[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: bert hubert <ahu@ds9a.nl>
CC: dnsop@cafax.se
From: "Piet E. Barber" <pbarber@verisign.com>
Date: Thu, 02 Aug 2001 10:46:35 -0400
Sender: owner-dnsop@cafax.se
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; rv:0.9.1) Gecko/20010621
Subject: Re: Joint DNSEXT & NGTRANS agenda

>At Amnic:
>	I.AM			NS 	select.powerdns.com.
>	I.AM			NS 	mincore.powerdns.com.
>
>At the GTLD servers:
>
>	powerdns.com		NS	dns-us1.powerdns.net.
>	powerdns.com		NS	dns-eu1.powerdns.net.
>	dns-us1.powerdns.net	A	63.123.33.130
>	dns-eu1.powerdns.net	A	213.244.168.217
>
Bert and I worked on this issue for a few days, trying to figure out why 
a server running BIND 4.x - Bind 8.2.4 would behave like this.  (Bind 9 
and Windows 2000 weren't affected).

The problem was subtle and difficult to explain without drawing diagrams 
and waving my arms about.  To make it short, BIND would go through all 
the normal procedures to retrieve the glue in order to figure out just 
who 'select.powerdns.com' and 'mincore.powerdns.com' were.  After the 
answer came back from the gTLD servers, BIND said, "OK. This glue must 
not be valid, I'm tossing it out" and stops the fetch-glue chain.  

I documented my thinking at the time with packet traces and BIND debug 
output. If you want the whole explanation, please write to me privately.

Our analysis led us to believe that it was a "BIND" bug and not a 
protocol issue. (And I've been too busy to write the guys at ISC and 
tell them about it!  Shame on me!)

And FWIW, when I'm chasing down re-querying-atrocities from nameservers 
across the Internet, pounding the root servers and gtld servers, it's 
hardly ever a BIND server.

I'd love to talk about this at the IETF in London, but, sadly,  I won't 
be there.



Home | Date list | Subject list