[DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Peter Thomassen <[e-mail]>]

On 5/4/23 20:07, Havard Eidnes wrote:
>> As an example, it's quite common for people to register a
>> domain and point the DNS at some nameservers which they don't
>> control, and have no relationship with.
> 
> If this is common, I'm abhorred.
> 
> Having the delegating party check for service for the requested zone
> at time of delegation request and refuse to update / register if
> this check fails

It would be interesting to develop a consensus position on acceptance checks for delegations. (Obviously, that's out of scope for this draft, so renaming the subject.)

I can see some value in such delegation checks. However, I think that very clear guidance on what kinds of checks are acceptable would be helpful, to avoid checks that primarily cause trouble. Examples:

- DENIC customers have repeatedly reported to us (deSEC) DENIC's warning on how our SOA REFRESH and RETRY values should be related. We think it's entirely a matter of how the operator arranges their replication, and the parent should not be concerned. What's more, the DENIC recommendations are in contradiction to RIPE's. [1]

- Lots of tools and some registries check reachability and other configuration details of the SOA MNAME, although the MNAME again is an internal matter to the operator. (Could be using a different replication scheme; could be a split-horizon setup; ...) For example, NIC.it rejects nameservers whose SOA MNAME is a CNAME [2]. Tools like MxToolbox, Zonemaster etc. trigger warnings when the SOA MNAME has no DNS service [3]. Other tools complain when the MNAME isn't dual-stack [4]. We receive similar complaints about the "serial date being in the future".

- ISNIC recently started rejecting new delegation to deSEC (and warned to delete existing ones) because our zones allegedly don't have NS records. It turned out that their delegation tool did not honor the extended RCODE field (RFC 6891) which is why BADCOOKIE appeared like YXRRSET to them, and the tool gave up. (No public reference though, and it's been fixed within a few days.)

While I'm not generally opposed to parents checking whether a delegation update would break the domain's resolution (this is like the CDS acceptance checks, and makes sense for NS, too), I do see some risk in encouraging people to do more checks.

I imagine that others also spend time on sorting out these entirely unnecessary issues. If guidance were developed on delegation acceptance checks, it would be great to use the opportunity not only to encourage helpful checks, but also to discourage harmful ones.

Thanks,
Peter

[1]: https://talk.desec.io/t/default-soa-does-not-match-denic-recommendations/520/2
[2]: https://talk.desec.io/t/nic-it-cnamehosttest-failed-changing-nameservers/432
[3]: https://talk.desec.io/t/invalid-soa-record/68
[4]: https://talk.desec.io/t/reachability-of-digga-desec-io/339

-- 
https://desec.io/