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

Mark Andrews <> Mon, 08 May 2023 02:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EC0CC151524 for <>; Sun, 7 May 2023 19:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 (1024-bit key) header.b="T8Hsx4Hy"; dkim=pass (1024-bit key) header.b="n3lghCoi"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ayr35WN1qyHw for <>; Sun, 7 May 2023 19:36:16 -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 AA190C14F5E0 for <>; Sun, 7 May 2023 19:36:11 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPS id 326143AB008; Mon, 8 May 2023 02:36:09 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 326143AB008
Authentication-Results:; arc=none smtp.remote-ip=
ARC-Seal: i=1; a=rsa-sha256;; s=ostpay; t=1683513369; cv=none; b=Z+Kww8BH78nn9s/ztyaTFFAht0h3Zg1PVeKsldzSiyMm0GJPe/glQp3MT5L6U0zVjhWX3h9Y1NbydQpFN6HxUnb33YUZVdqiLRIfcg1zbh/1pJjRtekpJ4RgcakUQQQ0ACxg+2nMJF/NDe7u1ewzkxGPHULhkZ4G7PDjJMm97aY=
ARC-Message-Signature: i=1; a=rsa-sha256;; s=ostpay; t=1683513369; c=relaxed/relaxed; bh=woZjUDEKuuHpdZ55PrJw89RTuM8b0ujjtEl++DPhUk4=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=iB9Fq3bnkaz0XG0eA+0pha/E7r8zCnr53XNv9HHtdc1odR9PTSvoXq7vbE22yOvgCfHf16Gh5m1nrkaKfjTQ/btRkjWU/ubJKD0CP9Gw1/mUDCGDsRC+yyjVR7q2k1NnpT2nUArwwmwNTBn3WoBmrvFA64D2sve1Kh4hlxEypRQ=
ARC-Authentication-Results: i=1;
DKIM-Filter: OpenDKIM Filter v2.10.3 326143AB008
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1683513369; bh=GhfJa/0qVZ6WhdTOVKxrNRMmliQ/zukjScUZH+CXNnU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=T8Hsx4Hy/B/+O3pdwEFgFl/cTQOLsBe6/XJUwM0By1ydKZ/qLq8zVcS7lNEqMbqYF WdgtUNKByT5XGHa8mBZkwwVMz7hjJHGtDXkz/wLyyQEm5Rlsga+0Oilhet4tvhzFnD DpGAVmDG4uE16WsDCCWxoQi+Zr3GAggXPQ2F1z7A=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id 19EC7FE6FC4; Mon, 8 May 2023 02:36:09 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id C5E99FE7008; Mon, 8 May 2023 02:36:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 C5E99FE7008
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1683513368; bh=woZjUDEKuuHpdZ55PrJw89RTuM8b0ujjtEl++DPhUk4=; h=Mime-Version:From:Date:Message-Id:To; b=n3lghCoiQ/0dW50SRyKtMRN70ahxwnz7LuHhG/BxcJpsF398fMhejxl1c7op5uOOV VCmHDc3ew/oalpcHMUY5ym6Kmqxw+jX9JeI4L3b8z0l+i7ixoCxq9JQUe3LKSEHaUe rwtstYIXNOlpp/0npYRGjYENNsXrTM/uuXHdDiN8=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id DWkIEvXm8peR; Mon, 8 May 2023 02:36:08 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id 9A651FE6FC4; Mon, 8 May 2023 02:36:06 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Mark Andrews <>
In-Reply-To: <>
Date: Mon, 08 May 2023 12:35:59 +1000
Cc: Peter Thomassen <>, Havard Eidnes <>, Warren Kumari <>,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Joe Abley <>
X-Mailer: Apple Mail (2.3731.500.231)
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: Mon, 08 May 2023 02:36:20 -0000

> On 6 May 2023, at 04:45, Joe Abley <> wrote:
> Hi Peter,
> On Fri, May 5, 2023 at 04:39, Peter Thomassen <> 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.)

Then just have them all be post delegation checks.  If the servers listed are not serving within a week pull the delegation.

> 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?

Daily.  There are no zones where this is anything like impossible to do.  A single threaded process can do tens of thousands of requests a second and can be testing hundreds of thousands on delegations simultaneously.  We do this every day with the compliance checks on

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

So?  Stability of the DNS is already broken because of broken delegations and non RFC compliant server implementations.  It’s only mostly working at the moment because resolver vendors go to extraordinary lengths to work around the broken configurations and implementations.  No one is saying one strike and you are removed.  I would expect people to be given a reasonable amount of time to correct the issue along with repeated waring to multiple contacts.  That said once you start penalising broken behaviour people will learn that penalties will be applied and will proactively fix things that they know are being checked.

This is nothing more than the equivalent of a vehicle safety check.  For most checks the mechanic will say go get this fixed and come back to me in a few days for a re-check.  There are very few things where the mechanic says you can’t drive this car away as it is so unsafe that you shouldn’t be driving it, if you want to take the vehicle it needs to be on a flatbed.

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

Please show a single instance where the delegation can’t be made coherent at the TLD level.  Nameservers and their addresses are relatively stable compared to everything else in the DNS.

> 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?

Well if the public side of a delegation is getting answers from the private version of the zone there is a problem that needs to be addressed.

> 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?

They ALL matter.  Broken delegations get used by bad actors to cause additional load on recursive servers and on authoritative that are being referred to incorrectly.

> 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.
> Joe
> _______________________________________________
> DNSOP mailing list

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: