On Wed, Feb 2, 2011 at 3:04 AM, Lorenzo Quatrini lorenzo.quatrini@gmail.com wrote:
Larry Vaden ha scritto:
AFAIK, that's the status of the clones at this time. Still unexplained is why
'host www.yahoo.com 208.67.220.220' and 'host www.yahoo.com 8.8.8.8' got completely different answers.
For what I know OpenDNS (208.67.222.222, 208.67.220.220) does some more "caching" and puts on play some more distribution algorithms on it's own, that's why it doesn't give the same answers that other dns do. I remember there where issues also about www.google.com not giving the "official" google server but their own cache.
That doesn't explain the observed behavior of dig/host/nslookup. Nor does IMHO the official release notes, which are quoted again for focus:
"* 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.
That wouldn't cause the observed behavior; the practice of backporting may be at play here. I'll check with the author's release notes for when/if this has ever been a "feature" in the stock isc.org code as well as BZ and report back to the list.