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

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