[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: notes from Dallas DNSIND - multiple TTL values
From:       "Donald E. Eastlake 3rd" <dee () cybercash ! com>
Date:       1995-12-07 5:58:02
[Download RAW message or body]

DNSSEC is even more stringent than indicated below.  SIG signs all RRs 
with the same type/name/class.  To verify the SIG, you have to do it
on the exact original RRs that were signed *including TTL*.  This is
implemented by having the "original TTL" remembered in the SIG RR and
restoring it into all the RRs before doing the hash calculation, etc.
(The RRs might have been retrieved from a caching server that has
decremented the TTLs.)

I suppose this doesn't really require the original RRs to all have
the same TTL, it just imposes an upper bound on on their TTL (since
no security aware DNS server will let the signed RRs have a TTL above
the "original TTL" in the SIG) and it means you always have to use the
this right "original TTL" in all the RRs when calculating the SIG over
them.  In really, the program that processes the master file to add
SIGs, etc., will probably at least indicate an error on different TTLs
if not clobber all the RRs to have the same TTL...

Donald

On Wed, 6 Dec 1995, Josh Littlefield wrote:

> > Because of the huge number of caching servers (and a few caching clients) that
> > implement 1035's TTL logic, I don't consider this change realistic.  What will
> > happen if we start emitting variant-TTL RRsets is that all conforming caching
> > servers will minimize the TTL and the effect will be the same as if the RRset
> > had a nonvariant TTL equal to the lowest variant TTL.
> 
> I'm glad you're holding firm on this.  I think there is a significant reason 
> that TTLs must work the way described in 1035, which you don't seem to 
> mention.  This is that if caching server X queries and caches 2 A records for 
> name N, and honors the different TTL's, expiring one of the A records, it then 
> has only 2 options when queried for N's A records by a client:  Hand back the 
> one remaining A record, which may well be incomplete information (just because 
> the TTL expired on the other A record doesn't mean the records expired at the 
> source), or try to update its data.  The latter is, of course, the same as 
> having wacked the entire set when the shortest TTL expired.  The former means 
> that short TTL data becomes relatively useless when a long TTL record is part 
> of the same set.
> 
> It seems that honoring each record's TTL really does nobody a service, and the 
> behavior desired by those at the WG mtg wouldn't materialize anyway.
> 
> The SIG RR's in DNSSEC reflect this view as well, for what that's worth, as 
> they sign ALL RR's of a particular type for a name, requiring all RR's to be 
> returned in any valid, secure response.
> 
> The benefit of multiple TTLs in the authoritative database is simply to allow 
> records to be added independently, contributing their own TTL requirements to 
> the set.  But that doesn't mean their TTLs can, or should be individually 
> represented to the outside world if caching servers are to work at all.
> 
> -josh
> 
> ========================================================================
> Josh Littlefield                           American Internet Corporation
> josh@american.com                                        4 Preston Court
> tel: 617-271-9200  fax: 617-275-4930             Bedford, MA  01730-2334
> 
> 

=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)

[prev in list] [next in list] [prev in thread] [next in thread]