<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [dns-operations] Reporting glue as authoritive
data --</title></head><body>
<div>I wanted to update my first response to the thread.</div>
<div><br></div>
<div>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).</div>
<div><br></div>
<div>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 "<tt>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."</tt></div>
<div><br></div>
<div>Where $brand_name is not BIND.</div>
<div><br></div>
<div>At 9:38 -0500 1/25/08, Edward Lewis wrote:</div>
<div>>Although I work for the company that bought up Ultra, I
didn't know<br>
>they were doing this until Monday. Independently, and
now<br>
>ironically, I was about to suggest the IETF document responses
that I<br>
>have personally labeled 'hybrid' - combination answer and
referral.<br>
><br>
>I wouldn't call this a bug in Ultra. I don't know the reason
they<br>
>are doing this but I think (think) is it trying to copy that
actions<br>
>of the .com servers (ATLAS).<br>
><br>
>Try this 'dig ns1.crsnic.net. @f.gtld-servers.net.'<br>
><br>
>What makes this a hybrid:<br>
><br>
>Note the lack of a AA bit.<br>
>Note the presence of an answer record.<br>
>Note the lack of an RA bit.<br>
><br>
>If the AA bit as here, it's an answer. If the answer section
was<br>
>empty, it would be a referral. If it were obviously a
recursive<br>
>response, it would like it was a cached answer.<br>
><br>
>I've had this discussion before. The below message was a
private<br>
>message sent in mid 05 to someone to explain why hybrid answers
exist<br>
>and the niche they fill. If I can find a public archive
version, as<br>
>I refer to RIPE's dns-wg in the message, I'll post a link to
it.)<br>
><br>
>Date: Tue, 14 Jun 2005 09:32:13 -0400<br>
>From: Edward Lewis <Ed.Lewis@neustar.biz><br>
>Subject: Re: 4.3.2 and NS responses<br>
>Cc: Edward Lewis <Ed.Lewis@neustar.biz><br>
><br>
>>So, this is was Atlas does, but it is not what BIND and NSD do
and what I<br>
>>believe is correct and useful. BIND and NSD would respond with
a vanilla<br>
>>referral (NOERROR/NODATA), but wouldn't they violate the 4.3.2
algorithm then?<br>
><br>
>The dilemma you see is "protocol definition" vs.
"operational<br>
>experience." I'll cut to some salient points and spare
you the<br>
>melodrama of it all.<br>
><br>
>I call the pseudo-cache-plus-referral response a
"hydrid." The<br>
>hybrids are not part of the DNS specification and will cause
problems<br>
>when we extend the basic DNS for something like DNSSEC.
Another<br>
>reason against the hybrids is that the cause a higher
credibility<br>
>assignment to otherwise non-credible data. Non-credible because it
is<br>
>coming from a "second source" (the .com/.net registry
database). The<br>
>higher credibility is that because the data is in the answer
section,<br>
>it is assigned more credibility than glue.<br>
><br>
>['08 note - in 05 I was using mistakenly using the word
"credibility"<br>
>instead of "trustworthiness" as defined in RFC
2181.]<br>
><br>
>For good reasons, the hybrids are not part of the architecture of
the<br>
>DNS. They only work if the out of band management is
kept up to<br>
>date (the host objects) and so long as we don't extend the DNS
in<br>
>certain ways - like DNSSEC does.<br>
><br>
>However, there is a whole 'nuther reality at work. These
hybrids are<br>
>a crutch for bygone but still in use BIND implementations and
the<br>
>hybrid answers do cut down on extraneous DNS lookups.<br>
><br>
>In older BINDs, I think up until BIND 8.3 +/- .1, BIND's
software<br>
>architecture lacked a decent "event manager." BIND
could iterate for<br>
>answers, but if it got too sidetracked it would develop amnesia
and<br>
>forget why it asked for something. A symptom of this would
be "ask<br>
>once, get SERVFAIL, ask again, get answer." This was a
particular<br>
>problem with the ARIN portion of in-addr.arpa (probably as well
for<br>
>the other RIRs) because ARIN complicated things by using the
"vanity"</div>
<div>>name server names. (This is why I wanted to
argue/discuss the issue<br>
>on dns-wg.)<br>
><br>
>True, ISC has now fixed this, but old BINDs to live on.
Nevertheless,<br>
>new BINDs will issue fewer queries with the hybrids still in
place<br>
>because BIND keeps plugging away to get addresses for all the
NS<br>
>records in a referral. BIND apparently isn't satisfied with
glue.<br>
><br>
>So that's why the hybrids are there, in a nutshell. I don't
know of<br>
>any quantitative work on the issue. I fell onto it when ARIN
removed<br>
>some name servers for which the hybrid answers were in effect,<br>
>blowing some users out of the water. At the time I thought
"we've<br>
>done nothing wrong" operationally, followed up by doing
packet<br>
>traces, and confirmed this with the Verigisn engineers.
That's how I<br>
>"discovered" this.<br>
><br>
>--<br>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<span
></span>=-=-=-=-=-<br>
>Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
>NeuStar<br>
><br>
>If you knew what I was thinking, you'd understand what I was
saying.<br>
><br>
><br>
>At 9:48 +0000 1/25/08, Lutz Donnerhacke wrote:<br>
>>I assume the DNS implementation on ultradns is buggy.<br>
>>It respond the glue record in the answer section instead of
the additional.<br>
>><br>
>>; <<>> DiG 9.4.2 <<>> dns1.fqdn.org
@tld1.ultradns.net<br>
>>;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2,
ADDITIONAL: 1<br>
>><br>
>>;; QUESTION SECTION:<br>
>>;dns1.fqdn.org.<x-tab>
</x-tab><x-tab>
</x-tab><x-tab>
</x-tab>IN<x-tab> </x-tab>A<br>
>><br>
>>;; ANSWER SECTION:<br>
>>dns1.fqdn.org.<x-tab>
</x-tab><x-tab>
</x-tab>86400<x-tab>
</x-tab>IN<x-tab>
</x-tab>A<x-tab>
</x-tab>89.107.65.75<br>
>><br>
>>;; AUTHORITY SECTION:<br>
>>fqdn.org.<x-tab>
</x-tab><x-tab>
</x-tab>86400<x-tab>
</x-tab>IN<x-tab>
</x-tab>NS<x-tab>
</x-tab>dns2.fqdn.org.<br>
>>fqdn.org.<x-tab>
</x-tab><x-tab>
</x-tab>86400<x-tab>
</x-tab>IN<x-tab>
</x-tab>NS<x-tab>
</x-tab>dns1.fqdn.org.<br>
>><br>
>>;; ADDITIONAL SECTION:<br>
>>dns2.fqdn.org.<x-tab>
</x-tab><x-tab>
</x-tab>86400<x-tab>
</x-tab>IN<x-tab>
</x-tab>A<x-tab>
</x-tab>208.83.233.58<br>
>><br>
>>_______________________________________________<br>
>>dns-operations mailing list<br>
>>dns-operations@lists.oarci.net<br>
>>http://lists.oarci.net/mailman/listinfo/dns-operations<br>
><br>
>--<br>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<span
></span>=-=-=-=-=-<br>
>Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
>NeuStar<br>
><br>
>Think glocally. Act confused.<br>
>_______________________________________________<br>
>dns-operations mailing list<br>
>dns-operations@lists.oarci.net<br>
>http://lists.oarci.net/mailman/listinfo/dns-operations</div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
NeuStar</div>
<div><br></div>
<div>Think glocally. Act confused.</div>
</body>
</html>