Discussion:
How to make resolvconf put 3 nameserver entries in resolv.conf???
(too old to reply)
David Mathog
2007-05-29 22:01:29 UTC
Permalink
resolvconf: one step forward (in theory), 5 steps back (in practice).

Once upon a time (like, for as long as I've been using unix, so at least
20 something years) there was a file /etc/resolv.conf into which one
placed as many nameserver records as needed. For various reasons some
of the workstations I manage have 3 nameserver records. Then along comes
Mandriva 2007.1 and /etc/resolv.conf is generated automagically by
resolv.conf, and it appears that the nameserver records are derived from

/etc/sysconfig/network-scripts/ifcfg-eth0

specifically the DNS1= and DNS2= lines. To test I reordered the DNS1 and
DNS2 records in ifcfg-eth0 and restarted the network, and those changes
showed up in /etc/resolv.conf. So, I tried putting a DNS3= line in
ifcfg-eth0, did a

service network restart

and /etc/resolv.conf was rewritten - but only with the first two
nameserver records. I tried to trace it back through

/etc/resolvconf/update.d/libc

but got lost and couldn't figure out exactly where it was pulling the
DNS names from ifcfg-eth0.

So why is it that resolvconf accepts DNS1 and DNS2 but not DNS3???

This may sound like it's coming from a Luddite, but it completely
escapes me what the advantage is of using resolvconf over simply editing
/etc/resolv.conf. The DISadvantage of using resolvconf is, I think,
manifestly evident in the current problem.

Oh yes, I did try using drakconf to change this. That let me enter a
third nameserver record (but no option to enter a 4th), and that third
entry did end up in /etc/resolv.conf. However this REMOVED the DNS3=
entry from
/etc/sysconfig/network-scripts/ifcfg-eth0

This is much, much, MUCH too much mystery for a key system configuration
step.

Thanks,

David Mathog
David Mathog
2007-05-29 22:03:47 UTC
Permalink
Post by David Mathog
Oh yes, I did try using drakconf to change this. That let me enter a
third nameserver record (but no option to enter a 4th), and that third
entry did end up in /etc/resolv.conf. However this REMOVED the DNS3=
entry from
/etc/sysconfig/network-scripts/ifcfg-eth0
I forgot to mention, that in it's inscrutable wisdom at the next:

service network restart

resolvconf deleted the 3rd nameserver entry from /etc/resolv.conf.

Regards,

David Mathog
Bit Twister
2007-05-29 22:53:24 UTC
Permalink
Post by David Mathog
service network restart
resolvconf deleted the 3rd nameserver entry from /etc/resolv.conf.
Why fight it, create a script, say /sone/where/x_add_nameserver

#!/bin/bash
_count=$(grep -c nameserver /etc/resolv.conf)
if [ $_count -lt 3 ] ; then
echo "nameserver x.x.x.x" /etc/resolv.conf
fi
true
#************** end x_add_nameserver **********************

then
chmod +x /sone/where/x_add_nameserver
cd /etc/sysconfig/network-scripts/ifup.d/
ln -s /sone/where/x_add_nameserver

if dns values come from a dhcp connection,
cd /etc
ln -s /sone/where/x_add_nameserver dhclient-exit-hooks

Or add x_add_nameserver to /etc/dhclient-exit-hooks, if it exists. The next
service network restart
should add the line for you.
David W. Hodgins
2007-05-29 23:37:51 UTC
Permalink
Post by David Mathog
This may sound like it's coming from a Luddite, but it completely
escapes me what the advantage is of using resolvconf over simply editing
/etc/resolv.conf. The DISadvantage of using resolvconf is, I think,
manifestly evident in the current problem.
If you're using a laptop, or using different providers, at different times,
it saves having to update resolv.conf, yourself.

If the nameservers you want to specify, are fixed, just add the nameserver
line(s) to /etc/resolvconf/resolv.conf.d/head.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
David
2007-05-31 00:28:38 UTC
Permalink
Post by David W. Hodgins
Post by David Mathog
This may sound like it's coming from a Luddite, but it completely
escapes me what the advantage is of using resolvconf over simply editing
/etc/resolv.conf. The DISadvantage of using resolvconf is, I think,
manifestly evident in the current problem.
If you're using a laptop, or using different providers, at different times,
it saves having to update resolv.conf, yourself.
If the nameservers you want to specify, are fixed, just add the nameserver
line(s) to /etc/resolvconf/resolv.conf.d/head.
This is what is at the top of the head file

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

What would be the point of adding the nameserver info here, if it will
be overwritten?
Post by David W. Hodgins
Regards, Dave Hodgins
Robert M. Riches Jr.
2007-05-31 00:49:11 UTC
Permalink
Post by David
Post by David W. Hodgins
Post by David Mathog
This may sound like it's coming from a Luddite, but it completely
escapes me what the advantage is of using resolvconf over simply editing
/etc/resolv.conf. The DISadvantage of using resolvconf is, I think,
manifestly evident in the current problem.
If you're using a laptop, or using different providers, at different times,
it saves having to update resolv.conf, yourself.
If the nameservers you want to specify, are fixed, just add the nameserver
line(s) to /etc/resolvconf/resolv.conf.d/head.
This is what is at the top of the head file
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
What would be the point of adding the nameserver info here, if it will
be overwritten?
I think the point is you put stuff in
/etc/resolvconf/resolv.conf.d/head so the automagic stuff
will copy that into /etc/resolv.conf when it updates it.
--
Robert Riches
***@verizon.net
(Yes, that is one of my email addresses.)
Bit Twister
2007-05-31 01:11:23 UTC
Permalink
Post by Robert M. Riches Jr.
I think the point is you put stuff in
/etc/resolvconf/resolv.conf.d/head so the automagic stuff
will copy that into /etc/resolv.conf when it updates it.
Downside is, if third nameserver is the last resort server, you will be
hitting it first instead of the "Primary/ISP nameservers" :(
David W. Hodgins
2007-05-31 01:44:49 UTC
Permalink
Post by Bit Twister
Post by Robert M. Riches Jr.
I think the point is you put stuff in
/etc/resolvconf/resolv.conf.d/head so the automagic stuff
will copy that into /etc/resolv.conf when it updates it.
Downside is, if third nameserver is the last resort server, you will be
hitting it first instead of the "Primary/ISP nameservers" :(
Then put it in the tail file, in the same conference.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Bit Twister
2007-05-31 02:09:03 UTC
Permalink
Post by David W. Hodgins
Then put it in the tail file, in the same conference.
Well shucky dern, there is a /etc/resolvconf/resolv.conf.d/tail
I should have looked.
David W. Hodgins
2007-05-31 01:48:37 UTC
Permalink
Post by David Mathog
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
What would be the point of adding the nameserver info here, if it will
be overwritten?
The generated resolv.conf file gets overridden, using the files
in this directory, plus those generated by resolvconf when the
network starts.

I have $ cat /etc/resolvconf/resolv.conf.d/head
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 127.0.0.1 # Caching name server

------ end of cat
with the result $ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 127.0.0.1 # Caching name server

nameserver 216.240.0.1 # ppp temp entry
nameserver 216.240.1.1 # ppp temp entry
nameserver 216.240.0.1 #kppp temp entry
nameserver 216.240.1.1 #kppp temp entry
------ end of cat

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
David Mathog
2007-05-31 16:21:37 UTC
Permalink
Post by David W. Hodgins
with the result $ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1 # Caching name server
nameserver 216.240.0.1 # ppp temp entry
nameserver 216.240.1.1 # ppp temp entry
nameserver 216.240.0.1 #kppp temp entry
nameserver 216.240.1.1 #kppp temp entry
Unless the resolv.conf mechanism is smarter than I think it is won't
that look for 0.1, then 1.1, then 0.1 AGAIN, and 1.1 AGAIN? If it
didn't find what it wanted in 0.1 or 1.1 the first time, it probably
isn't going to find it the second time either.

Regards,

David Mathog
David W. Hodgins
2007-05-31 17:27:57 UTC
Permalink
Post by David Mathog
Post by David W. Hodgins
with the result $ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1 # Caching name server
nameserver 216.240.0.1 # ppp temp entry
nameserver 216.240.1.1 # ppp temp entry
nameserver 216.240.0.1 #kppp temp entry
nameserver 216.240.1.1 #kppp temp entry
Unless the resolv.conf mechanism is smarter than I think it is won't
that look for 0.1, then 1.1, then 0.1 AGAIN, and 1.1 AGAIN? If it
didn't find what it wanted in 0.1 or 1.1 the first time, it probably
isn't going to find it the second time either.
That's kppp adding the lines, after ppp has done so. I haven't bothered
to figure out how to stop it, as resolvconf doesn't seem to be duplicating
the nameserver lookups. It seems it does have the smarts to remove
duplicates.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
David Mathog
2007-06-01 18:39:39 UTC
Permalink
Post by David W. Hodgins
Post by David Mathog
Post by David W. Hodgins
with the result $ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1 # Caching name server
nameserver 216.240.0.1 # ppp temp entry
nameserver 216.240.1.1 # ppp temp entry
nameserver 216.240.0.1 #kppp temp entry
nameserver 216.240.1.1 #kppp temp entry
Unless the resolv.conf mechanism is smarter than I think it is won't
that look for 0.1, then 1.1, then 0.1 AGAIN, and 1.1 AGAIN? If it
didn't find what it wanted in 0.1 or 1.1 the first time, it probably
isn't going to find it the second time either.
That's kppp adding the lines, after ppp has done so. I haven't bothered
to figure out how to stop it, as resolvconf doesn't seem to be duplicating
the nameserver lookups. It seems it does have the smarts to remove
duplicates.
Have you actually verified this? It would only progress down the list
if a name lookup failed (server down, or _maybe_ some cases where the
server can't resolve the name). If the nameservers are up you'll
normally never get past the first one.

For jollies you might make a resolv.conf listing two nonexistant name
servers. Then time something that does a name lookup and wait for it to
time out on the failed namelookups. Duplicate the lines and try it
again. If you're correct the two times will be the same.

Regards,

David Mathog
David W. Hodgins
2007-06-01 21:11:26 UTC
Permalink
Post by David Mathog
Have you actually verified this? It would only progress down the list
if a name lookup failed (server down, or _maybe_ some cases where the
server can't resolve the name). If the nameservers are up you'll
normally never get past the first one.
I tested using wireshark, to see the dns lookups, as they were processed,
however, as you suggested, I just tried testing with multiple lines like
nameserver 10.0.0.1 # No such server
prepended, to /etc/resolv.conf, and as you expected, it does not remove
the duplicates. I stand corrected.

I then looked at kppp. To stop the duplication, select the configure tab,
accounts, edit the account being used, and change the dns configuration,
from automatic to manual. ppp will still generate the lines, and kppp is
no longer generating duplicates.

Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Moe Trin
2007-06-02 00:16:39 UTC
Permalink
On Thu, 31 May 2007, in the Usenet newsgroup alt.os.linux.mandriva, in article
Post by David W. Hodgins
Post by David W. Hodgins
with the result $ cat /etc/resolv.conf
Post by David W. Hodgins
nameserver 127.0.0.1 # Caching name server
nameserver 216.240.0.1 # ppp temp entry
nameserver 216.240.1.1 # ppp temp entry
nameserver 216.240.0.1 #kppp temp entry
nameserver 216.240.1.1 #kppp temp entry
Unless the resolv.conf mechanism is smarter than I think it is won't
that look for 0.1, then 1.1, then 0.1 AGAIN, and 1.1 AGAIN?
Yes, but for a different reason. Read the man page for 'resolver'(5)
and in the 'nameserver' option description, see

nameserver
Internet address (in dot notation) of a name server that the
resolver should query. Up to MAXNS (see <resolv.h>) name
servers may be listed, one per keyword. If there are multiple
servers, the resolver library queries them in the order listed.
If no nameserver entries are present, the default is to use the
name server on the local machine.

So, what is "MAXNS" on your system?

[compton ~]$ grep MAXNS /usr/include/resolv.h
#define MAXNS 3 /* max # name servers we'll track */
nsaddr_list[MAXNS]; /* address of name server */
[compton ~]$

It almost always set to "3", so the second pair of entries won't be used.
Post by David W. Hodgins
That's kppp adding the lines, after ppp has done so.
Actually, no. If you read the man page for pppd, in the 'usepeerdns'
option, you'll find that pppd creates "/etc/ppp/resolv.conf", and also
passes the two IP addresses as "DNS1" and "DNS2" to the /etc/ppp/ip-up
script. pppd does NOT mess with /etc/resolv.conf. It's more likely to be
some wonderful improvement from Mandriva that is screwing things up, and
this _may_ be done in that /etc/ppp/ip-up script. See the "SCRIPTS"
section of the same man page.
Post by David W. Hodgins
I haven't bothered to figure out how to stop it, as resolvconf doesn't
seem to be duplicating the nameserver lookups. It seems it does have
the smarts to remove duplicates.
Yes, kppp is following the "I know better than you - I'll fix things"
mode from microsoft. You could try disabling the name server option in
kppp (or simply junk the entire bloated security problem and create a
short script to replace it - my scripts are a total of

[mro ~]$ wc /usr/local/bin/dialin /etc/ppp/dialscript
/etc/ppp/pap-secrets
4 19 169 /usr/local/bin/dialin
1 11 67 /etc/ppp/dialscript
1 3 22 /etc/ppp/pap-secrets
6 33 258 total
[mro ~]$

258 bytes - of course this doesn't include /usr/sbin/chat which is already
installed (16k), but the combination is probably smaller than the kppp
man page, never mind the binary.

Old guy

Dave Pickles
2007-05-30 05:53:15 UTC
Permalink
Post by David Mathog
resolvconf: one step forward (in theory), 5 steps back (in practice).
Once upon a time (like, for as long as I've been using unix, so at least
20 something years) there was a file /etc/resolv.conf into which one
placed as many nameserver records as needed. For various reasons some
of the workstations I manage have 3 nameserver records. Then along comes
Mandriva 2007.1 and /etc/resolv.conf is generated automagically by
resolv.conf, and it appears that the nameserver records are derived from
/etc/sysconfig/network-scripts/ifcfg-eth0
specifically the DNS1= and DNS2= lines. To test I reordered the DNS1 and
DNS2 records in ifcfg-eth0 and restarted the network, and those changes
showed up in /etc/resolv.conf. So, I tried putting a DNS3= line in
ifcfg-eth0, did a
service network restart
and /etc/resolv.conf was rewritten - but only with the first two
nameserver records. I tried to trace it back through
/etc/resolvconf/update.d/libc
but got lost and couldn't figure out exactly where it was pulling the
DNS names from ifcfg-eth0.
So why is it that resolvconf accepts DNS1 and DNS2 but not DNS3???
This may sound like it's coming from a Luddite, but it completely
escapes me what the advantage is of using resolvconf over simply editing
/etc/resolv.conf. The DISadvantage of using resolvconf is, I think,
manifestly evident in the current problem.
Oh yes, I did try using drakconf to change this. That let me enter a
third nameserver record (but no option to enter a 4th), and that third
entry did end up in /etc/resolv.conf. However this REMOVED the DNS3=
entry from
/etc/sysconfig/network-scripts/ifcfg-eth0
This is much, much, MUCH too much mystery for a key system configuration
step.
In /etc/resolvconf/resolv.conf.d there are two files 'head' and 'tail'
which are copied into /etc/resolv.conf before and after the automagic.
Put your *real* resolv.conf entries in one of those.
--
Dave
David Mathog
2007-05-30 16:23:44 UTC
Permalink
Dave Pickles wrote:
(and David Hodgkins said something similar)
Post by Dave Pickles
In /etc/resolvconf/resolv.conf.d there are two files 'head' and 'tail'
which are copied into /etc/resolv.conf before and after the automagic.
Put your *real* resolv.conf entries in one of those.
That won't fix the interaction with drakconf though. To review, if one
used drakconf to set three nameservers it correctly sets up resolv.conf
and puts only DNS1=, DNS2= into

/etc/sysconfig/network-scripts/ifcfg-eth0.

Unfortunately the next time the network restarts resolv.conf will be
overwritten with just the entries from DNS1=, DNS2=. If these tools
played nicely together then one or both would have already put the
nameserver entries into the "head" file.

This is I think yet another bug in 2007.1, specifically:

Part 1: resolvconf as supplied by Mandriva 2007.1 only processes DNS1=
and DNS2= records in ifcfg-eth0.
Part 2: drakconf (apparently) writes directly to /etc/resolv.conf but
does not make corresponding changes to ifcfg-eth0 (omitting DNS3=).
Part 3: at the next network restart (part) of the drakconf configuration
is lost.

I'll have another look at the libc script in resolvconf. Perhaps if I
can figure out it's inscrutable processing of the DNS= records I'll be
able to fix this.

Thanks,

David Mathog
David Mathog
2007-05-30 16:55:06 UTC
Permalink
Post by David Mathog
I'll have another look at the libc script in resolvconf. Perhaps if I
can figure out it's inscrutable processing of the DNS= records I'll be
able to fix this.
AAARGH!!!!

The libc script seems not to ever look at ifcfg-eth0 directly. Instead
it is reading from /etc/resolvconf/run/interface/eth0 which holds the
exact same (two) entries as /etc/resolv.conf. However, I DID
find these lines inside the uniquify_nameserver_list() function in the
libc script:

N=$(($N + 1))
[ "$N" = 3 ] && return 0

and that may be part of the issue. The function is fed from sed on the
.../interface/eth0 file so that the function sees the list of
nameservers from that file on one line.

So, I modified /etc/resolvconf/run/interface/eth0 to add a third
nameserver entry and did

service network restart

and voila, STILL 2 entries in resolv.conf, and ..../interface/eth0 was
back down to 2 nameservers as well. Apparently some OTHER script is
converting ifcfg-eth0 to .../interface/eth0 and THAT one is stopping
at two DNS entries.

This is such a PITA.

Now I get to step through /etc/rc.d/init.d/network to figure out what is
writing interface/eth0.

Regards,

David Mathog
David Mathog
2007-05-30 18:15:38 UTC
Permalink
Post by David Mathog
The libc script seems not to ever look at ifcfg-eth0 directly. Instead
it is reading from /etc/resolvconf/run/interface/eth0 which holds the
exact same (two) entries as /etc/resolv.conf. However, I DID
find these lines inside the uniquify_nameserver_list() function in the
N=$(($N + 1))
[ "$N" = 3 ] && return 0
and that may be part of the issue.
It would be if there were MORE than 3 nameservers. I finally tracked
the immediate problem (not even 3 nameservers supported) down to
some truly hideous logic in

/etc/sysconfig/network-scripts/ifup-post

Here's the diff that enables 3 nameservers:

% diff ifup-post ifup-post.dist
38,40c38
< DNSCOUNT=3
< DNSNEXT=""
< (cat /etc/resolv.conf ; echo EOF ; echo EOF; echo EOF) | while
read answer ; do
---
Post by David Mathog
(cat /etc/resolv.conf ; echo EOF ; echo EOF) | while read answer ; do
47,49c45
< DNSNEXT="DNS${DNSCOUNT}"
< eval "next_replacement=$`echo $DNSNEXT`"
< DNSCOUNT=$(($DNSCOUNT + 1))
---
Post by David Mathog
next_replacement=
So, how does this routine work? Well, among other things the original
was HARDWIRED to only look at DNS1 and DNS2 entries. Even with the
patch the limit for the number of sequential
DNS# entries is set by the number of "echo EOF" lines. If PEERDNS is set
to "no" in ifcfg-eth0 the result is an
/etc/resolv.conf with no nameserver entries. In older versions of
Mandriva I had PEERDNS=yes in ifcfg-eth0 and no DNS# entries in that
file, which worked fine. Unfortunately in Mandriva 2007.1 that will
cause an empty /etc/resolv.conf the next time the network restarts.
There are only minor changes in ifup-post between 2006.0 and 2007.1,
so yet something else is involved in this interaction.

My patch does not address the problem of drakconf setting nameserver
lines in /etc/resolv.conf and NOT putting DNS# lines in ifcfg-eth0.

Here are the contents of /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=static
IPADDR=131.215.66.66
NETMASK=255.255.255.0
NETWORK=131.215.66.0
BROADCAST=131.215.66.255
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=yes
USERCTL=no
PEERDNS=yes
DNS1=131.215.254.100
DNS2=131.215.139.100
DNS3=131.215.9.49
DOMAIN=bio.caltech.edu
RESOLV_MODS=yes
LINK_DETECTION_DELAY=6
IPV6INIT=no
IPV6TO4INIT=no

and here is the /etc/resolv.conf that results from
a "service network restart":

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 131.215.254.100
nameserver 131.215.139.100
nameserver 131.215.9.49
search bio.caltech.edu


All in all, this is quite a mess.

Regards,

David Mathog
David Mathog
2007-05-30 18:24:09 UTC
Permalink
Post by David Mathog
resolvconf: one step forward (in theory), 5 steps back (in practice).
I have probably unfairly mailigned resolvconf. These problems seem to
stem primarily from other scripts in Mandriva 2007.1 which do not work
well since resolvconf was added, rather than with an intrinsic problem
in resolvconf itself.

David Mathog
Loading...