Subject: A6 benefits?

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Jan 2001 09:01:14 -0000

Background: Why do NS and MX records use names, rather than addresses?

RFC 1035 responds: If you copy a machine's address into an NS record,
then you have to watch for changes in the address, and echo them.
Indirection ``avoids the opportunity for inconsistency.''

I agree: indirection is good. But it didn't have to be handled by the
DNS _client_. It could have been handled by the DNS _server_. The server
could have periodically checked for changes in the address. This would
have reduced latency, and improved reliability; see my next message.

Now my question: Why has IPNG proposed A6, rather than AAAA?

The answer seems to be the same: If you copy an ISP's address into part
of an AAAA record, then you have to watch for changes in the address,
and echo them. Indirection avoids the opportunity for inconsistency.

I agree: indirection is good. But it doesn't have to be handled by the
DNS _client_. It can be handled by the DNS _server_. The server can
periodically check for changes in the address. This will reduce latency,
and improve reliability.

Is there some other claimed benefit of A6?

---Dan

--------------------------------------------------------------------
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: "D. J. Bernstein" <[email-masked]>
Date: 18 Jan 2001 09:13:40 -0000

A recent bind-users report pointed out that BIND 8 can't find the IPv4
address of www.monty.de, even though the monty.de configuration is valid
and the relevant servers are responding quickly.

Here's one way to understand what's going wrong.

I'd like to write a program that talks to DNS servers to find an address
given an FQDN. How much memory do I need? How many servers do I need to
contact?

Well, I might need 64KB for an incoming DNS message, during the brief
moment before I parse it. There's not much persistent data:

   * The name I'm looking up.
   * The name of the closest zone found so far.
   * The addresses of servers for that zone. 16 is more than enough.

A response from a server will give me the answer, or refer me to a
closer zone. The number of queries is at most 4 for www.blah.com.
Simple, isn't it?

Oops, that's not quite right. I might receive a CNAME. In that case I'll
have to change the name and start over. This may happen several times.
RFC 1034 says that the first CNAME ``should always'' get me to the
canonical name, to avoid ``extra indirections,'' but it also says that I
should follow chains if they do happen.

Suddenly there's no limit to the number of queries. I have to set my own
artificial limits to catch loops, and pray that they're not too small.

But wait. The algorithm still doesn't work. The referral can include
some glueless server names---names without addresses. I need to put the
query on hold while I look up _those_ addresses. So here's what I
actually have to store:

   * The name I'm looking up.
   * The name of the closest known zone.
   * The known addresses of servers for that zone.
   * The names of servers whose addresses I still have to look up.
   * The name of a server whose address I'm looking up.
   * The name of the closest known zone to _that_.
   * The known addresses of servers for that zone.
   * The names of servers whose addresses I still have to look up.

It doesn't end there. If there are names in the last list, I'll have to
put the second lookup on hold while I look for the addresses of _those_
names. And so on.

The servers for monty.de, for example, are {ns,ns2}.norplex.net. The
servers for norplex.net are vserver.neptun11.de and ns1.mars11.de. The
servers for neptun11.de are {ns,ns2}.germany.net. The servers for
mars11.de are ns1.neptun11.de and www.gilching.de. The servers for
gilching.de are ecrc.de and name.muenchen.roses.de. What an amazing
display of gluelessness!

Suddenly there's no limit to the amount of space I need. I don't have a
single small array of addresses; I have an unlimited-length array of
small arrays of names and addresses. This isn't so simple any more.

The problem with BIND is that it doesn't set aside this space. It uses
the naive data structure. The only way it can put a query on hold, and
look up a server name, is by dropping the query. It hopes that the
server name lookup (``sysquery'') will find the server name before the
original client tries again.

My DNS cache can handle several levels of gluelessness, so it's able to
find www.monty.de---but it has to send _fourteen_ queries. That takes
quite a bit of time. Even worse, there are fourteen opportunities for
delays.

I encourage my users to avoid CNAMEs. I encourage them to avoid glueless
domains. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as
the default server names for fqdn. My users appreciate the speed and
reliability.

Now I'm looking at the IPv6 DNS proposals. Here's what I see:

   * ip6.int is similar to in-addr.arpa. The format is slightly less
     compact but allows many levels of delegation without CNAMEs. The
     final names are large but tolerable. Okay. It works.

   * AAAA requires a fairly clumsy transition; extending the A format
     would have been much cleaner. But AAAA in a future IPv6-only world
     will function the same way that A does today. Okay. It works.

   * DNAME exacerbates all the problems of CNAME. DNAMEs can be wrapped
     inside DNAMEs---and this is _encouraged_! We'll have people setting
     up huge CNAME/DNAME chains to match their corporate structures.

   * A6 exacerbates all the problems of glueless names in NS records.
     Suddenly there's another reason that a lookup will have to be put
     on hold---and, again, this is _encouraged_!

DNAME and A6 are moving in the wrong direction: more gluelessness,
slower lookups, more frequent delays, and more outages like monty.de.
A6 creates reliability problems that are not present in AAAA.

I object to DNAME and A6. I would object to them even if they were the
only way to support easy renumbering. I cannot bring myself to inflict
such a rickety system on future Internet users.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Jan 2001 16:55:32 +0700

Date:        18 Jan 2001 09:01:14 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is there some other claimed benefit of A6?

It is certainly possible to set up some horrid indirections which
cause lots of extra work with A6, as it is with NS or MX.

However, in all of those cases, the indirection, if used
intelligently (and I would admit that there isn't a lot of
intelligence in a lot of DNS configuration) allows significant
caching benefits - especially when addresses are likely to
change, and changing addresses is supposed to be one of the
things that IPv6 makes easy (which includes cheaper).

That is, with

	$ORIGIN my.domain
	host1	604800	IN	A6	64 <mac> pfx.my.domain.
	host2	604800	IN	A6	64 <mac> pfx.my.domain.
	(etc)
	pfx	7200	IN	A6	0  <prefix1>
		7200	IN	A6	0  <prefix2>

The mac addresses of host1 & host2 can stay cached for ages
(if I ever change one, I can just retain the old address as
an alias long enough for the old A6 record to expire), whereas
the prefix needs to be refreshed quite frequently.

With A6, any refresh of the prefix will refresh it for all the
hosts that use it.

The same applies to NS records, MX records, etc - those records
typically have values that rarely need to change, but the
associated addresses change often.   But many hosts can share
the same MX, and many domains the same NS, refreshing the
A record for any of them in the cache refreshes for all of
them.

kre

---

From: Nathan Lutchansky <[email-masked]>
Date: Fri, 19 Jan 2001 09:41:07 -0500 (EST)

> cause lots of extra work with A6, as it is with NS or MX.

Yes, but with A6 records, the number of queries is bounded by the length
of an IPv6 address, unless you use a lot of 0-length records.  And DNAME
records aren't that great of an issue; half the reverse-resolution in the
current Internet is broken and nobody seems too concerned about fixing
it.

One other thing to keep in mind is that unlike an endless chain of
glueless NS records, A6 records will, in general, chain to other records
in the same zone and thus a significant part of the chain will be returned
on each query.  Thus, NS chains require much more work to resolve and
should not be compared to A6 chains.  It shouldn't take more than 2 or 3
queries to resolve a full A6 chain.  In all likelyhood, prefixes for
popular providers and services will remain cached, and resolving the names
of virtual hosts and hosts on the same network will only take a single
query, just as they do now with A records.  -Nathan

-- 
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [email-masked] |  Lithium Technologies  |
+------------------------------------------------------------------+
|  I dread success.  To have succeeded is to have finished one's   |
|  business on earth...  I like a state of continual becoming,     |
|  with a goal in front and not behind. - George Bernard Shaw      |
+------------------------------------------------------------------+

---

From: [email-masked]
Date: Fri, 19 Jan 2001 23:52:12 +0900

>query, just as they do now with A records.  -Nathan

	A6 chain will not stay in the same zone.  it will go up from leaf site
	to a small ISP, then to middle ISP, and then to large ISP.  this is
	the purpose of A6.

foo.itojun.org.		IN A6	64 ::9876:5432:9876:5432 segment0.itojun.org.
segment0.itojun.org.	IN A6	48 ::1234:0:0:0:0 ispX.net.
ispX.net.		IN A6	40 0:0:0012:: ispY.net.
ispY.net.		IN A6	32 0:0:2300:: ispZ.net.
ispZ.net.		IN A6	16 0:9876:: ispU.net.
ispU.net.		IN A6	0 1234::

itojun

---

From: Nathan Lutchansky <[email-masked]>
Date: Fri, 19 Jan 2001 10:03:42 -0500 (EST)

> ispZ.net.		IN A6	16 0:9876:: ispU.net.

I was envisioning something more along the lines of:

foo.itojun.org.		A6	64 ::9876:5432:9876:5432 segment0.itojun.org.
segment0.itojun.org.	A6	48 0:0:0:1234:: itojun-prefix.ispX.net.
itojun-prefix.ispX.net.	A6	40 0:0:0008:: tokyo8-prefix.ispX.net.
tokyo8-prefix.ispX.net.	A6	32 0:0:2300:: tokyo-prefix.ispX.net.
ispX-prefix.ispY.net.	A6	16 0:9876:: japan-prefix.ispY.net.
japan-prefix.ispY.net.	A6	0 1234::

How many intermediate ISPs/zones are there typically expected to be?
Site->ISP->backbone seems like a reasonable configuration, possibly with
one additional ISP in the middle.  It seems that the first one or two ISP
prefixes would stay in caches of most busy servers.  -Nathan

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Jan 2001 22:49:32 +0700

Date:        Fri, 19 Jan 2001 23:52:12 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	A6 chain will not stay in the same zone.  it will go up from leaf site
  | 	to a small ISP, then to middle ISP, and then to large ISP.  this is
  | 	the purpose of A6.

Well, perhaps.  This will depend upon how it is configured.   The example
you showed is most likely taking the thing towards absurdity (and yes,
that is certainly possible).

On the other hand, I suspect that many sites will not want to place their
addresses into the hands of some other zone administrator, and will instead
use

foo.itojun.org.		IN A6	64 ::9876:5432:9876:5432 segment0.itojun.org.
segment0.itojun.org.	IN A6	48 ::1234:0:0:0:0 ispX.itojun.org.
ispX.itojun.org.	IN A6	40 0:0:0012:: ispY.itojun.org.
ispY.itojun.org.	IN A6	32 0:0:2300:: ispZ.itojun.org.
ispZ.itojun.org.	IN A6	16 0:9876:: ispU.itojun.org.
ispU.itojun.org.	IN A6	0 1234::

which gives almost all the same benefits (except you need to be
involved when one of the prefixes changes), and gives you the
added security (peace of mind I mean, not mathematical type security)
that your addresses are all under your control.

Then, having done that you will probably realise that you could
just as easily make the third one be...

ispX.itojun.org.	IN A6	0 1234:9876:2312::

(assuming I mentally did the correct transformation) and not bother
with the long chain.   It might mean a few more records to update if/when
one of the ISP prefixes changes (not in this example, but in general
it would), but not so many more that it becomes unreasonable.

Then the chain is just 3 long, and all in the same zone.

However, we do need more experimentation with A6 - and to get that
we need people to actually use the thing, rather than just looking
at the worst possible configuration of it and throwing up their hands
and saying "too hard".

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jan 2001 11:16:44 -0600

This is all very well in theory. In practice, we obviously need to
limit ourselves to very short chains - maximum 2 would be prudent,
until we know whether it works at massive scale.

Decoupling the host and prefix is the *big* win for renumbering;
chaining up the ISP hierarchy is a marginal benefit.

    Brian

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Jan 2001 19:25:38 -0000

Nathan Lutchansky writes:
> Thus, NS chains require much more work to resolve and
> should not be compared to A6 chains.

I'm sorry if I didn't make myself clear.

This is not a competition between out-of-zone NS records and out-of-zone
A6 records. The two types of records are _cooperating_ to hurt service.
The success chance drops exponentially with the amount of gluelessness.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jan 2001 02:20:46 -0000

Robert Elz writes:
> allows significant caching benefits

Do you have some numbers to back that up? How many DNS queries does your
site generate? How many of them would have been saved by this type of
overlap? Assume that networks are marked by in-addr.arpa zones. Ignore
the extra cost of following out-of-zone pointers.

> The same applies to NS records, MX records, etc

I've reviewed the logs on a busy mail server. The overlap is negligible.
Yes, there are quite a few high-TTL MX/NS records pointing to low-TTL A
records, but only a small fraction of the A owners are shared by other
MX/NS records.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sat, 20 Jan 2001 15:20:22 +0700

Date:        20 Jan 2001 02:20:46 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Do you have some numbers to back that up?

No.   I thought you were asking what the benefits were supposed to be.
I also thought I made it clear that there isn't currently a lot
of intelligence in DNS configuration.   I guess the question is
whether we design protocols so they can be used intelligently by
those who care, or whether we design them assuming that all the
users are morons, and cannot possibly cope with anything sophisticated.

  | Yes, there are quite a few high-TTL MX/NS records pointing to low-TTL A
  | records, but only a small fraction of the A owners are shared by other
  | MX/NS records.

So, way too many DNS admins obviously accept bogus advice that NS
records should be nsN.my.domain (or similar) instead of using the
well known names of the actual servers?   That people can be misled
this way doesn't mean that they have to be, or that we should assume
it is the only way.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jan 2001 09:49:36 -0000

I've analyzed my DNS cache logs in more detail:

   * The number of different MX targets is 97% of the number of
     different MX records. Weighting by query doesn't change the
     figures.

   * The number of different address sets for those MX targets is 94% of
     the number of different MX records. Again, weighting by query
     doesn't change the figures.

   * 40% of all MX targets are outside the MX server's bailiwick. The
     cache can't use the A even if the server provides it.

In other words: There's very little overlap between mail exchangers. The
number of queries wasted by missing addresses is much larger than the
number of queries that could possibly be saved by overlap.

Elz is wrong when he blames the lack of overlap on the choice of MX
names. In fact, almost all of the addresses are different.

Elz concludes, from his incorrect efficiency claim, that my advice to
avoid gluelessness is ``bogus.'' Apparently he doesn't understand that
gluelessness causes _reliability_ problems. I explained this in detail
in the A6-unreliability thread.

---Dan

---

From: Ian Jackson <[email-masked]>
Date: Thu, 25 Jan 2001 00:54:42 +0000 (GMT)

>      up huge CNAME/DNAME chains to match their corporate structures.

Quite.  I can't see any excuse for DNAME, frankly.

The only positive effect of DNAME I can think of at the moment is that
it might produce a bit of extra caching commonality.  But, this is
only relevant if a DNAME is made of large domain and *many* of the
records in the DNAME domain are used.

In return for this we get all of the reliability problems Dan
mentioned, not to mention the fact that DNAME processing is quite a
complex task even under favourable conditions and implementations are
bound to be buggy, have security problems, etc.

Ian.

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 26 Jan 2001 17:11:46 +0100

On Thu, Jan 18, 2001 at 09:13:40AM -0000, D. J. Bernstein wrote:

> and the relevant servers are responding quickly.

The servers might respond quickly at the moment, but the configuration
is nevertheless invalid:

% host -t any www.monty.de.
www.monty.de is a nickname for monty.de
monty.de name server ns.norplex.net
monty.de name server ns2.norplex.net

% traceroute ns2.norplex.net.
traceroute to ns2.norplex.net (151.189.26.234), 30 hops max, 40 byte packets
 1  xanthos.informatik.uni-bonn.de (131.220.4.3)  2 ms  2 ms  2 ms
 ...
 14  grf-ffm-ge020.germany.net (151.189.3.121)  23 ms  19 ms  19 ms
 15  151.189.26.234 (151.189.26.234)  20 ms  21 ms  25 ms
% traceroute ns.norplex.net.
traceroute to ns.norplex.net (151.189.12.193), 30 hops max, 40 byte packets
 1  xanthos.informatik.uni-bonn.de (131.220.4.3)  2 ms  2 ms  2 ms
 ...
 14  grf-ffm-ge020.germany.net (151.189.3.121)  46 ms  18 ms  20 ms
 15  vserver.neptun11.de (151.189.12.193)  29 ms  21 ms  20 ms
%

Using an official secondary which is behind the same router is
completely bogus, and at least until recently, no domain would be
registered at all that didn't have a really independent secondary
server.

But it looks like nowadays it is ok to not pretend at all to have a
secondary nameserver, and even people who should know better don't
bother:

% host -t any yp.to.
yp.to name server a.ns.yp.to
yp.to name server b.ns.yp.to
% host -t any a.ns.yp.to.
a.ns.yp.to has address 131.193.178.181
% host -t any b.ns.yp.to
b.ns.yp.to has address 131.193.178.181

so why should clueless $30 ISPs do?

Now, let's go back to discuss design of reliable networks.

Regards,
	-is

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Jan 2001 16:51:21 -0000

The physical location of the servers has no relevance to the protocol
failures under discussion. BIND's inability to find monty.de doesn't
involve any lost packets; nor did the fourteen queries that I mentioned.

Ignatios Souvatzis writes:
> completely bogus,

Will you keep saying that if it turns out that there are arrangements to
instantly reroute the network in case of outages?

As for my configuration, see http://cr.yp.to/djbdns/third-party.html.

---Dan