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 <[email protected]> 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
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/dns-wg
