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