Re: [dnsext] draft-li-dnsext-ipv4-ipv6 -- a more versatile proposal

[Paul Vixie <vixie@isc.org>]

> Date: Fri, 6 Nov 2009 16:52:14 -0500
> From: Andrew Sullivan <ajs@shinkuro.com>
> 
> > what a terrible idea.  we're not going to add yet another query before
> > the start of every tcp/ip session.  the way to handle this is to
> > include AAAA as additional data in A responses, and include A as
> > additional data in AAAA responses.
> 
> So why doesn't this happen today?  What caused us not to choose that path
> in the past?  (Something must have, but I've been unable to figure out
> what.  I'd sure like to know, however, because I'm busy having arguments
> over in behave about a related topic.)

because i didn't think about it or propose it during DNSIND's review of the
draft of RFC 1886, and then when i did propose it there was a Strong Desire
on the part of All Parties to Be Done and so we didn't want to pull the
covers off.  also, it was widely recognized that additional data could be
added at any time, and so the thought was, somebody would write it up later,
there was no reason to hold up the current draft.

nobody has written it up.

now, in the time since then, kaminsky showed us the nonwisdom of caching any
data other than the direct response to the question you asked.  so if we 
were to write this up today, we'd say, it has to be an authoritative answer
and the owner name has to exactly match the answer name.  or something.

(i sort of wish we had multiple question support.  if all the qnames are the
same, and all the qclasses are the same, and all the qtypes are different,
then we could reasonably fill the answer section with multiple rrsets.  would
have been nice.  at this point it would draw a lot of FORMERR responses and
so doing it would amount to another kind of pairwise protocol negotiation --
which if we're going to do we should do as part of EDNS somehow.  i digress.)