dhcpcd putting garbage into resolv.conf

Has anyone seen this? I recently discovered that I had an incorrect (but
optional)domain name configured in my D-LINK DI-604 router. This caused
dhcpcd to place the bad domain name into the "search" entry in
resolv.conf, and I believe that this is causing a major slowdown in
resolving hostnames for me.

SO, since I didn't want a search entry in resolv.conf at all, I deleted
the "optional" local domain name in the D-LINK configuration webpage, and
restarted the router. I then did an ifdown eth0/ifup eth0, and checked
resolv.conf This is what I now see:

### BEGIN INFO
# Modified_by: dhcpcd
# Backup: /etc/resolv.conf.saved.by.dhcpcd [SNIP more comments
genereated by dhcpcd] ### END INFO
search |ê@|ê@
nameserver 192.168.0.1

This is even worse :-( So HOW do I get dhcpcd to stop making a "search"
entry in resolv.conf?? I don't want to resort to telling dhcpcd to not
build a resolv.conf at all if possible (if I ever decide to change the
router's base IP address, I don't want to have to remember that I have to
manually fix resolv.conf to point to the new nameserver location on the
router). Is this a bug in dhcpcd? or possibly a flaw in the D-LINK
firmware for the router that is returning a bad string to Linux?

FYI, I am running SuSE 9.0, running Linux 2.4.21-199-default, and dhcpcd
reports a version of v.1.3.22-p14 (the default that came with SuSE 9.0).
The D-LINK DI-604 router reports a firmware version of 3.20, dated July 1,
2003.

Thanks for any help or pointers!

On Sat, 26 Jun 2004 17:57:06 -0700, Bradley Navarro wrote:
> Has anyone seen this? I recently discovered that I had an incorrect (but
> optional)domain name configured in my D-LINK DI-604 router. This caused
> dhcpcd to place the bad domain name into the "search" entry in
> resolv.conf, and I believe that this is causing a major slowdown in
> resolving hostnames for me.

I did not want the search concast.net placed in my resolv.conf for the
same reason. Also I figured since everyone is using the first dns
server I would use the other one. If they renumber I'll have to fix
the sort command.

On Mandrakelinux all the scripts found in
/etc/sysconfig/network-scripts/ifup.d/
are executed when a device is brought up.

You may want to remove the last copy command unless you are running
postfix. Postfix complains if it's copy and /etc/resolv.conf dates do
not match.

#*************************************************
#
# strip_search - strip *search* line from resolv.conf
#
# A reverse sort to used to flip name server order.
# Rational, everyone is using the first name server.
#
# Usually placed at bottom of /etc/rc.d/rc.local
# or placed in /etc/sysconfig/network-scripts/ifup.d/
#
#*************************************************

_new=/tmp/resolv.conf_new

cp /dev/null $_new
while read line
do
set -a $line
if [ $1 != "search" ] ; then
echo $line >> $_new
fi
done < /etc/resolv.conf

sort -r -o /etc/resolv.conf $_new
/bin/cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf

#--------- end strip_search -----------------------

Bit Twister <BitTwister@localhost.localdomain> writes:

]same reason. Also I figured since everyone is using the first dns
]server I would use the other one. If they renumber I'll have to fix
]the sort command.

The second nameserver may be there because it is known to be slow or
unreliable, but it is a backup just in case the first one does not work. Ie
your reasoning is suspect.


]On Mandrakelinux all the scripts found in
]/etc/sysconfig/network-scripts/ifup.d/
]are executed when a device is brought up.

]You may want to remove the last copy command unless you are running
]postfix. Postfix complains if it's copy and /etc/resolv.conf dates do
]not match.

]#*************************************************
]#
]# strip_search - strip *search* line from resolv.conf
]#
]# A reverse sort to used to flip name server order.
]# Rational, everyone is using the first name server.
]#
]# Usually placed at bottom of /etc/rc.d/rc.local
]# or placed in /etc/sysconfig/network-scripts/ifup.d/
]#
]#*************************************************

]_new=/tmp/resolv.conf_new

]cp /dev/null $_new
]while read line
]do
] set -a $line
] if [ $1 != "search" ] ; then
] echo $line >> $_new
] fi
]done < /etc/resolv.conf

Uh, grep -v '^search' /etc/resolv.conf> $_new
would do the same thing much much more easily.


]sort -r -o /etc/resolv.conf $_new
]/bin/cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf

]#--------- end strip_search -----------------------

On Sun, 27 Jun 2004 01:36:59 +0000 (UTC), Bill Unruh wrote:

> The second nameserver may be there because it is known to be slow or
> unreliable, but it is a backup just in case the first one does not work. Ie
> your reasoning is suspect.

Hmmm, since comcast's newsserver are slow you could be quite right.
>
> Uh, grep -v '^search' /etc/resolv.conf> $_new
> would do the same thing much much more easily.

Well, shucky dern, I know that. :-[

I am so used to keeping coding snippets handy and tend to include/re-work
them I have not bothered to engage brain.