Subject: Re: A6/DNAME usage guidelines and limits

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Apr 2002 08:50:48 -0800

> 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?

in this model, you wouldn't.  QTYPE=AAAA && RD=0 would be invalid.

--
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: Paul Vixie <[email-masked]>
Date: Thu, 04 Apr 2002 09:05:39 -0800

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

then you lose, i guess.  the hope is that once this situation is widely
known, then improved caching robustness will be seen by network operators
as a key way to increase their overall network robustness.

> 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?

in rfc2317 we "solved" this by recommending that servers for intermediate
zones also slave the delegated zones.  that way iteration would likely not
occur beyond the octet boundary.

that's probably a wise practice for A6 chain intermediaries, as well.

> ... 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.

agreed.  and as shown by rfc2317's success, it's not all that hard to do.

> 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.

well, there's no way to require an authority server to fetch glue, though
many will.