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

[Viktor Dukhovni]

On Sat, Apr 04, 2020 at 09:56:06PM +0000, Paul Vixie wrote:

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

That said, there are also unfortunately cases where a DNS hosting
provider allows customers to shoot themselves in the foot and not only
change various non-infrastructure records, but also update the zone apex
NS RRset with servers from another provider that have independent
unsigned copies of a signed zone, or are otherwise not properly set up
to actually handle the domain.

I'm therefore sympathetic to Google's parent-centric approach (one
source of truth), without denying the desirability of letting the child
zone adjust TTLs.

Of course, we should probably not overly optimize the design for the
minority of cases that are broken.  The majority of cases where the
parent glue and child zone apex don't agree are benign.

For anyone who cares about the reliability of DNS for their domain,
monitoring should be in place to detect inconsistency between the parent
zone glue and child zone authoritative NS records, and discrepancies
other than ones expected briefly during a migration should be addressed
promptly.

DNS hosting providers should ideally caution users about custom NS
RRsets, especially for zones signed by the provider where there is no
AXFR arrangement in place for the additional external nameservers to
serve valid copies of the zone.

-- 
    Viktor.