On Wed, Feb 2, 2011 at 1:41 PM, Lamar Owen <lowen at pari.edu> wrote: > On Wednesday, February 02, 2011 09:31:43 am Larry Vaden wrote: >> "* The host/dig/nslookup utilities queried only servers from >> resolv.conf. With this update, the utilities query the servers >> specified on command line instead of in resolv.conf and the issue is >> resolved. ( BZ#561299)" >> >> The official release notes imply that the argument on the command line >> was ignored and the contents of /etc/resolv.conf were used instead >> which should lead to consistent results between the two invocations. Genau. > I think the release notes do not reflect the actual bug, in this case. The bug text is: > > "I have noticed that release 5.4 (Final) appears to ignore the server option > when using host or nslookup if the host in question is not available. > > The commands should return no server available as they have in the past > but instead decide to query the servers specified in resolv.conf and return > results from that." > > As both of the servers you gave in the message provided results, the queries given do not trigger the actual bug; that is, if the server referenced is not available or does not return a result, *then* it went to the servers in resolv.conf rather than the previous behavior. > > Fault lies in the writer of the release note bullet point, which does not accurately describe the bug actually fixed. > > And that explains why 'host www.yahoo.com 208.67.220.220' and 'host www.yahoo.com 8.8.8.8' got completely different answers, as I know OpenDNS does fairly aggressive caching that semi-ignores $TTL, and google (8.8.8.8 is a google DNS server) probably does too. I think your analysis is spot on. kind regards/ldv