Funny cache records

[Barry Margolin]

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