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/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
