Subject: [DNSOP] long / short TTL

From: "Marc Lampo" <[email-masked]>
Date: Mon, 2 Apr 2012 13:53:40 +0200 (CEST)

Hello,

Following up on last week's DNSOP gathering in Paris,
where one contribution pleaded for long TTL's (on infrastructure records)
and another for short TTL's.

>From the humming results I interpret that consensus will be hard to reach.
Would it be an idea to spend some words on the theme in RFC4641bis ?
 (there is already wording in that draft,
  linking short TTL to applying corrections)
As that document does not "give strong recommendations",
 but mostly "guidelines" (quoted from the Introduction of that draft),
 no "consensus" is needed and guidelines can refer to security aspect.

However :
the authors of the draft on long TTL's showed data on a large set of
domains, over a period of time; regarding changes to NS records.
Since they can already provide a table with % of changes over a period
of time, can you also provide data on TTL of "about to be changed records"
?
In other words :
For those domains where a NS change was noticed,
 do you also have data on TTL values of the records, prior to the change ?
 (I assume most did not reduce the TTL of the old data)
--> I remember a statement of 75% that did not change NS records.
    Leaving 25% that did change.
If the change was not preceded by a lowering of TTL before the change,
that 25% is the percentage of domains that will be *negatively* affected
by large TTL's on infrastructure RR's !

Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 02 Apr 2012 16:32:48 +0200

Hi Marc,

As you said, there is already text in 4641bis on this subject. There
is text that provides guidelines on TTLs for DS records:

   ..., there is the TTL value on the DS
   RRs.  Shortening the TTL reduces the damage of a successful replay
   attack.  It does mean that the authoritative servers will see more
   queries.  But on the other hand, a short TTL lowers the persistence
   of DS RRsets in caches thereby increasing the speed with which
   updated DS RRsets propagate through the DNS.

And section 4.4.1 covers many time considerations. Although not
explicitly about NS RRset, imho they do cover all the considerations
related to DNSSEC operational practices. So to be clear, I don't think
the document needs to address this topic to more extent.

Best regards,
  Matthijs

On 04/02/2012 01:53 PM, Marc Lampo wrote:
> Hello,
> 
> Following up on last week's DNSOP gathering in Paris, where one
> contribution pleaded for long TTL's (on infrastructure records) and
> another for short TTL's.
> 
> Would it be an idea to spend some words on the theme in RFC4641bis
> ? (there is already wording in that draft, linking short TTL to
> applying corrections) As that document does not "give strong
> recommendations", but mostly "guidelines" (quoted from the
> Introduction of that draft), no "consensus" is needed and
> guidelines can refer to security aspect.
> 
> However : the authors of the draft on long TTL's showed data on a
> large set of domains, over a period of time; regarding changes to
> NS records. Since they can already provide a table with % of
> changes over a period of time, can you also provide data on TTL of
> "about to be changed records" ? In other words : For those domains
> where a NS change was noticed, do you also have data on TTL values
> of the records, prior to the change ? (I assume most did not reduce
> the TTL of the old data) --> I remember a statement of 75% that did
> not change NS records. Leaving 25% that did change. If the change
> was not preceded by a lowering of TTL before the change, that 25%
> is the percentage of domains that will be *negatively* affected by
> large TTL's on infrastructure RR's !
> 
> 
> Kind regards,
> 
> 
> Marc Lampo Security Officer EURid (for .eu)
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop