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