[dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode
paul at redbarn.org
Sat Apr 4 21:56:06 UTC 2020
On Saturday, 4 April 2020 20:21:01 UTC Doug Barton wrote:
> Sorry, wasn't clear. I was making a general statement when I said that
> the child should be able to determine its own fate, not responding
> specifically to something you said.
ty. on that narrow topic, i will separately disagree. a zone is given rise to
by some delegation (NS and DS RRsets), and if those are removed, or rolled
over 100%, or moved upward (toward the root), then the child's existence
should be at instant and reliable risk, and subject to rediscovery. this is
vital not just for redelegations where the old child zone can't be modified
(e.g., to turn down TTL in advance) and in de-delegations where the child has
been the subject of a takedown action.
only where the elements which give rise to the child's existence are still
present should a child continue to function. this is absolutely vital, and in
the interests of both registries, registrars, registrants, and RDNS operators.
that the child should be able to steer its fate within those constraints is
something we would agree about, if you held that broader view. for example if
a child turns down its apex NS TTL, or churns its apex NS RRset in advance of
getting the parent to do the same, or alter any of its own content. DNS is a
distributed, coherent, reliable, hierarchical, autonomous database. existence
of data in the DNS should be a matter of polite general cooperation.
More information about the dns-operations