Subject: [dnsext] TTL on DS records

From: "Wessels, Duane" <[email-masked]>
Date: Sat, 21 Feb 2015 01:19:04 +0000

Section 5 of RFC 4034 says:

   The DS RR has no special TTL requirements.

While RFC 4035 Section 2.4 says:

   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset

Due the "SHOULD" I'm not sure this is worthy of an errata, but seems rather unfortunate.

Apologies if this is a previously known issue.

DW

---

From: Patrik Wallström <[email-masked]>
Date: Sat, 21 Feb 2015 11:50:39 +0100

> Apologies if this is a previously known issue.
Several TLD operators have a lower TTL on the DS. The reason is to help
the registrant to recover from a signature failure and be fast to remove
the DS. I think this is one of the reasons to why there is a SHOULD there.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 21 Feb 2015 12:15:29 +0100

> On 21 feb 2015, at 11:50, Patrik Wallström <[email-masked]> wrote:
> 

My personal view is that the TTL for the DS should be really short. I.e. much shorter than what people might think. This because any kind of key rollover (when doing transfer etc) or forwarding of private keys, or any other "correct" theoretical model of how to do transfer in reality I think is just...theory. Specifically as one of the main reasons for doing transfer is that the loosing registrar/dns operator is that they do not do their job. And because of that have double reasons for not cooperating in the transfer.

But, I would like some really smart people think about what "really short" should be. 15 minutes?

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 21 Feb 2015 07:21:04 -0500

On Sat, Feb 21, 2015 at 12:15:29PM +0100, Patrik Fältström wrote:
> 
> My personal view is that the TTL for the DS should be really short.

This would be yet another reason for people not to turn on validation,
because validating will become an excellent way to increase latency in
page loading.  It seems to me that you want to defend against one
problem (lousy operator) by creating a new one (poor caching).  I'm
not convinced that's an excellent trade off.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 21 Feb 2015 15:05:29 +0100

> On 21 feb 2015, at 13:21, Andrew Sullivan <[email-masked]> wrote:
> 

Well, my point is that there is a balance, and I ask for a calculation of that balance.

Today, with a lousy operator that one move a domain away from have a delay in effect of that move which is based on the TTL of the DS.

My question is how long we think that delay should be, to not affect caching too much.

Given we see caching issues anyway around the net that question why we have 48h TTL on some records.

I am not after 1 second TTL, but maybe it should be recommended to be 1h and not 48h.

I also btw do see complaints on registries only updating their zone every 4h or 8h, so I see a clear trend to have shorter caching.

I was just after a discussion :-)

   Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 21 Feb 2015 08:17:47 -0800

> I also btw do see complaints on registries only updating their zone every 4h or 8h, so I see a clear trend to have shorter caching.

Paf,

Could you expand on what you've seen as complaints? Are these from 
registrants (or their agents) attempting "stupid dns tricks", or 
monitization schemes, or ...

In my limited experience, registrants pursuing a plan of making more 
than nominal resources available are insensitive to zone update frequency.

Eric

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 21 Feb 2015 17:28:43 +0100

> On 21 feb 2015, at 17:17, Eric Brunner-Williams <[email-masked]> wrote:
> 
> Could you expand on what you've seen as complaints? Are these from registrants (or their agents) attempting "stupid dns tricks", or monitization schemes, or ...

Registrants asking registrars why they have to wait to get to use the domain names they just procured.

And the problem might not be the wait, but that some TLDs have "instant update" and some others have "longer wait".

And the difference is what registrars have to try to explain to registrants.

> In my limited experience, registrants pursuing a plan of making more than nominal resources available are insensitive to zone update frequency.

   Patrik

---

From: Ralf Weber <[email-masked]>
Date: Sat, 21 Feb 2015 20:19:34 +0100

Moin!

> not convinced that's an excellent trade off.
I don't see how this will increase latency of page loading. Most
recursive resolvers these day do pre fetching for often used records
and if the record isn't in the cache the difference in latency comes 
from validation anyway.

I think we need to move away from TTLs in the days or even week range
to TTLs that are in the hours range. I think one hour is a good TTL
for DNSSEC stuff. If your domain isn't asked once an hour in a big
providers network chances are it would have fallen out of the cache
becuse of LRU anyway during that time frame.

So long
-Ralf

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 21 Feb 2015 15:50:34 -0500

> and if the record isn't in the cache the difference in latency comes 

Well, this could be, but if you're validating, reducing the TTL on the
DS automatically entails a lookup as frequently as the DS.  Now of
course, if browsers are doing this validation themselves (and not
relying on the system validator), they might pin anyway.

> to TTLs that are in the hours range.

What do you mean _we_?  Your zone, your rules.  That's part of why I'm
objecting to parents having very short DS TTLs: it affects what the
child's cache behaviour is like, and we have historically supposed
that zone administrators have pretty good control over that for their
own zones.  If the parent side TTL gets short, then setting the TTL on
the child side isn't the only thing one can do to affect caching.
That seems like a pretty big change to the operational environment.

> I think one hour is a good TTL for DNSSEC stuff. If your domain
> isn't asked once an hour in a big providers network chances are it
> would have fallen out of the cache becuse of LRU anyway during that
> time frame.

That could be.  It seems to me that without actually studying this, we
could all make up numbers.  I gather that OARC is going to run another
DITL this year.  Maybe that'd be something worth getting large
recursive operators involved in so that we have something to study.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 21 Feb 2015 20:42:38 -0500

> On Feb 21, 2015, at 3:50 PM, Andrew Sullivan <[email-masked]> wrote:
> 

No Andrew it effectively is the MAX( DS TTL, DNSKEY TTL) 
and with prefetching you can compare existing records to the new ones thus avoid validation. 
In most cases there is plenty of headroom for calculations so I think we should be thinking about
what is good for the internet. 
Long TTL’s are good for unstable networks, Short TTL meet customers expectations. 

> That seems like a pretty big change to the operational environment.

Not putting words in Ralph’s mouth, but I agree with him. 
Long TTL are artifacts of decisions taken long time ago
and they need to be reexamined. 

> recursive operators involved in so that we have something to study.

Yep we need to study and experiment. 
A simple study is to compare how much more traffic a resolver with MAXCACHE = 1H 
asks than one with MAXCACHE = 6H or 12H 

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 21 Feb 2015 22:13:57 -0500

> No Andrew it effectively is the MAX( DS TTL, DNSKEY TTL) 

I suppose it's true that, having validated the DNSKEY once, you're not
going to check it again.  It does still entail that the parent zone
gets to make TTL decisions that affect the lookups necessary for use
of child-side data.

> and they need to be reexamined. 

I don't have any trouble with the idea that most caches aren't going
to keep anything for a week, and I know lots of zones that have very
short TTLs.  But as I said, it's almost completely novel in the DNS
that the parent-side decisions affect things for the child in this
way, and I think we shouldn't be cavalier about that change.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ralf Weber <[email-masked]>
Date: Mon, 23 Feb 2015 05:17:10 +0100

Moin!

> relying on the system validator), they might pin anyway.
Don't most browser validators still use at least the system stub 
resolvers and thus your configured recursive resolver anyway? What 
you describe is correct, but the lookup only has to fill the DS
from the parent and nothing from the child (unless it expired of
course).

> What do you mean _we_? 
The DNS community within the IETF (and possible other venues).

> Your zone, your rules.  That's part of why I'm
Yes there may be one round trip to the parent name server when
the DS expires, but you still control how often your server is
asked with the TTL of your records (unless there is an attack ;-).

> recursive operators involved in so that we have something to study.
You have to as in the DITL run you might not see the effect of 
different DS TTL because the root might not be asked in the
cache refill scenario.

Just one side note of personal experience running or helping people
to run large resolver farms over the last 20 years. While the average
TTL, especially for often used records has gone down during that 
time frame, the cache hit rate has gone up. These days it is not
uncommon to see cache hit rates of 90% or more. So I don't think
lowering the TTL of the DS record will have an impact on the cache
hotness and thus performance of resolution.

So long
-Ralf