Subject: Re: A6/DNAME usage guidelines and limits

From: Carl Perry <[email-masked]>
Date: Wed, 3 Apr 2002 15:59:42 -0600

On Tue, Apr 02, 2002 at 04:47:51PM +1000, Nathan Jones wrote:
> AAAA Synthesis
> 
>    [RFC2874] discusses making a transition from AAAA to A6 by automatically
>    generating AAAA records from A6 records. Such AAAA synthesis should be
>    viewed as an integral part of DNS support for IPv6, rather than purely
>    a transition mechanism. 
> 
>    A nameserver that offers recursive DNS resolution SHOULD be able to
>    generate AAAA records in response to AAAA queries. This allows devices
>    and other hosts to use a lightweight stub resolver that does not need
>    to know about A6.

I think this is the way to go.  A6 is a good idea, in general.  However,
having the resolver on a client have to perform multiple queries to get
a single name resolved is not a good idea.  End-points in the DNS tree
should be able to ask DNS server/cache systems to provide them an AAAA
answer to a name.  The server/cache should be able to handle AAAA and
A6, and convert A6 records to AAAA responses accordingly.  This gives
the ability for "easy" address renumeration, and a thinner client
resolver profile.  In short, it's the best of both worlds.

-- 
	-Carl Perry
	[email-masked]

"Deliver yesterday, code today, think tomorrow."

---

From: Carl Perry <[email-masked]>
Date: Wed, 3 Apr 2002 16:12:47 -0600

-- 
	-Carl Perry
	[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Derek Atkins <[email-masked]>
Date: 04 Apr 2002 10:30:47 -0500

> resolver profile.  In short, it's the best of both worlds.

Note that there is no way to authenticate a AAAA-synthesis.  You can
require TSIG between the 'lightweight resolver' and the synthesizing
resolver, I suppose, and require the synthesizing resolver to verify
the DNSSEC response(s).  However as an application writer I can
envision endpoint applications (users of DNS) that would want access
to the DNSSEC responses themselves.  How would you do that with AAAA
synthesis?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Robert Elz <[email-masked]>
Date: Thu, 04 Apr 2002 23:00:40 +0700

Date:        04 Apr 2002 10:30:47 -0500
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | However as an application writer I can
  | envision endpoint applications (users of DNS) that would want access
  | to the DNSSEC responses themselves.  How would you do that with AAAA
  | synthesis?

Clearly you wouldn't.   You (the application writer) will just send
a query for A6 records instead.   Then you'll get the A6 records, and
their SIGs, returned to you.   AAAA synthesis is an option, one which
is liklely to be heavily used - using it will never be a requirement.

If your application can handle chasing the SIG/KEY/DS/NXT/... stuff to
validate the records, it can certainly also do the extra triviality of
chasing the A6 chain, which is much simpler.

kre

---

From: Derek Atkins <[email-masked]>
Date: 04 Apr 2002 11:55:12 -0500

> chasing the A6 chain, which is much simpler.

What happens if the A6 chain requires N hops, and I get the first
three and then fail?

I would like to see a situation where the client makes 1 request and
gets a response with the whole A6 chain.  This solves the latency
issues in low bandwith situations (like cell phones) but still allows
you to use A6.

Here's an alternative proposal: is there some way to require that a
nameserver for an A6 record be able to recurse up the chain and act as
a cache for the rest of the chain?  Perhaps the nameserver is required
to always cache complete A6 chains?  That way the client need only
make one request and the responding server will follow the chain?

Here's my reasoning: A server that is authoritative for the end-host
is the one going to answer the _first_ entry in the A6 chain.  If that
server _always_ has the rest of the chain cached, and can respond with
the whole chain in one answer, then the only difference between AAAA
and A6 is the packet size (from an application point of view).

For example, assume that MIT.EDU deploys A6 records of the form

        $ORIGIN provider.net.
        mit A6 0 <>

        $ORIGIN mit.edu.
        host A6 48 mit.provider.net. <> 

When the resolver asks the MIT nameservers for "host.mit.edu. A6" the
server can respond with the following in a single packet:

        host.mit.edu A6 48 mit.provider.net. <>
        mit.provider.net A6 0 <>

Obviously this is an implementation issue, not a protocol issue.  But
it would solve some of the problems that people have with A6, namely
the relatively-unbounded number of round-trips required to resolve an
A6 request and the possibility of failing partially through a request.

I admit that this proposal does add complexity to the nameserver
implementation, because they must be aware of all A6 chains and "keep"
them in the cache..  Or, alternately, the nameserver must be required
to recurse on their own A6 records, even if they don't necessarily
recurse.

-derek

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Apr 2002 22:47:37 -0000

[ post by non-subscriber ]

Carl Perry writes:
> A6 is a good idea, in general.

No, it isn't. See http://cr.yp.to/djbdns/killa6.html. The problems with
A6 are much bigger than the cost of an extra loop in (stub) clients.

The fundamental problem is that A6's cross-server indirection is being
performed in the foreground instead of in the background. We already
have reliability problems from foreground cross-server indirection in NS
and CNAME, even though NS and CNAME don't _encourage_ cross-server
indirection the way that A6 does.

For people who want separate signatures on chunks of an address: Fine.
Put separate signatures on chunks of an address. This is compatible with
background indirection.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago