Subject: Q32: Adding the DNSKEY TTL as a factor when determining RRset TTL

From: "Scott Rose" <[email-masked]>
Date: Thu, 8 Apr 2004 07:25:09 -0400

Q32:  Adding the DNSKEY TTL as a factor when determining RRset TTL

Section 5.3.3 of the protocol document discusses how a cache should
calculate the TTL value for a RRset based on a number of factors:

- The RRset's TTL as received in the response

- The RRSIG RR's TTL as received in the response

- The value in the RRSIG RR's Original TTL field

- The difference between RRSIG expiration time and the current time.

The last being corrected from a previous error on the editors' part.

The comment given to the editors group was to add the follow constraint to
that list:

- The validating DNSKEY’s TTL

Discussion:
The case for this constraint is that if the DNSKEY has expired, then the
RRSIGs it has validated should also expire.  The DNSKEY may have rolled over
during the time period and the RRSIGs may no longer be valid.  It is
possibly out of date information.

The case against this constraint is that if the DNSKEY is purged from the
cache, it does not necessarily mean the RRSIGs have expired (they possibly
have not reached their expiration time).  The RRSIGs and DNSKEY may still be
in use by the authoritative zone.

It is the editors' opinion is that this additional constraint is not
necessary.  If WG members think that it is necessary, please state so and
supply text for Section 5.3.3 cache value recommendation.

Deadline for discussion is April 19th  Default action is to NOT ADD the
suggested constraint.  Otherwise, please state reason why the constraint is
useful and suggest text.

Thanks,
The DNSSEC editors group

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>