original report here: http://sources.redhat.com/ml/libc-alpha/2004-09/msg00146.html basically somewhere between Aug 08 2004 and Sep 18 2004, the resolver library's behavior broke when dealing with 'domain' entries in resolv.conf when looking up a hostname, the old behavior was to try to search for the hostname in each of the domains found in resolv.conf ... if those lookups failed, the hostname itself would be tried the new behavior is to only search in the domains found in resolv.conf for example, i have the host 'aurora' setup to resolve to '192.168.0.7' on my dns server ... on a client machine, i would look up 'aurora' via gethostbyname() ... in the resolv.conf on the client machine, i have one domain entry, 'domain wh0rd.org' ... the old glibc would query 'aurora.wh0rd.org' and fail, and then fall back and try to look up 'aurora' which would work the new glibc only tries 'aurora.wh0rd.org' and then fails sniffing dns traffic via ethereal backed up this analysis
i neglected to mention that if i remove the 'domain wh0rd.org' from the resolv.conf on my client, the new glibc will attempt to lookup just 'aurora' and thus work 'properly'
I know which change this was, revision 1.20 of resolv/res_query.c (minus the accidentally left in debug stuff). But I maintain that this is the correct change and that it worked for you by accident. Try adding options ndots:0 to your resolv.conf.
'options ndots:0' restored the previous behavior like i described and like you said i'm not sure if there are any specs which cover the 'proper' behavior with respect to resolv.conf/domain/etc... (SuSv3 and such) but like you say, when using the 'domain' option in resolv.conf, this seems like 'proper' behavior, even it does take 'more' effort to get back to the older/simpler behavior perhaps we can get the man page to make a note of the 'expected' behavior under the ndots section so that people (such as myself) wont file anymore 'invalid' bugs unknowingly ?
Man pages are not part of glibc. Bring this up with the appropriate person.