[EMAIL PROTECTED] writes:
> Dan stop assuming things about BIND 9's behaviour
I didn't say anything about BIND 9. Please read my message again; I'm
criticizing the protocol, not BIND. Think about your gigantic 6887ms
lookup time when you get to the ``fourteen queries'' part.
---Dan
Date: 18 Jan 2001 09:13:40 -0000
Message-ID: <[EMAIL PROTECTED]>
From: "D. J. Bernstein" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: A6 unreliability
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
