On Wed, Feb 2, 2011 at 3:04 AM, Lorenzo Quatrini
<lorenzo.quatrini@xxxxxxxxx> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
