On 29. 11. 21 12:59, Anand Buddhdev wrote:
Dear colleagues,
Users may request reverse DNS delegation by creating "domain" objects in
the RIPE Database. Such domain objects must contain "nserver" attributes
to specify the name servers for a reverse DNS zone, and may contain
"ds-rdata" attributes, to specify delegation signer (DS) records.
When the RIPE NCC publishes these records in the appropriate parent
zones, the Time to Live (TTL) of all these records is set at 172800 (two
days).
The TTL of delegation NS records may be overridden by the TTL of NS
records from a zone's apex. Alternatively, many large resolvers ignore
the TTL values of NS records and cap them at much lower values such as
21600. Finally, there is no way for a zone operator to change the TTL of
a DS record, which is only present in a parent zone.
Long TTLs can cause problems for users when they want to change their
name servers or perform DNSSEC key roll-overs. A long TTL on a DS record
is especially harmful when a user needs to do a key roll-over in an
emergency.
We propose to lower, in the first quarter of 2022, the TTL on NS records
to 86400 and on DS records to 3600.
We welcome feedback or discussion about this, ideally via the DNS
Working Group mailing list. If you prefer to send your feedback directly
to us, you can email [email protected].
I think lowering both TTLs is a step in right direction, but let me ask
provocative question:
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:
Step 3a: If there was no update to the record in the last 1 hour, double
the respective TTL. Repeat until defined upped bound is reached. -> Go
to Step 3
Step 3b: If there _was_ another update, reset TTL to 1 minute and reset
the timer. -> Go to Step 3
If the upper bound was 1 hour then the maximum would be reached in ~ 6
steps (6 hours since the change was introduced). 1 day TTL would be
reached in 11 steps, i.e. 11 hours.
I think something like this would provide best of both worlds:
- Quick turnaround around changes and potential problems. Most problems
happen right after change, in which case even 1 hour is PITA.
- Automatic TTL adjustment of "stable" records lowers load on servers
and improves reliability when outages in the DNS infrastructure happen.
- Even if the delegation was hijacked (unlikely for reverse zone, so
here just to illustrate) the lower TTL would help fixing it/pointing it
back to the rightful owner.
What do you think? It seems so simple that I now have to wonder why
registries are not doing it?
--
Petr Špaček @ Internet Systems Consortium
--
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
