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

Q18: TTL values for RRSIG vs. RFC2181



Q-18:  Chance for conflict with RFC 2181 and RRSIG RRs.  Should RRSIG RRs be
allowed to have TTL values different from each other, if the RR sets they
cover have different TTL values?

Background
RFC2181 section 5.2:

   "Consequently the use of differing TTLs in an RRSet is hereby
   deprecated, the TTLs of all RRs in an RRSet must be the same."

dnssec records 5 section 3
  "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
  it covers."

Now consider this zone fragment:

efnet.example.com.       300     IN A    10.14.88.25
                         300     SIG     A 5 3 300 20031128150903 (
                                         20031029150903 11576 ... )
                         3600    AAAA    2001:7b8:3:3f:201:2ff:fef6:574e
                         3600    SIG     AAAA 5 3 3600 20031128150903 (
                                         20031029150903 11576 ... )
                         3600    NXT     ega.example.com. A SIG AAAA NXT
                         3600    SIG     NXT 5 3 3600 20031128150903 (
                                         20031029150903 11576 ... )

The RRSIG RR set has different TTL values, while they cover RRsets with
different TTL values.

The proposed solution is to add text to the DNSSECbis protocol draft stating
that RRSIG RRs are different than other RR sets in that they must have the
same TTL value as the set they cover.  Even if that means different values
for the TTL for RRSIG RRs with the same owner name.  This is an exception to
the specification in RFC2181 that states that all RRs in an RRset must have
the same TTL value.

There is no proposed text as yet, but it will go along the lines of the
section above.  Hopefully in more clear text than mine.  Alternatives are
welcome, as well as any statement as to why we shouldn't allow this.

DNSSECbis editors



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