Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

>> I see a big difference between deprecating/moving to historic and changing
>> status to experimental. Experemental implies further development.
>
>I don't see that difference here.  Just as "let's let the market decide"
>really just means "let's do whatever Microsoft wants", so it is that "let's
>make it experimental" really just means "let's move on."  (I find it amusing
>that SRV was experimental but that Microsoft's use of it pulled it forward.)
>
>I was not able to be in London, but had I been there my comments would've been:
>
>	Let's not expect stub resolvers to do the caching necessary to
>	understand either A6 or SIG/KEY -- those are things which servers
>	ought to use to talk to other servers.  Stub resolvers making
>	recursive requests of their name servers should be using AAAA and
>	TSIG.  AAAA synthesis of underlying A6, and TSIG to protect
>	verified KEY/SIG data for the last mile, is all a client needs.
>	Every argument against SIG/KEY or against A6 comes down to either
>	the caching problem or the complexity problem, and if we insulate
>	the end-stations from those problems, the arguments are reduced to
>	things which authority-side tools can be made to cope with.

	i have a major concern with AAAA synthesis - which is, it is unclear
	as to who needs to AAAA synthesis.  the concern is mentioned
	in my draft.

	- you can't guarantee every first-hop DNS server to do AAAA synthesis.
	- if anyone does not, AAAA queries go into non-first-hop DNS servers
	  by recurse (imagine when pre-BIND9/non-BIND name server is used
	  as the first-hop name server).

	therefore, AAAA synthesis basically asks everyone to run AAAA and A6
	in parallel, which raises a lot of concerns (query delays if you query
	both, database maintenance cost if you maintain both in zone, no-sign
	if you synthesize, and a lot of others).

itojun