Subject: (IPng 6729) DNS implementation of IPv6 A6 and other new features

From: [email-masked] (Peter R. Tattam)
Date: Thu, 12 Nov 1998 16:38:09 +1100

These are some concerns that have been brewing over the last couple of weeks.  
Feel free to shoot me down in flames if I'm out of place or its all been 
discussed before.

While browsing the draft about the revised method of doing name lookups, I 
became concerned about the A6 proposal (standard now?)

The new A6 introduces some inefficiencies that could cause reliability 
problems as it can potentially require more than one query to resolve a host 
name.   The initial AAAA only requires a single query which would be atomic 
but an A6 will require multiple queries or multiple responses to a query 
possibly in a recursive manner.  Caching may help, but adds a layer of 
complexity and uncertainty into the resolvers.  Many small stacks (like our 
own) do a fresh query for each name resolution.  While adding the extra 
records to complete the full recursive lookup of the A6 results can be added 
in the DNS record, there is a risk of incomplete DNS records, and also of 
cache entries being stale causing havoc.

Also, while compression and the regular DNS method of string handling will 
reduce the size of the queries it's likely to be larger than the equivalent 
AAAA entry for the address.

For these reasons, I feel that the deprecation of AAAA records in favour of A6 
records is a "bad thing".

Basically, the issues boil down to increased network usage and reduction in 
reliability due to the increased complexity, and the added burden on TCP 
stacks and the bottom of the chain.

Considering that resolution of names to addresses is one of the most 
fundamental operations in the use in the internet, this may make or break the 
adoption of IPv6 if it is insisted that we deply this system in favour of AAAA 
records.

I propose that if you insist on keeping the A6 structure, that it be used for 
inter server communication and management while AAAA continue to be fully 
supported at leaf sites, with servers performing the necessary translations.

I do agree however that the reverse lookups do need work as the existing 
system is indeed quite ugly, but again the adoption of a recursive style 
system in favour of a flat single entry style lookup suffers from the same 
design flaws as mentioned earlier.

Finally, I must say that the implementation details aren't impossble or even 
difficult, but rather my concerns are primarily for performance reasons.

Those of you who manage a busy ISP or network would understand that minor 
inefficiencies grow into large ones as the size of networks scales.

I'm really puzzled that these issues weren't raised in the draft.

Peter

--
Peter R. Tattam - Managing Director          
Trumpet Software International Pty Ltd.
Phone: +61-3-6245-0220     Fax: +61-3-6245-0210
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Fri, 13 Nov 1998 01:11:31 +1100

Date:        Thu, 12 Nov 1998 16:38:09 +1100
    From:        [email-masked] (Peter R. Tattam)
    Message-ID:  <[email-masked]>

  | The initial AAAA only requires a single query which would be atomic

Only if one presumes a dumb stub resolver using a smarter host to do the
name resolution for it.   If the resolver is going to do the entire
resolution on its own, it will need be able to do multiple queries to chase
the NS records from the root to the zone of interest.

  | Also, while compression and the regular DNS method of string handling will 
  | reduce the size of the queries it's likely to be larger than the equivalent 
  | AAAA entry for the address.

I think this is likely to just the opposite where it matters.    That is,
for a minimal sized AAAA query, yes, it is possible that an A6 query might
be larger.   But you can't know that an AAAA query will result in a minimal
sized answer, so you need to allow for more than that.  Once the AAAA result
starts getting potentially larger (that is, when there are multiple records
to be returned), the likelihood is that the A6 result will actually be smaller
than the AAAA response.   It seems to me that this is a good result - what
happens to small responses, for which more space needs to be allowed anyway
isn't so important, but keeping large responses smaller, so they will keep
fitting in a UDP response, is important.

  | Considering that resolution of names to addresses is one of the most 
  | fundamental operations in the use in the internet, this may make or break
  | the  adoption of IPv6 if it is insisted that we deply this system in
  | favour of AAAA records.

You mean instead of AAAA records.   All of these issues are judgement calls.
Personally, I feel that the increased flexibility of A6, especially when a
renumbering of a site is required, means that because A6 is used will make the
whole thing practical in a reasonable way, especially for larger sites, and
be one of the big selling points of IPv6 over IPv4.   I know I would hate to
think about renumbering our site (the DNS is under the control of a diverse
group of people) under v4, but with v6, and A6, where we could all simply defer
to a single instance of the base (upper bits) part of the address, the
DNS changes would be the easiest part of any renumbering, instead of one
of the harder parts.

  | I propose that if you insist on keeping the A6 structure, that it be used for 
  | inter server communication and management while AAAA continue to be fully 
  | supported at leaf sites, with servers performing the necessary translations.

It isn't clear just what that would mean - DNS servers (as they are defined
in the DNS) can't do it, for all kinds of reasons that we discovered when it
was originally proposed that it be done exactly that way.

However, I suspect that you really mean that the back end part of a
stub-resolver / real-resolver split (the real resolver part) do the A6
processing (as they do NS chain chasing, CNAME handling, etc) and return
just a synthesised AAAA record to the stub resolver.    That might be
a reasonable approach - the only difficulty is in having the back end part of
the resolver knowing that the particular query it has received is for a
stub resolver rather than a random query from some other source.  As things
are currently done, there is no difference - all queries look the same.

Perhaps if TSIG is in use (which it ought be between stub resolvers and
their back ends, in the future) then that mighht be enough (the TSIG
association can be configured that way) to provide this info, and the
back end would know to allow AAAA records to be synthesised out of A6
responses, and handed back complete.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 16 Nov 1998 16:09:07 +0100

>was originally proposed that it be done exactly that way.

could you rehash the reasons, please?
This wasn't mentioned when the AAAA/A6 coexistence/transition was being
muttered about (too few messages to call a debate :-) in NGTRANS.

(detecting the difference between a dumb stub and a smart resolver:
stubs ask for AAAA. Smart resolvers ask for A6 (and AAAA, just in case
there are old systems. I think.)

               Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Nov 1998 22:36:57 +1100

Date:        Mon, 16 Nov 1998 16:09:07 +0100
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | could you rehash the reasons, please?

They largely relate to security, and how a DNS response that is generated
by the server could possibly be signed (given that for some security the
keys are not kept on line, zones are signed off line).

  | This wasn't mentioned when the AAAA/A6 coexistence/transition was being
  | muttered about (too few messages to call a debate :-) in NGTRANS.

The issues are different when you're considering a short term transition
issue (how we get from what we now have to where we want to be) - especially
when the major problem with the approach is security, which we don't have
working at all yet in any detectable way.

When you're considering a permanent solution, then we have to look at how
thing will work in the future, not just now - and for the future we have to
assume that some kind of security is in place.

If the (remote) server synthesises (128 bit) AAAA out of its components,
it has to obtain, and verify, the signatures of the parts.   Now we can assume
that at least one part (typically the least significant part) will be owner
by that server, for that part is easy, but the other components might need
to be fetched from other servers in the worst cases.   While verifying that
the data is authentic is what dnssec is all about, so that should be possible,
it is entirely reasonable to imagine security scenarios where the original
client might have accepted (trusted) a response that the server doing the
synthesising might not (or vice versa).   That is, there would need to be a
bunch of extra data passed around between the client (resolver) and the
server to allow everyone to be aware of just what had been done.   And all that
is aside from the problem of how the server, once it has produced the AAAA,
actually authenticates that to the resolver (if it signs it, assuming it can
find its key somehow, then the client will believe that the server is 
guaranteeing that information, whereas what it is really doing is passing
along information that it obtained from elsewhere).

Even then, all that assumes that all of the data is signed - once you start
mixing signed with unsigned (unauthenticated) data, things get even messier.

The only reasonable solution to all of this is simply to give the end resolver
all of the data, the parts of the final AAAA (the A6 records) and their
signatures, and allow it to implement its own verification policy (which may
vary anywhere from "I don't care, I see data, I loke it", to "I see a signature,
it must be OK", all the way to "While I see a signature, that was signed by
incompetant inc, and I dont' trust any signatures from them, so I will drop
this data".

  | (detecting the difference between a dumb stub and a smart resolver:
  | stubs ask for AAAA. Smart resolvers ask for A6 (and AAAA, just in case
  | there are old systems. I think.)

Yes, there may be something in having resolver parts (between themselves)
do an AAAA query, and have the back end part of the resolver do A6 queries,
signature verification, etc, and finally pass the "answer" back to the
stub resolver.

Dumb stub resolvers cause problems for authentication as well - if putting
A6 processing (which is really pretty simple stuff) into your backend is
considered too complex to deal with, then putting DNSSEC verification in
there is going to be way out of the even conceivable.    That's why TSIG
is being developed - a much simpler authentication mechanism, but one which
requires shared keys between the parties (and so is useless for general
DNS work).   The plan is that the dumb resolver uses TSIG to authenticate
its communications with the back end resolver, which uses DNSSEC to
verify the answers, and having done that, continuing with the TSIG
communications, passes the results back to the stub resolver.   If that's
going to happen, it seems to me that it would also be reasonable to do
A6->AAAA construction at the same point.

The existance of TSIG (which involves a pre-established association) allows
the back end resolver to understand that an AAAA query it receives is
from a stub resolver, and so A6 responses should be reconstructed into an
AAAA to return to the stub.

We can't simply have that happening all the time, as, as you point out, for
some time anyway we're going to have AAAA queries being made, just in case
the server for the zone hasn't changed from AAAA to A6 in its zone files
yet.   With the current state of the universe, "back end resolvers" and
"servers" are one and the same thing - and the queries they receive are
indisinguishable.   A way is needed to actually distinguish the two cases,
so the server/resolver can determine in which role it is being queried.
TSIG is the one thing on the horizon which just might permit that.

The conclusion from all of this is that stub resolver implementors should
certainly *all* be implementing TSIG (and somehow dealing with the issue of
where the shared key information is to come from).   That's likely to be
true, regardless of what is finally done with AAAA / A6.

TSIG is not yet an RFC, though it is close.   The current draft

	draft-ietf-dnsind-tsig-06.txt

should certainly be stable enough now for implementations to proceed upon
it with confidence.   You might also care to look at draft-skwan-gss-tsig-02.txt
though I'm not sure that that one (alternate algorithm) has widespread support
yet (when you get to talking about the details of security algorithms you
go way out of my league, I don't pretend to understand what the issues are).

kre