[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Cc: "Tony Hain" <alh-ietf@tndh.net>, "Nathan Jones" <nathanj@optimo.com.au>, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From: Johan Ihren <johani@autonomica.se>
Date: 15 Aug 2001 11:57:01 +0200
In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 17:57:32 +0900"
Sender: owner-dnsop@cafax.se
User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

Jun-ichiro itojun Hagino <itojun@iijlab.net> writes:

Hi Itojun,

> >I'm pointing out that due to the configuration change that will follow
> >from deployment of v6 roots it will be comparatively easy to reach all
> >the caching resolvers (i.e. name servers) on v6 transport to ensure
> >that they all do AAAA synthesis.
> 
> 	isn't it just a root.hint change, not a server replacement?

Well, if you are running in a forwarding configuration *with your
present server* and replace the root.hint file with one that includes
v6 glue for one or several roots not much will happen. So there is no
point to it.

Because you are using a forwarding configuration.

However, what you want is a root accessible over v6 transport (and of
course all the TLDs, etc, etc) so that you can move away from your
forwarding configuration.

However, to avoid walking around in a barren wasteland of almost no
DNS hierarchy initially I strongly suspect that you would like some
sort of fallback mechanism so that you can still get to the data that
is presently only available over v4 transport. 

But to do that you *will* need a server replacement, since no server
deployed does that today.

There are various icky schemes for doing such transport bridging
(Alain Durand and I have spent some time in that mess and there is a
draft outlining some of the problems). All of these schemes are ugly,
but without something like that I see little point to the v6 roots
that you want.

So, I still claim that the time of deployment of v6 glue for the first
root is a "magic date" since that will initiate a configuration change
and in all likelihood a server replacement for all the v6 caching
resolvers that want to utilize this v6 root for anything useful.

Look at it as a synchronization barrier for IPv6 DNS functionality.

Johan Ihren


Home | Date list | Subject list