On Wed, Feb 2, 2011 at 1:41 PM, Lamar Owen <lo...@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 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
