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

Joe Abley <> Fri, 05 May 2023 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 710F0C1522C6 for <>; Fri, 5 May 2023 11:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Status: No, score=-2.086 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CWHxkWyXzRpe for <>; Fri, 5 May 2023 11:45:32 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4A8BBC16B5B0 for <>; Fri, 5 May 2023 11:45:32 -0700 (PDT)
Date: Fri, 05 May 2023 18:45:20 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail; t=1683312329; x=1683571529; bh=/ydjF/hI+OAWI2V1lpKttULcblAsQ3ERN1PuvzAo6oI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=TNcUTsd7EywlE1Zm4bru/OKodblJ7x9mOz66ejcvNeVSJZiN4sU/SfHdlYggSekX8 30Dh01CuXQuIiGQxBAwENRmapci5DlgR9khcCdQkmIr9RzJx+LilhD63hNAardNMU+ d/oCUe2HbXH18429QbC9esY8W2piZvFMgVGY3E/glRr+NESMKmZKes7givUY7MeuW1 u+g++a7HA9UnwBHXs0cqimCr06+I8Uhcfzm/IIj7w+iFOAUO6Tq/3O60/GE7NJK4qJ uOtyTbHTdm960T9vfDvJYoq2rDy5sw60y3cy1EHiRvehCin8RRkbpJkfoU6ssn5HqO 4rmU6cmZ9HWew==
From: Joe Abley <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Feedback-ID: 73263797:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_YYGzk5OOjTUtXomWqbM1OPM2p7PzuKVIW4LLAaM"
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 18:45:37 -0000

Hi Peter,

On Fri, May 5, 2023 at 04:39, Peter Thomassen <[](mailto:On Fri, May 5, 2023 at 04:39, Peter Thomassen <<a href=)> wrote:

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

Pre-delegation checks add friction to the domain registration process. They further complicate the commuications between different actors in the commercial graph (registrars, registries, resellers, DNS operators, hosting companies) and introduce delay and manual intervention into what might otherwise be a fairly automated or at least automatable process. That is to say, checks have a cost, and that cost might well be difficult to sell in a commercial environment, especially one where the policy depends on a membership that is often quite commercially motivated. (I appreciate not all TLDs are the same.)

The ability to arrive at a consistent universal policy across many different policy regimes seems like a bit of a long shot. Some early adopters of increased friction will be at a commercial disadvantage to late or never-adopters of the same kinds of checks. This disadvantage will provide further disincentive to adopt this kind of check for those registries that are commercially-motivated. (I appreciate not all TLDs are commercially-motivated.)

So even if a clear technical best current practice could be published, I think there would be considerable work to do in seeing it implemented. I presume implementation is desirable, otherwise we're just navel-gazing.

On the technical side, I think arriving at a generalised approach will be difficult. For example,

1. Repeated checks -- just because something is declared good at registration time doesn't mean it might not go bad later. How often do you need to check?

2. The possibility of cascading failure -- a partial failure in a delegation, if punished by a domain suspension, might result in a complete failure. This is at worst an attack vector and at best contrary to the interests of stability for users of the Internet. Making automated changes to disable things that are already demonstrably fragile seems a bit like form over function.

3. Deliberately-incoherent namespaces -- many of the most common responses in the DNS are generated at response time according to a variety of dynamic policy, and are subject to access control. So vantage points matter. Any policy that is measuring the health of a delegation needs to be able to interpret the results of multiple measurements from different vantage points and understand which of them correspond to a policy that is acceptable, without any a priori understanding of what the response generation policy is. In general I think this is problematic.

4. The fiction of a single namespace. The particular bits of machinery that respond to particular names and particular addresses (including nameserver names and nameserver addresses) are not always the same. Private namespaces exist that avoid collisions with the nominally-public namespace by making the same domain exist in both, but implementing each very differently. This is valid and good advice, even (e.g. compared to squatting on .HOME or .CORP). Should those domains be suppressed simply because they are not intended for use by the general public?

My personal opinion on all of this is that there is already direct commercial pressure for delegations to be healthy when they matter. Services that depend on the DNS (or things reached by the DNS) that people care about generally have incentives to keep their ducks lined up (incentives like revenue, customer retention, being elected again). Things in the DNS that aren't well-paired with incentives like that might well break more often, but if a delegation breaks in the forest and there's nobody present to argue about whether the delegation is strictly lame or not, does anybody need to care?

To look at it another way, why would we give authority to a third party to break our domains just because they are not fully-informed about how we are using them?

And lastly, even if a delegation is genuinely broken and useless for all the world, and nobody cares enough to fix it, what harm does it do? What is the motivation to find a fix? A dribble of extra traffic relating to a mainly-unused domain to a nameserver that is already over-provisioned doesn't seem very compelling.

Even if I thought this was a problem that needed a solution, I don't think the solution is likely to be easy. The technical aspects are the easiest part, and those are already difficult. Perhaps we can just become comfortable with the idea that at any time the DNS contains bits that work and bits that don't work, and that is just the way of things.