Re: (ngtrans) DNSEXT NGTRANS Joint meeting DRAFT minutes

[Johan Ihren <johani@autonomica.se>]

Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:

> >>>>> "Olafur" == Olafur Gudmundsson <ogud@ogud.com> writes:
>     Olafur> Steve Deering noted that we have AAAA, and going to A6 0 is a "no
>     Olafur> brainer", but if it is lots of work to change to A6 for a limited
>     Olafur> value, is it worth it? 
> 
>   While going to A6 0 is simple, if the stub resolver implementers
> simply ask for "A6 0", i.e. ask for A6 instead of AAAA as if it was
> AAAA, then if we come up with a new situation that *requires* A6 X
> (X!=0), then we are in trouble.

Which is exactly why I think that the claim that A6 0 is equivalent to
AAAA is wrong. 

We should keep the AAAA as "what stub resolvers use" and synthesize it
from a DNS infrastructure built from A6. Non-stub resolvers have a
choice of whether to deal with possible chains by querying for an A6,
or stay with the easier-to-digest form by querying for a AAAA.

I really think that the humming in the room was based very much upon
fears of delaying deployment further, regardless of technical
solution. And a feeling that A6, even in the form of A6 0, would do
that (which is correct).

Since AAAA synthesis was presented as a transition mechanism, not the
"final solution" those concerns won out.

>   Secondly, those code paths where X!=0 will not get tested even if
> they are written, and security may be involved, and wouldn't a
> buffer overflow bug in a stub resolver be pretty!

By staying with the AAAA for stub resolvers this will simply not happen.

Regards,

Johan Ihren
Autonomica

PS. A popular description of the differences between AAAA and A6 is to
claim that AAAA is optimized for read, while A6 is optimized for
write. Possibly a better way out putting it would have been to say
that AAAA is optimised for the (stub) resolver and end applications,
while A6 is optimized for the nameserver and DNS infrastructure. 

By keeping AAAA synthetization as a permenent mechanism rather than as
a transition issue it would be possible to optimize for both...