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

[Warren Kumari <[e-mail]>]

<No hats (obviously)>


On Fri, May 05, 2023 at 4:39 AM, Peter Thomassen <[e-mail]> 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/
>