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.