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


To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
cc: "Christian Huitema" <huitema@windows.microsoft.com>, "Paul A Vixie" <vixie@vix.com>, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From: Robert Elz <kre@munnari.OZ.AU>
Date: Thu, 09 Aug 2001 16:41:41 +0700
In-Reply-To: <20010809092252.3EBEA7BA@starfruit.itojun.org>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

    Date:        Thu, 09 Aug 2001 18:22:52 +0900
    From:        Jun-ichiro itojun Hagino <itojun@iijlab.net>
    Message-ID:  <20010809092252.3EBEA7BA@starfruit.itojun.org>

  | 	as I repeatedly commented, AAAA synthesis does not really work in the
  | 	wild due to the deployment hurdles and ambiguity as to who is going
  | 	to synthesize.

There's no ambiguity.   It gets done at your local resolver/cache.

For deployment, yes, to make use of A6 lookups code is going to need to
be deployed - if that means just that it is required that you deploy a
back end resolver that understands A6 and AAAA synthesis, then that seems
like a fairly easy upgrade path (much easier than if all the clients had
to be upgraded).

And yes, as you have pointed out, if the local back end resolver doesn't
understand A6, and AAAA synthesis, then AAAA queries will still get
transmitted to the rest of the net.  In the short term, the existing AAAA
records can just be returned, that's the first step of transition.
But it also does no great harm if some other server does AAAA synthesis
on your behalf (you'll have no good way to verify the data, but the chances
are that you wouldn't be bothering even if you had).

kre



Home | Date list | Subject list