<No hats (obviously)>
On Fri, May 05, 2023 at 4:39 AM, Peter Thomassen <pe...@desec.io> wrote: > 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 > <http://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, > Well, yes… but where? To me it feels like the IETF would be the right place to discuss and develop the guidance (personally I think that a parent should check if the name servers that are being proposed actually answer for the domain[0], and strongly suggest (but do not prevent) that that be fixed[1]. As the most common place where this occurs is (citation needed!) at a TLD, I'd think that once guidance is created, someone (SSAC?) should push for it being strongly recommended / folded into ICANN contract. it would be great to use the opportunity not only to encourage helpful > checks, but also to discourage harmful ones. > Yup. I think that these should be of the forms "SHOULD / SHOULD NOT / RECOMMENDED", and not of the form "MUST / MUST NOT" — if I want to do something silly with a domain, I should be able to (as long as it isn't harming others). W [0]: Some, including myself, would call this lame, but…. [1]: As an example, I have a-random-test-domain.net pointing to nameservers which have no idea about this domain - and I did that intentionally… </No hats> > 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
