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

Edward Lewis Ed.Lewis at neustar.biz
Fri Jan 25 14:38:02 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.

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.



More information about the dns-operations mailing list