slackware64-current glibc resolver bug?

fancylad · 01-31-2010, 11:13 AM

I upgraded my system from slackware64-13.0 to slackware64-current and, as a result, have noticed what I believe to be a bug in glibc. I am using bind9 as a recursive nameserver on my system. Usually my /etc/resolv.conf file looks like this:

Quote:

nameserver localhost

This worked fine before the upgrade. However after the upgrade no application was able to resolve hostnames. For instance if I tried to ping www.google.com I would get this:

Quote:

ping: unknown host www.google.com

Dns tools like host and dig still worked. I think that might be because they use a different library to query nameservers:

Quote:

matt@amd:~$ldd `which host`
linux-vdso.so.1 => (0x00007ffffd1ff000)
liblwres.so.30 => /usr/lib64/liblwres.so.30 (0x00007f8dc3663000)
libdns.so.38 => /usr/lib64/libdns.so.38 (0x00007f8dc3325000)
libbind9.so.30 => /usr/lib64/libbind9.so.30 (0x00007f8dc311b000)
libisccfg.so.30 => /usr/lib64/libisccfg.so.30 (0x00007f8dc2f00000)
libisc.so.36 => /usr/lib64/libisc.so.36 (0x00007f8dc2cb7000)
libcrypto.so.0 => /usr/lib64/libcrypto.so.0 (0x00007f8dc2932000)
libisccc.so.30 => /usr/lib64/libisccc.so.30 (0x00007f8dc272a000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f8dc2510000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8dc22f3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8dc1f82000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8dc1d7e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8dc3874000)

Quote:

matt@amd:~$sudo ldd `which ping`
linux-vdso.so.1 => (0x00007fffe75ff000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2516f4f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2516bde000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2517168000)

I tried comparing using localhost and 127.0.0.1 in the /etc/resolv.conf file on my laptop which is running slackware-13.0 and that works normally. In fact I can delete /etc/resolv.conf altogether and the resolver still queries bind9 running locally.

Has anyone else experienced this?

From man resolv.conf:

Quote:

On a normally configured system this file should not be necessary. The only name server to be queried will be on the local machine;...If no nameserver entries are present, the default is to use the name server on the local machine.

bsdunix · 01-31-2010, 11:25 AM

May not be what happened to you, but by mistake, I upgraded the x86 patches on a x64 system and I couldn't hostname resolve like you. I had to uninstall all the x86 packages, install the x64 packages, then upgrade the correct x64 packages. I had one of the doh moments.

fancylad · 01-31-2010, 11:35 AM

No that's not happened...although I have done that before too

. I did do some googling on glibc 2.11.1 /etc/resolv.conf bugs and found this: http://sourceware.org/ml/libc-announ.../msg00000.html

I'm not sure if that's the same thing though.

bsdunix · 01-31-2010, 12:09 PM

Pat applied that glibc 2.11.1 patch Jan 4th, so I don't think that is it.

I presume you've already done basic network troubleshooting, i.e. ping the gateway and Internet hosts by IP and received a reply?

fancylad · 01-31-2010, 12:39 PM

yes i did do all that already. i can ping hosts fine by ip and like i said host and dig still work.

fancylad · 01-31-2010, 12:56 PM

Also bsdunix I am wondering how you know that the patch was applied on Jan 4th? Are you just looking through ChangeLog.txt or do you have another source? When I look in ChangeLog.txt all I see for that day pertaining to glibc is:

a/glibc-solibs-2.11.1-x86_64-1.txz: Upgraded.

Does "Upgraded" imply patched?

rworkman · 01-31-2010, 03:15 PM

I noticed that same thing here on my home network while I was doing early testing of libc-2.11.x - with "nameserver localhost" in resolv.conf, DNS lookups were broken; with "nameserver 127.0.0.1" in resolv.conf, they were fine. After discussing it amongst the other team members, the consensus was basically this: there should be an ip address, not a hostname, specified as the dns server in resolv.conf -- after all, if a *name* is there, then where to look to get the ip address of the name? It's a chicken-egg problem :-) It previously worked, and while it's troublesome to refer to a *working* something as a *bug*, that's probably the correct nomenclature here. That being said, I realize that there's probably some room for debate as to whether the previous behavior or the current behavior is a bug.

mRgOBLIN · 01-31-2010, 03:20 PM

Yes Robby noticed the same thing but this from the resolv.conf man page

Quote:

nameserver Name server IP address
Internet address (in dot notation) of a name server that the resolver should query.

Might suggest that using _any_ hostname as a server address might not be correct.

fancylad · 01-31-2010, 04:47 PM

I agree rworkman that one *should* have an ip and not a hostname in /etc/resolv.conf. But if I have a hostname/ip mapping in /etc/hosts then it should work fine as the resolver or whatver can check /etc/hosts first. Also in the current man page for resolv.conf it states:

Quote:

On a normally configured system this file should not be necessary. The only name server to
be queried will be on the local machine; the domain name is determined from the hostname and
the domain search path is constructed from the domain name.

And further down:

Quote:

If no nameserver entries are present, the default is to use the name server
on the local machine.

Based on these two statements as well as the behavior of glibc in previous versions, this does seem, IMHO, to be a bug as it would be logical for the resolver to still function in the absence of any /etc/resolv.conf. Having said this it is not that big a deal to always have ip addresses in /etc/reslv.conf.