Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

[Brian E Carpenter <brian.e.carpenter at gmail.com>]

FWIW, I think either of these suggestions would have a better
chance of deploying than a new RR type. Think about the
ill-fated A6 record.

Incidentally, the draft doesn't mention whether reverse
entries are also needed.

   Brian

On 2009-11-07 06:14, Andrew Sullivan wrote:
...
>     a.  Add the "base" A record to the Additional section
> 
> If a DNS64 server were to provide synthetic AAAA records and include
> the corresponding A record in the Additional section, a DNS64-aware
> querying client could take the presence of that A record as a hint
> that there might be more to the answer than meets the eye.  It should
> be able to extract the equivalent IPv4 address from the AAAA record,
> and thereby infer that the AAAA is synthetic.  A dual-stack host could
> then just use the A record instead.  A signficant disadvantage of this
> approach is that the Additional section is the first thing to be
> truncated when a response gets long, so it's possible that the
> Additional section won't have the "base A" when it's needed.  In
> addition, a site publishing statically-configured synthetic AAAA
> records can do so with a bog-standard DNS server, and there'd be no
> way to tell that the records are in fact synthetic, so such servers
> wouldn't include the A record without some kind of additional work.
> 
>     b.  Use an EDNS0 option to signal DNS64 awareness
> 
> If we defined an EDNS0 option (call it the SY bit, for synthetic) to
> signal DNS64 awareness, then either an initiator or a recursor could
> signal its ability to understand DNS64.  A server receiving such a
> signal could include the Pref64::/n in the answer using a new RRTYPE
> (say, PREF64).  That prefix could then be stripped off the AAAA by
> whatever node got the answer, and the resulting IPv4 address could be
> used as appropriate.  One disadvantage of this approach is that it
> requires participating nodes to upgrade in order to achieve the
> functionality; but in fact, A64 also requires that, and so the effect
> is no worse.  Moreover, it does not introduce new queries or anything
> of the sort to the mix, so we aren't increasing the number of queries.
> 
>     4.  Conclusion
> 
> Even if this is a problem that needs to be solved -- a position that
> is not obvious to me -- it is not plain that A64 solves it.  Even if
> it does solve it, it solves it at a very great price, and a price that
> will be paid long after A64 is broadly useful.  In any case, there are
> other ways to solve the same problem, and they are less disruptive
> than adding A64 to the DNS.  Therefore, I do not think the A64
> proposal should be adopted.
> 
> Best regards,
> 
> Andrew
> 
>