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

Warren Kumari <> Fri, 05 May 2023 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EF1FC13AE56 for <>; Fri, 5 May 2023 09:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_RED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8HsHpbrwsKbe for <>; Fri, 5 May 2023 09:17:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 6EC75C15199F for <>; Fri, 5 May 2023 09:17:10 -0700 (PDT)
Received: by with SMTP id d75a77b69052e-3f0b30f240eso15529221cf.3 for <>; Fri, 05 May 2023 09:17:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1683303429; x=1685895429; h=cc:to:subject:message-id:date:in-reply-to:references:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bx4JGvI2LEAQFIxwvzhmUfjNb1swuv/Xso6viB3l2FI=; b=AIPK2rQdMIaC1pE1OB/XVX4O52fRnje31OtrJIfi8Ams2RreoOxtBnVHtY0F4lG/e9 ZT84ut9fOJ/wBA+RKbXOZubVyNKj6l9njr7ryxxTJPeMmU7Dh2QhFVJ/88rssFX4b1Im rNgG4dOBb2ca4GKDKHU2xcx73ZVzD2SB0es7Oi8fiHel44UHDZsNf4xnvLvRlovUCXkM 469/3DWrQtBBRsDrroV6ueIo8jSsG9J+4vIbrD4Iotxxw/RSseVuN3yIsCUx+Itsi/jO YxMeEafvbbkeTzO8lfWFSmjMlpD70v3/kWqvcg5lKh8NZ+D0PUU30wPKjkiX6FLn7AFc qFJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1683303429; x=1685895429; h=cc:to:subject:message-id:date:in-reply-to:references:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bx4JGvI2LEAQFIxwvzhmUfjNb1swuv/Xso6viB3l2FI=; b=mBjcUNpoTXBVzFO/uyNN6aqNwBYb9ibvkO1yOsgWYpmu3H837xwdQXgGSn6PlefdxM OfOTZk9ox7IeGPPhxP++gToVQ2j0E7s2hJwuXJ3/XHkzPJVztHznSsRAMwirE6h7xyI2 oyGUx9wljGbIUbDpZEWYeIK7CpNNn6SR7icI4mXMizQFYYY27JkGHfhOE8sBGJfrC9Ts +mXvF6BXz9hymkfnDcG6BzHngJrmhvd99lb09upOnPXVLn6WiW8es1DrMvfRXx+B99kJ zDd0owEcF4PSGrX5myiX9e/gqXZHbV7uo+dH5+hogC673VqSZjXcNQb/G8MFYVFW8IKs sedA==
X-Gm-Message-State: AC+VfDw3xawTCfov+5CUaNs9jxY7/5auOiPz2U4wBs2h2VU8QeSJWmpN 6Jdn5pcviG3t0CaPLQp4Ph8XalEqdGoL4SABoKKXbAR2sQIesaCK
X-Google-Smtp-Source: ACHHUZ7e95CHcgc5a1MXr+Wu+MHnsQ7H8YRQZW46Sy0eBPLezigGbJ2cV0NteKS3O76USfD+WsqBbm0ai+WfZqrs1c8=
X-Received: by 2002:ac8:5745:0:b0:3f0:a755:61ef with SMTP id 5-20020ac85745000000b003f0a75561efmr3520780qtx.0.1683303429014; Fri, 05 May 2023 09:17:09 -0700 (PDT)
Received: from 649336022844 named unknown by with HTTPREST; Fri, 5 May 2023 11:17:08 -0500
Mime-Version: 1.0
X-Superhuman-ID: lhardy3e.492fd8f9-691c-450a-aa8a-ff4c73e530c5
From: Warren Kumari <>
References: <> <> <> <> <>
X-Mailer: Superhuman Desktop (2023-05-04T22:06:06Z)
X-Superhuman-Draft-ID: draft00c94a288c9dde51
In-Reply-To: <>
Date: Fri, 05 May 2023 11:17:08 -0500
Message-ID: <>
To: Peter Thomassen <>
Cc: Havard Eidnes <>,,, Nils Wisiol <>
Content-Type: multipart/alternative; boundary="000000000000ef99e205faf49ed7"
Archived-At: <>
Subject: Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 May 2023 16:17:15 -0000

<No hats (obviously)>

On Fri, May 05, 2023 at 4:39 AM, Peter Thomassen <> 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,
> <> 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.


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

[0]: Some, including myself, would call this lame, but….
[1]: As an example, I have pointing to
nameservers which have no idea about this domain - and I did that

</No hats>

> Thanks,
> Peter
> [1]:
> default-soa-does-not-match-denic-recommendations/520/2
> [2]:
> nic-it-cnamehosttest-failed-changing-nameservers/432
> [3]:
> [4]:
> --