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

Brian Dickson <> Fri, 05 May 2023 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C0CBC19E113 for <>; Fri, 5 May 2023 14:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ulF665K1IAks for <>; Fri, 5 May 2023 14:29:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (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 AA3CCC19E0FF for <>; Fri, 5 May 2023 14:29:50 -0700 (PDT)
Received: by with SMTP id 41be03b00d2f7-52cbd7d0c37so75222a12.3 for <>; Fri, 05 May 2023 14:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1683322190; x=1685914190; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QsUpwHFrNU1RfQUIPNFZ+7jhkSd9o6z6FQKB1YHTGys=; b=ZE8tg/MbdV97l5lmMdLKnhS5fPScr5BKQp/ao1As1VwdHMDjAHogDaaeBlTzZ6DfdG zT+rwcdDfWGQg0Mv70HSQSQuDy7sPRM5CDp4H3R3FTKjk29hJbuxm2vzlq1Gf38BkcJG G7JRHeICZn75SAQfA+/lNzEDvGqrnmKPWTEX4XfumuGTM+QxDZu7NxWmQfo0sQuTtjtT PnCvz0DUh2rwviiCL9p7V8k7tBGe8RQCeRMh73vsgo1oHw3vErF/+YMiVo6M91MamHQM h6tOdb8BCSxu1JiAoJMDmFLpFQMDJzG4Ted3o5ifde2IxWIXdHyvjNgsauGFzlftzcLg wB3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1683322190; x=1685914190; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QsUpwHFrNU1RfQUIPNFZ+7jhkSd9o6z6FQKB1YHTGys=; b=MONQOyP6DSkrspbvSs0IYQ3NoqwqsWvJNHIp9eg/8DFTHPyVaCk8grJrl3GLwcPoeQ 7Z5bPKZBmrb9SnEDXBjMyWtChAzNFvYv635vzcb2SJwgvHAdDy/bgOatVJYbbhVrfxqt e/N3KYib++WSiluqnVotNiWxFBFp0Wn0KyVLX5+ZfHaZd6FrVqLSaegg6az4tKDc8AUM vhaYvOp/r6+g+PI/M9THJi2WPf1MHacWJcIW+hRlglOOS7fr3qNPHyD19LAGP0fCTQMf 8VjO9doxiUY2tOciVcXf/gGB75+BvqUn3S5ZTUvh4pSusVPEasHr7g2GijXQSlDFjGp+ zz/g==
X-Gm-Message-State: AC+VfDyKm/WcGubS8LgsF4hHfsPDdNMPKnphweS4fEDqxG3kzw2JqqJ4 UybWrev03oBAw3T9xE8wtSwvc3hmCyQpHQQAWME=
X-Google-Smtp-Source: ACHHUZ5ot5MtSnfbhXPqScZzoa8TBcOX9ie9R7a8cS0Cd4jzdKwScH2vrtDPg9Cm8yKOKhRpHtvyZOVVb3KkytrR8+8=
X-Received: by 2002:a17:90b:198b:b0:24b:8480:39d6 with SMTP id mv11-20020a17090b198b00b0024b848039d6mr3146015pjb.0.1683322189862; Fri, 05 May 2023 14:29:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 05 May 2023 14:29:38 -0700
Message-ID: <>
To: Joe Abley <>
Content-Type: multipart/alternative; boundary="0000000000002b5dc105faf8fd72"
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 21:29:55 -0000

On Fri, May 5, 2023 at 11:46 AM Joe Abley <> wrote:

> Hi Peter,
> On Fri, May 5, 2023 at 04:39, Peter Thomassen <
> <On+Fri,+May+5,+2023+at+04:39,+Peter+Thomassen+%3C%3Ca+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
There is also the notion of indirect checks vs direct checks, with
reporting/signaling/scaling elements.
I think the work on trust anchors (done for gathering information to inform
the root key rollover) would be one relevant example to consider.
Other work (recent or in progress) related to reporting to domain operators
(don't recall draft or rfc identifiers) would also be useful to examine.

3. Deliberately-incoherent namespaces
This is definitely something that any proposal should accommodate. One
approach would be looking at opt-in vs opt-out mechanisms, possibly
anchored under the namespaces of NS names.
Scaling for all of these sorts of mechanisms is also very important, given
that the first priority of the DNS system is answering queries, and
anything that impacts performance needs to be tempered appropriately.

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

This is an important consideration, for sure.

I think any proposals should start with a couple of things;

   1. Identifying what parties are interested parties and/or involved
   parties. Depending on specifics the number could be large, but in the
   general case there is a minimum number of parties that are necessarily
   involved. Enumerating those, and what their roles in would be a good place
   to start.
   2. Determining authority tied to those parties and their roles. The
   canonical example would be the operator of a name server, should be
   involved in decisions about whether or not a given delegation should be
   allowed when the domain is not served by the name server.

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

This is where I can add some useful data and context.
Operators of substantial numbers of zones where this traffic is received
are able to quantify the impact.
At the servers under domaincontrol dot com, the normal traffic is over 15%
queries for domains not served (i.e. lame zone delegations). That is a lot.
Additionally, lame delegations are abuse vectors. We see much abuse via
this vector.
And lastly, the current state of affairs is that we are unable to directly
affect this, since the RRR model does not include a role for DNS operators.
(We are also a Registrar, but when the domain has a different Registrar
than us, the RRR rules do not facilitate us removing lame delegations to
our name servers.)

I do have some ideas on mechanisms, but those probably belong in their own

I.e. the issue isn't specifically "pre-delegation checks", it is
"delegation correction".

> 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.
How I wish that were the case. It is not, at least not for everyone, and
certainly not for us.

The abuse vector is similar in nature to the Kaminsky poisoning attacks.
The attackers have mechanisms that are fundamental to DNS which operators
are defenseless against, for which only systemic corrections can address.