[dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

[Paul Vixie]

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.

-- 
Paul