Subject: RE: The case against A6 and DNAME

From: "Christian Huitema" <[email-masked]>
Date: Wed, 7 Feb 2001 18:30:01 -0800

I think we are hearing the same argument over and over again, so let's
repeat the other side of the story:

1) Perl script don't help you if you must compute RSA signatures for
10,000 records -- or 10 millions. Having to sign one record instead of
10,000, on the other hand, is very beneficial.

2) If your site has 4 prefixes and 10,000 hosts, then A6 allows you to
have four times less DNS records to handle.

3) With A6, you can exercize "site redirection" by publishing short
lived A6 records for your site, while leaving the host and server
records unchanged.

The argument in the page is essentially an argument against dependency
loops. The dependency loop occurs when one needs to contact a nameserver
in order to get the address of that same nameserver. The problem is
aggravated by "anti-poison" protections that essentially prevent serving
cached records from domains for which the local server is not
authoritative. May I observe that if "zone administrators (could) write
trivial perl scripts", then they could just has well write a trivial
perl script that checks for dependency loops? In any case, it is fairly
easy to write reasonable guidelines on how to use the technology without
creating loops -- the AOL example is a great way to explain what to do
and what not to do.

As for deprecating or otherwise removing standards, we have a clear IETF
process. A standard progresses if it is implemented and used, and if we
can demonstrate successful inter-operation between independent
implementations. Let's just follow the process...

-- 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: Bill Sommerfeld <[email-masked]>
Date: Wed, 07 Feb 2001 22:38:59 -0500

The problem is aggravated by "anti-poison" protections that
    essentially prevent serving cached records from domains for which
    the local server is not authoritative.

With DNSSEC and signed entries, it doesn't matter who gives you the
data, it's who signs it..

I haven't looked at it that closely but it would seem at first glance
that appropriate use of SIG records could allow for some relaxation of
the "anti-poisoning" checks (though SIG's are somewhat bulky).

					- Bill

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Feb 2001 03:52:20 -0000

System administrators insist on being able to change their records with
at most a few days notice---typically one day. See my ``Extremely long
TTLs'' message for further discussion of this point.

With DNSSEC, those records would have to be signed again every day. It
is not acceptable from a security perspective to have signatures last
longer than this; otherwise an attacker would be able to interfere with
changes by forging an old DNS response under the old signature.

Occasional renumbering is not going to add noticeably to this cost. In
fact, unless renumbering has to happen with less than a day's notice,
the extra cost is zero.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Feb 2001 04:30:45 -0000

Christian Huitema writes:
> A standard progresses if it is implemented and used, and if we

AAAA has independent interoperable implementations, but I don't see you
supporting it. I don't see you saying ``follow the process'' when some
people say that AAAA is deprecated in favor of A6 and should go away.

Well, I'm saying that A6 and DNAME should go away. The relevant process
is specified in section 6.4 of RFC 2026.

> have four times less DNS records to handle.

So what? It's a tiny database either way.

> lived A6 records for your site, while leaving the host and server

I can't figure out what practical problem you're talking about. ``Site
indirection'' normally refers to a bunch of http-equiv="refresh" web
pages pointing to a new location.

---Dan