[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From: "D. J. Bernstein" <djb@cr.yp.to>
Date: 20 Jul 2001 22:13:22 -0000
Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise.
Content-Disposition: inline
Subject: Re: NGtrans - DNSext joint meeting, call for participation

``Administrators normally insist on being able to change their records
with at most a few days notice,'' my web page says, as a starting point
for analyzing the expiration-date security issues.

This applies to _all_ records. Existing DNS software assumes, correctly,
that long TTLs are a mistake. I elaborated on these points in an
``Extremely long TTLs'' message on ipng in January:

   Everything changes. Machines acquire extra IP addresses. Machines
   disappear. Even MAC addresses change: network cards die. (It isn't
   always possible, never mind easy, to reprogram the MAC address on the
   new card.)
   
   Those of us who write caches don't want to deal with users asking ``why
   am I getting the old address?'' when a novice administrator starts with
   a silly 6-week TTL and then suddenly realizes that he has to change the
   address. My cache never saves data for more than a week.

Yes, the average address stays unchanged for a very long time. Yes, it
might stay unchanged for even longer with A6. But that's not what TTLs
measure! When an address _does_ have to be changed, there's often not
much warning. _That_ is what TTLs are for.

Matt Crawford writes:
> then the signatures on the A6 records covering interface identifiers
> and subnets can be valid for a long time,

No, they cannot, because that would allow an attacker to interfere with
updates. This is the security issue analyzed on my web page.

---Dan

Home | Date list | Subject list