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 _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
