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

Tue Jan 29 15:51:05 UTC 2008

I wanted to update my first response to the thread.

I asked the Ultra engineering team about this and found out that this 
is not the result of a recent change to the Ultra code, it has been 
in place for a long time (how long I don't know).

Additionally, the Ultra engineers are aware of the "totality" of the 
issue.  There is a comment in the code that shows awareness of what 
is going on, documenting that a broken "ancient $brand_name recursive 
resolver, [is] causing our production network to get slammed.  The 
purpose of this code is to move glue records from the answer section 
into the additional section when giving back a child NS delegation."

Where $brand_name is not BIND.

At 9:38 -0500 1/25/08, Edward Lewis wrote:
>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.
>
>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 then?
>
>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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20080129/e92ca442/attachment.html>