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
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/dns-wg
