Subject: RE: A6 unreliability

From: [email-masked]
Date: Thu, 18 Jan 2001 22:55:07 -0600

I agree with this excellent assessment.  I also don't think that any bind
implementation
will permit more than 3 levels of hiearchy with A6.  The renumbering
benefits are valid
for A6 though.  But we need to put a bounds on them in some fashion.  I also
think this
should move to a server process model too not a client.  Quite frankly to
expect client 
implementations to do this well is just plain not going to fly.  I think you
bring up 
really good points.  I also think we need to start deployment with AAAA
records which 
will work and are running back in pre 8.X bind versions too.  Until we can
bound these
A6 beasts and make sure they can perform with implementations AAAA is our
only option.

regards,
/jim

-----Original Message-----
From: ext D. J. Bernstein [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 4:14 AM
To: [email-masked]
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-masked]
--------------------------------------------------------------------
--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 18 Jan 2001 23:07:25 -0600

Also go look at the source address selection stuff where we now have kernel
and user 
space hacking dns abstract types back and forth.  Another case of excessive
engineering insanity and architecture without consideration for performance.
Its good work as a spec but I have my doubts about what it will do to the
performance of end system **production** running code. Or now we use IPv4
anycast in ngtrans which has never been deployed or even well tested in an
evironment like the core interoperability events IPv6 has worked on.
Or the most ridiculous thing of late is this privacy stuff of temporary and
public 
addresses cause some adhoc group is paranoid about my MAC address.  Then
people take all this and make some kind of grand computer science cosmos
wonder out of it and slow down everything else around IPv6 or put an
interrupt in it for real implementors.  Oh yeah go look at the scoping.
Sooner or later the market will just barf on all this and force the vendors
to just deliver basic IPv6 as IPv4 so we can solve the real problem lack of 
address space and NATism.  But I truly hope your mail at least enlightens my
colleagues to fix these A6 records.  It will not work.

Not feeling politically correct and want IPv6 to be deployed with warts if
necessary,
/jim

-