On Wed, Feb 2, 2011 at 3:04 AM, Lorenzo Quatrini <lorenzo.quatrini at 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.