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