Subject: RE: The case against naïve anti-poison (was A6 and DNAME)

From: "Christian Huitema" <[email-masked]>
Date: Thu, 8 Feb 2001 08:05:12 -0800

May I observe that most of the issues Dan are rising result from a
specific approach to anti-poison, which is to rely strictly on the name
hierarchy? I don't know who decided on that approach, but it clearly has
the consequence of breaking existing practice, such as name servers
located in another domain. That existing practice had been going on for
quite a long time -- back in 1988, many of the name servers for
"inria.fr" were located in ".edu". There is no mention anywhere that
name server have to belong to the same hierarchy as the served domain.
So, instead of asking everybody on earth to revise their delegation, it
is probably avisable to make the anti-poison code a little bit smarter.
Now, this is probably a subject for the DNS group, not IPNG.

-- Christian Huitema
--------------------------------------------------------------------
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: 11 Feb 2001 01:27:44 -0000

Huitema's assignment of blame is completely incorrect. This is not a
subtle issue; there is a fundamental difference between the server
knowing addresses and the server not knowing addresses.

Let's take his inria.fr example. A cache contacts ns-ext.vix.com, one of
the .fr servers, and learns

   inria.fr NS dns.cs.wisc.edu

without the address of dns.cs.wisc.edu. It has to put the query on hold
while it looks for the address of dns.cs.wisc.edu.

Why doesn't this .fr server provide the address of dns.cs.wisc.edu?
Because IT DOES NOT KNOW THE ADDRESS.

Huitema is wrong when he says that the current anti-poison mechanism---
clients don't accept .edu records from .fr servers---created this
problem. The protocol does not require .fr servers to know the address
of dns.cs.wisc.edu! See RFC 1034, end of section 4.2.1. (See also the
part of section 5.3.3 that screams yes-we-know-this-design-is-garbage.)

Do you think the .fr server should provide the dns.cs.wisc.edu address?
That's server-side indirection. It works with current servers and caches
if the name is changed from dns.cs.wisc.edu to whatever.ns.inria.fr, as
I recommend. The inria.fr server is responsible for copying the address
and notifying the .fr server of any changes. Everything works.

Of course, with this fix, the name in the NS record serves no purpose. A
better protocol would have put the address directly into the NS record:
easier for servers, easier for caches, and no reliability problems.
These are the same reasons that AAAA is better than A6.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sun, 11 Feb 2001 16:18:55 +0700

Date:        11 Feb 2001 01:27:44 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The inria.fr server is responsible for copying the address
  | and notifying the .fr server of any changes. Everything works.

Assuming that the inria.fr server (or management of the server) ever
find out about the change.   Currently if dns.cs.wisc.edu changes its
address, there's nothing the inria.fr people need to do.   The change
is local to wisc.edu (and the .edu server).

With your scheme, every other zone that is hosted by the dns.cs.wisc.edu
server has to be notified of the change of address, and all at once they
all need to send off to their parent zones DNS updates, to change the
addresses.

And all this so resolvers don't need to know how to put a query on
hold while they go look up some other information (which they have to
be able to do to handle CNAME in the general case anyway, or are you
planning on abolishing aliases as well?)

kre