[dns-operations] Reporting glue as authoritive data -- Bug!

Fri Jan 25 14:58:01 UTC 2008

> Although I work for the company that bought up Ultra, I didn't know 
> they were doing this until Monday.  Independently, and now 
> ironically, I was about to suggest the IETF document responses that I 
> have personally labeled 'hybrid' - combination answer and referral.
> 
> I wouldn't call this a bug in Ultra.  I don't know the reason they 
> are doing this but I think (think) is it trying to copy that actions 
> of the .com servers (ATLAS).
> 
> Try this 'dig ns1.crsnic.net. @f.gtld-servers.net.'
> 
> What makes this a hybrid:
> 
> Note the lack of a AA bit.
> Note the presence of an answer record.
> Note the lack of an RA bit.

	Which is based on BIND 8's behaviour which was a compromise
	due to everything being in one database.

> If the AA bit as here, it's an answer.  If the answer section was 
> empty, it would be a referral.  If it were obviously a recursive 
> response, it would like it was a cached answer.
> 
> I've had this discussion before.  The below message was a private 
> message sent in mid 05 to someone to explain why hybrid answers exist 
> and the niche they fill.  If I can find a public archive version, as 
> I refer to RIPE's dns-wg in the message, I'll post a link to it.)
> 
> Date: Tue, 14 Jun 2005 09:32:13 -0400
> From: Edward Lewis <Ed.Lewis at neustar.biz>
> Subject: Re: 4.3.2 and NS responses
> Cc: Edward Lewis <Ed.Lewis at neustar.biz>
> 
> >So, this is was Atlas does, but it is not what BIND and NSD do and what I
> >believe is correct and useful. BIND and NSD would respond with a vanilla
> >referral (NOERROR/NODATA), but wouldn't they violate the 4.3.2 algorithm the
> n?
> 
> The dilemma you see is "protocol definition" vs. "operational 
> experience."  I'll cut to some salient points and spare you the 
> melodrama of it all.
> 
> I call the pseudo-cache-plus-referral response a "hydrid."  The 
> hybrids are not part of the DNS specification and will cause problems 
> when we extend the basic DNS for something like DNSSEC.  Another 
> reason against the hybrids is that the cause a higher credibility 
> assignment to otherwise non-credible data. Non-credible because it is 
> coming from a "second source" (the .com/.net registry database).  The 
> higher credibility is that because the data is in the answer section, 
> it is assigned more credibility than glue.
> 
> ['08 note - in 05 I was using mistakenly using the word "credibility" 
> instead of "trustworthiness" as defined in RFC 2181.]
> 
> For good reasons, the hybrids are not part of the architecture of the 
> DNS.  They  only work if the out of band management is kept up to 
> date (the host objects) and so long as we don't extend the DNS in 
> certain ways - like DNSSEC does.
> 
> However, there is a whole 'nuther reality at work.  These hybrids are 
> a crutch for bygone but still in use BIND implementations and the 
> hybrid answers do cut down on extraneous DNS lookups.
> 
> In older BINDs, I think up until BIND 8.3 +/- .1, BIND's software 
> architecture lacked a decent "event manager."  BIND could iterate for 
> answers, but if it got too sidetracked it would develop amnesia and 
> forget why it asked for something.  A symptom of this would be "ask 
> once, get SERVFAIL, ask again, get answer."  This was a particular 
> problem with the ARIN portion of in-addr.arpa (probably as well for 
> the other RIRs) because ARIN complicated things by using the "vanity" 
> name server names.  (This is why I wanted to argue/discuss the issue 
> on dns-wg.)
> 
> True, ISC has now fixed this, but old BINDs to live on. Nevertheless, 
> new BINDs will issue fewer queries with the hybrids still in place 
> because BIND keeps plugging away to get addresses for all the NS 
> records in a referral.  BIND apparently isn't satisfied with glue.
> 
> So that's why the hybrids are there, in a nutshell.  I don't know of 
> any quantitative work on the issue.  I fell onto it when ARIN removed 
> some name servers for which the hybrid answers were in effect, 
> blowing some users out of the water.  At the time I thought "we've 
> done nothing wrong" operationally, followed up by doing packet 
> traces, and confirmed this with the Verigisn engineers.  That's how I 
> "discovered" this.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> If you knew what I was thinking, you'd understand what I was saying.
> 
> 
> At 9:48 +0000 1/25/08, Lutz Donnerhacke wrote:
> >I assume the DNS implementation on ultradns is buggy.
> >It respond the glue record in the answer section instead of the additional.
> >
> >; <<>> DiG 9.4.2 <<>> dns1.fqdn.org @tld1.ultradns.net
> >;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> >
> >;; QUESTION SECTION:
> >;dns1.fqdn.org.			IN	A
> >
> >;; ANSWER SECTION:
> >dns1.fqdn.org.		86400	IN	A	89.107.65.75
> >
> >;; AUTHORITY SECTION:
> >fqdn.org.		86400	IN	NS	dns2.fqdn.org.
> >fqdn.org.		86400	IN	NS	dns1.fqdn.org.
> >
> >;; ADDITIONAL SECTION:
> >dns2.fqdn.org.		86400	IN	A	208.83.233.58
> >
> >_______________________________________________
> >dns-operations mailing list
> >dns-operations at lists.oarci.net
> >http://lists.oarci.net/mailman/listinfo/dns-operations
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Think glocally.  Act confused.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org