[dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
- Previous message (by thread): [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
- Next message (by thread): [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Petr Špaček
pspacek at isc.org
Thu Dec 2 14:46:24 CET 2021
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 dns at ripe.net. 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
- Previous message (by thread): [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
- Next message (by thread): [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]