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@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