[dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations

On 12/2/21 2:46 PM, Petr Špaček wrote:
> Why not make the TTL _dynamic_, based on time of last change in the RIPE database?
> 
> Here is a wild example how it could work - all constants are made up, feel free to substitute your own:
> 
> Step 1: Define upper bound for NS & DS TTLs which are "stable". Say 1 day for both NS and DS.
> 
> Step 2:
> At the moment when someone updates NS or DS, lower respective TTL to 1 minute.
> 
> Step 3: Cycle:
[...]
> What do you think? It seems so simple that I now have to wonder why registries are not doing it?

One problem I see is that if you change or add NS/DS records, and the TTL is set to a low value without your active participation, you can no longer figure out for how long old values (pre-change) are cached somewhere, so you don't know when stale stuff will globally expire.

But knowing this may be relevant in some recovery scenarios. For example, if you remove a DS record and throw away the corresponding key, and later realize that this was an error, you will see a DS TTL on the order of a minutes. That may make you think that it would not be worth recovering the old key from the backup, and that it would be better to create a new key pair and deploy it (including the DS).

Unfortunately, that won't work, because resolvers may have cached the old values for a time period that you can't determine in hindsight. Only if modifying the TTL would be an explicit step, you could know this (by first looking, then changing).*

So it seems to me that explicit is better than implicit (as usual). If communication channels for that are missing (e.g in EPP), perhaps that's what the actual problem is?

* One could keep a history of TTL values somewhere, but that seems overengineered.

Thanks,
Peter