To:
Robert Elz <kre@munnari.OZ.AU>
Cc:
ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org
From:
Alain Durand <Alain.Durand@sun.com>
Date:
Tue, 14 Aug 2001 22:55:37 -0700
In-Reply-To:
<15663.997800535@brandenburg.cs.mu.OZ.AU>
Sender:
owner-dnsop@cafax.se
Subject:
Re: (ngtrans) Joint DNSEXT & NGTRANS summary
At 09:48 PM 8/14/2001 +0700, Robert Elz wrote: > >No, assuming you're right, long term what will happen is that people >will lament that the wrong decision was made in 2001, but regret that >there's no way to transition any more, the combination of resolvers >doing only AAAA lookups, and servers providing only AAAA records, means >there's no clean way to get out from under (sure, servers could provide >A6 records as well, but they'll have to keep providing AAAA records >forever to keep the old resolvers happy, and resolvers could do A6 lookups >but they'd have to fall back on doing AAAA so they can find names that >are only available that way - given that AAAA would have to remain, and >resolvers would have to do lookups of it, just for practical reasons, >there's no way to actually transition to A6). Doing AAAA synthesis at the resolver side helps a stub resolver that knows only about AAAA to get data from servers that knows only about A6. This transition scenario will work if we can upgrade the resolvers at the same time we introduce A6 in the servers. (note that upgrading the resolvers is a much simpler task than upgrading all the stub resolvers) Still, it may not be possible to upgrade them all before we introduce A6 in some servers. So what you are highlighting is the need for servers that are populated with A6 to answer resolvers (not stub-resolver) that know only about AAAA. Of course, as you mentioned, servers could be manually populated with AAAA at well as A6, but there are other possibilities. In other words, we have to explore AAAA synthesis done at the server side: - the server could automatically generate all the corresponding AAAA records when loading its A6 database. Of course, the missing pieces will have to be provided. - the server could generate AAAA on request. Of course, there are drawbacks and issues with such mechanisms and more study will have to be made to understand them, but they are transition mechanism and as such, do not need to be perfect. The point i'm trying to make is that by combining AAAA synthesis at the server side with AAAA synthesis at the resolver side, we may have a way to transition from an all AAAA world to a world with a mix of AAAA and A6 if/when we need it. Note also that such techniques would have to be used now if we decided to move to A6 today. - Alain.