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.
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
