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

Peter Thomassen <peter@desec.io> Fri, 05 May 2023 08:40 UTC

Return-Path: <peter@desec.io>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 038DBC151B3C; Fri, 5 May 2023 01:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XY7P6dnxc3_E; Fri, 5 May 2023 01:39:55 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C543C1522A0; Fri, 5 May 2023 01:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=srdwWi/6TYsbcwrul/7lPt+wv99EPVo6OrpxnVb/D2k=; b=L35Z5fJ/D2ZXPArOayRDxjidJY D3F8ueLPYDrFK65xNi41zpx4LiJFSC9qo0HY6xEw25W1ktH8UJT54K5iT5vm6JrxpU43ZH9F+ZMWD KqTtpEWCv4FSC+aF3Js+b4V7bPFu8kL2+AtJno8Qo559ImRCxFUFPBaL/E8cQM82K/kTD7RbOYVi9 NG6x5E9mTBj7HWwdLoRHMnjf0UUeu2iRg4zt3r69XqPRozOxP4SutRJSERdkmC6r9nPE8OCO6G70T WWM3/9IaxPdpZTnyKOYu8c8692gTRg/Jqu8oFLy1Z9YAT/zPuoPMa4h2gwU/sVd0DZt+RfSI+ZWvX 9tejhD7Q==;
Received: from ip5b41b091.dynamic.kabel-deutschland.de ([] helo=[]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1puqyg-001sMM-5r; Fri, 05 May 2023 10:39:46 +0200
Message-ID: <8ee0d0dd-685b-f767-e5bd-d722cc873dc8@desec.io>
Date: Fri, 05 May 2023 10:39:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Havard Eidnes <he=40uninett.no@dmarc.ietf.org>, warren@kumari.net
Cc: m9p@india.emu.st, dnsop@ietf.org, Nils Wisiol <nils@desec.io>
References: <1C10367C-B890-426F-A4F8-2D68E903ED39@icann.org> <0.2.0-final-1683191254.797-0xa08e34@qmda.emu.st> <CAHw9_iLyz4dhjmXm=eeqiVqQWOjYOgs45NbCtRtvrYpTFQHz=w@mail.gmail.com> <20230504.200747.619569100111463947.he@uninett.no>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <20230504.200747.619569100111463947.he@uninett.no>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Wmr1eq4buDFPQqEM4sv76eRiGFg>
Subject: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2023 08:40:00 -0000

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.


[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