SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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:
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:
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:
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.
Last edited by fancylad; 01-31-2010 at 11:17 AM.
Reason: some info from man resolv.conf:
Distribution: Caldera, CTOS, Debian, FreeBSD, Mac OS X, Mandrake, Minix, OpenBSD, Slackware, SuSE
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.
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:
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.
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:
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:
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.