Re: morishita-dnsop-misbehavior-against-aaaa

[Paul Vixie <vixie@vix.com>]

other misbehaviours in the ipv6/dns transport arena include interrim bind8/9
behaviour (which will be fixed in the next releases of each, possibly with
patches) is the aggressive search for "missing" glue.  let me explain, and
then someone else can decide whether this needs to be added to some draft's
list of things that an implementation ought not do.

this has to do with the behaviour of caching/forwarding resolvers, which BIND
terminology calls "recursive name servers".

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.)

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.

is this an appropriate topic for the morishita or durand drafts?
-- 
Paul Vixie
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.