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

Disclaimer:
I agree with everyone in this thread that explicit is better than 
implicit, and that auto-magic is much worse than operators lowering 
their TTL in time and then setting it back when they are done.

Of course, RIPE NCC can be a pioneer among registries and expose TTL to 
domain admins. In that case I will sit silently and watch how it goes.


Rest of this e-mail applies only to situation when explicit TTL 
configuration is not possible or practical.

---- Further musing about dynamic TTL below: ----
---- Ignore if explicit TTL control is introduced ----

This ideal IMHO has several practical problems:

- In my (admittedly limited, anecdotal) experience most operators do not 
lower their TTLs before doing changes, and then when problems happen 
they are in a trap. Maybe RIPE NCC's audience would be significantly 
better in that respect, who knows. We cannot have data about that 
without exposing the explicit TTL knob.

- It does not work at all CDS/CDNSKEY automation because AFAIK there is 
no way for child to signal desired TTL to the parent. One could argue 
that CDS/CDNSKEY should have lower risks so it might not be necessary.

- In my (again admittedly limited, anecdotal) experience registries do 
not _want_ to expose interface to change TTLs (for various reasons).

Another angle how to look at this is that explicit manual configuration, 
while theoretically the best, very much resembles the way how DNS was 
done in 1980s and not operational reality of 2020s. Manual and error 
prone processes are being replaced with automatic everywhere, and DNS 
should not be an exception.

In other words, I agree with purists on the theoretical level: Static 
and explicit TTLs are perfect for world full of cooperating DNS experts 
and registries, but I don't believe we are in this ideal world. And if 
the "explicit" option not practical for any reason, we are left either 
with static or dynamic "defaults" imposed by the registry. Pick you 
poison then.


On 02. 12. 21 15:37, Jim Reid wrote:
>> On 2 Dec 2021, at 13:46, Petr Špaček <pspacek at isc.org> wrote:
>> Why not make the TTL _dynamic_, based on time of last change in the RIPE database?
> 
> Because it’s a very bad idea?
> 
> 1) The RIPE database and its reverse zone DNS data are orthogonal things (modulo the nameserver objects for bits of the reverse tree). These two different things shouldn’t get linked in this way. There needs to be a clean and clear separation between the two. If they get entangled, the outcome will be painful for everyone.

Except that they already are entangled. You cannot plausibly claim they 
are orthogonal if DS & NS records read from the database and used to 
generate zone data. (I'm not database expert of course, but that's my 
understanding.)


> 2) It imposes (IMO unwanted) operational requirements on the database -- uptime, availability, extra tooling, new processes, opportunites for adding cruft, etc -- unrelated to the database's prime function.

I don't think so. The database already has "changelog", and there 
already has to be a component which generates zone data from the 
relevant fields in the database. Whatever theoretical logic for dynamic 
TTLs would belong to this "database->zone translation layer".


> 3) Changes to the RIPE database for some reverse zone do not necessarily mean changes to that zone’s DS TTLs or the LIR’s DNSSEC policies.

Agreed. I'm theorizing about the case where "registry" does not want to 
expose TTL configuration directly.


> Anyways, to get back on topic I think it would be better to discuss TTL values for NS and DS records based on solid engineering. At present, we seem to be plucking numbers out of the air based on gut feel. Simply saying “I think the TTL should be X” is not helpful when without some justification for choosing X - or why X is better than Y - or an explanation of the operational impacts.
> 
> Anand and his colleagues have identified an issue. But I’m not convinced his proposal is the right one. LIRs may well have good reasons for choosing TTLs for NS and DNSKEY RRs that are higher or lower than the defaults that are being proposed. I think this needs careful WG consideration: unintended consequences and all that.

Let's be honest here. TTLs are _always_ wrong:
Either too long when you need to do a change, or too short when there is 
an outage and long TTLs would have helped to paper over it :-)

-- 
Petr Špaček