Funny cache records
Barry Margolin
barmar at alum.mit.edu
Fri Feb 20 23:06:04 UTC 2004
In article <c162g1$2ueb$1 at sf1.isc.org>,
Jeff Stevens <jstevens at vnet.ibm.com> wrote:
> I have a customer reporting intermittent problems resolving www.msn.com
> (but not msn.com) and I had him dump his cache and I see the following.
> What kind of situations would cause the cache to have these SOA's and
> an A record of localhost?
>
> $ORIGIN msn.COM.
> ;help 243 IN SOA localhost. postmaster.localhost. (
> ; 2002100100 3600 1800 604800 3600 );msn.com.;NXDOMAIN ;-$ ;Cr=auth
> [206.13.29.12]
> www 2376 IN SOA localhost. postmaster.localhost. (
> 2002100100 3600 1800 604800 3600 ) ;Cr=auth [206.13.29.12]
> ; 2376 IN A localhost. postmaster.localhost. (
> ; 2002100100 3600 1800 604800 3600 );www.msn.com.;NODATA ;-$ ;Cr=auth
> [206.13.29.12]
The entries marked ";-$" are negative cache entries. The "IN A"
indicates that this is the type of record that could not be found; the
rest of the data is from the SOA record for the containing zone.
I can't explain where these bogus cache entries came from, though. When
I query 206.13.29.12 (dns1.lsanca.sbcglobal.net) it appears to know that
www.msn.com is delegated to various msft.net servers, and it knows the
correct SOA record for the zone. All I can think of is that there's a
firewall or transparent DNS cache between the customer's machine and
SBC's DNS server.
I'm not sure why the sbcglobal.net server is involved at all. Does he
have "forwarders" configured? Tell him to use the root servers directly
instead of forwarding to his ISP's servers.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
More information about the bind-users
mailing list