Subject: Q18: TTL values for RRSIG vs. RFC2181

From: "Scott Rose" <[email-masked]>
Date: Fri, 31 Oct 2003 13:56:22 -0500

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

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 31 Oct 2003 15:03:58 -0500

>cover have different TTL values?

</chair>
IMHO it is more important that the RRSIG be cached for the same time
as the RRset it is covering, than having purity among the TTL's
of all the RRSIG's for one name.

>   "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset

How about:
The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
it covers.  Note this may lead to an apparent violation of RFC2181
section 5.2, but the RRSIG is a meta type and each RRSIG is related to
a RRset and it is important that the RRSIG be cached for the same time as
the RRset covered.

         Olafur

---

From: Rob Austein <[email-masked]>
Date: Fri, 31 Oct 2003 20:27:38 +0000

> of all the RRSIG's for one name.

<hat=just-another-bozo-on-this-bus>

I agree.  RRSIG RRs are bags hanging on the side of the covered RRset,
and for practical purposes RRSIG RRs just don't form normal RRsets.

</hat>

> a RRset and it is important that the RRSIG be cached for the same time as

<hat=editor>

I don't like "meta type" ('cause then we'd have to explain what it
means, which would almost certainly be harder than just saying
whatever it is that we do mean in the first place...), but I think
that the editors can handle the wordsmithing unless the WG feels a
strong need to constrain us to specific text.

The question before the WG is whether we've understood the content
issue correctly.

</hat>

---

From: [email-masked]
Date: Sat, 01 Nov 2003 09:13:27 +1100

> The question before the WG is whether we've understood the content

	The other solution to making this a exception is the SIG bit in
	the type code.

	The TTLs on SIGRR subtypes should be identical.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]