Subject: Re: A6/DNAME usage guidelines and limits

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Apr 2002 13:07:51 -0800

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

what the world is coming to is that applications (by which i include stub
resolvers) will have to have available to them a far simpler protocol/API
than full DNS.  is that what we all really want?  what it would look like
is "applications make TSIG'd AAAA and A queries of their local recursive
name server" and "recursive name servers will use EDNS0, DNSSEC, and A6."

that doesn't cover the DNAME/PTR issue but that falls out naturally.

that doesn't cover the synthesized AAAA issue but that also falls out
naturally.

the question is, before we go into detail on it, is: have we really and
truly put so much mass into the DNS protocol that most applications (and
most stub resolvers) cannot reasonably be expected to speak it?

once we know that, we know how to proceed.

--
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: Carl Perry <[email-masked]>
Date: Wed, 3 Apr 2002 19:31:08 -0600

> most stub resolvers) cannot reasonably be expected to speak it?

I believe so.  I don't know about you, but my cell phone has a hard
enough time not dropping packets and doing name queries as it is - I
would hate to see it do a six-level A6 query with DNSSEC on.

I think we at least have to be able to support a "slimmer" subset of the
entire DNS system for tree-tip devices.  I see technologies like DNSSEC
and A6 as server/cache level technologies.  Let's face it, if your
client resolver supports DNSSEC and your caching server doesn't - you
are not making any gains on the anti-spoofing front.  Sure, a client
_can_ support DNSSEC if it wants to, but I don't think it should be a
requirement.

On top of the "easier to implement a resolver" front, there is also the
improvements to the end user.  With any luck, your DNS caching server
has a lower latency connection to the Internet than your 56k modem.  So,
one can hope that if the server with the better connection does the
bulk of the network-intensive legwork and then caches the result you are
going to have a much better response time than if you did it yourself.
You'll have an even faster lookup time if some of the A6 tiers are
already cached as well.

What do you think?  

-- 
	-Carl Perry
	[email-masked]

"Deliver yesterday, code today, think tomorrow."

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Apr 2002 16:12:48 -0800

> would hate to see it do a six-level A6 query with DNSSEC on.

does that mean that we as protocol designers have failed somehow?  (this
was not the anticipated mode when all this technology was planned out.)

> Let's face it, if your client resolver supports DNSSEC and your
> caching server doesn't - you are not making any gains on the
> anti-spoofing front.

that, at least, is untrue.  a client which fully implements DNSSEC can
know whether its forwarders are corrupt -- at least in the case where
the data has been signed.

> Sure, a client _can_ support DNSSEC if it wants to, but I don't think
> it should be a requirement.

what this means is the "light weight resolver" protocol we did for BIND9
was a complete waste of time, and simple AAAA and A queries should have
been used.  (right?)

> What do you think? =20

i think it's very late in the game to be holding this conversation.

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Apr 2002 19:08:17 +0200

<chair hat off>

> does that mean that we as protocol designers have failed somehow?

yes, we allowed an overly-clever set of proposals from the ipv6 community
go to far for too long.

> was a complete waste of time, and simple AAAA and A queries should have

right

> i think it's very late in the game to be holding this conversation.

agree.  so let's close this off already.  pass the document.  but i would
add completely ditch dname as well.

randy

---

From: Greg Hudson <[email-masked]>
Date: 04 Apr 2002 13:23:33 -0500

[ post by non-subscriber ]

> most stub resolvers) cannot reasonably be expected to speak it?

It seems to me that we reached that point a long time ago.  In
particular, Unix stub resolvers won't follow CNAME chains by doing
multiple queries; they rely on the recursive resolver to go out and
fetch the CNAME chain and the terminating canonical record.

If there were no installed base, and having A6 were an external
constraint, I would say that we should make recursive resolvers go out
and fetch A6 records to make a complete chain, so that stub resolvers
can still make only one query.  Since there is an installed base of stub
resolvers which do AAAA queries, it seems we would have to require the
less elegant approach of AAAA synthesis.  But it's the functionally the
same.

(I'm not very fond of A6, but I've made all those arguments in the
past.)