Re: morishita-dnsop-misbehavior-against-aaaa

[JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>]

>>>>> On 19 Nov 2003 01:10:12 +0000, 
>>>>> Paul Vixie <vixie@vix.com> said:

> if you learn of the existence of an NS RRset, most likely due to reception
> of a delegation response, but you do not know all of the glue (A and AAAA)
> for those NS.NSDNAMEs, then it's probably best that you go out and fetch it
> so that your own subsequent emissions of this NS RRset can include full glue.
> (a common cause of knowing an NS RRsets without full glue is "truncation".)

> however, it's important not to be overly aggressive in fetching such glue,
> where one definition of "overly" is "trying to fetch what doesn't exist."
> interrim (current, that is) BIND8 and BIND9 are overly aggressive, in that
> they will search for AAAA whenever its absence is felt during the 
> construction of an additional data section.  (and the root servers cried.)

Could you be more specific on "whenever its absence is felt"?  As far
as I can see in the code, BIND9 seems to limit itself about fetching
missing glues when it knows the glue RR for the particular type
doesn't exist (that is, the "NOERROR and an empty answer" case).  So,
if an appropriate negative TTL is provided, the fetching should be
leveraged.

I'm also not sure if this really makes the root servers cry.  Consider
the typical case (as of today) where an authoritative server only has
an IPv4 address (and the corresponding A RR is provided, of course).
When a recursive name server first tries to fetch A/AAAA RRs for the
authoritative server, it may ask a root server.  However, once the
recursive server knows the IPv4 address of the authoritative server,
succeeding queries for AAAA RRs will be directly sent to the
authoritative server, without making additional queries to root
servers (until the TTL for the cached A RRs expires).

A subtle situation may happen if the authoritative server "misbehaves"
as described in the morishita draft, though.  For example, if the
server ignores queries for AAAA RRs, the recursive server may try to
fetch the AAAA RRs in an "overly aggressive" way.

> the right thing to do is query for both A and AAAA if you lack both A and
> AAAA.  this can lead to the unfortunate corner case where silent truncation
> dropped an AAAA (or an A) RRset but left the A (or AAAA) in place.  it's
> probably important to recommend the use of round robin to "spread the pain"
> during such corner case events.  it's also important to prioritize the glue
> so that the kind most likely to be missed if absent (A RRs) are done first,
> since whenever AAAA RRs are going to be useful, EDNS0 will have been used.

I'd like to make the above points clear first, but anyway, another
possible way would be to introduce a timer before re-fetching missing
glues.  I think BIND[89] already takes this approach for the case
where a remote server that did not support EDNS0 has then supported
the extension.

> is this an appropriate topic for the morishita or durand drafts?

I don't think the morishita draft is an appropriate of the issue
itself, since the draft is concentrating on how an authoritative
server (badly) responds to AAAA (or non-A in general )queries.
However, it might be useful to mention the issue as an effect of the
misbehavior (i.e., the subtle situation I mentioned above).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.