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

Rubens Kuhl <> Fri, 12 May 2023 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AB74C15256B for <>; Thu, 11 May 2023 19:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iMfAs-Vka24i for <>; Thu, 11 May 2023 19:31:52 -0700 (PDT)
Received: from ( [IPv6:2001:12ff:0:4::15]) (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 D1B35C1524AA for <>; Thu, 11 May 2023 19:31:50 -0700 (PDT)
Received: from (unknown [IPv6:2804:431:c7c1:e19c:c50d:8d2:e046:7aa4]) (Authenticated sender: rubens) by (Postfix) with ESMTPSA id BB60EBD016 for <>; Thu, 11 May 2023 23:31:43 -0300 (-03)
From: Rubens Kuhl <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Date: Thu, 11 May 2023 23:31:32 -0300
References: <20230506155052.4A3C8CF9B318@ary.qy>
To: dnsop <>
In-Reply-To: <20230506155052.4A3C8CF9B318@ary.qy>
Message-Id: <>
X-Mailer: Apple Mail (2.3731.500.231)
X-Rspamd-Queue-Id: BB60EBD016
X-Spamd-Result: default: False [1.49 / 15.00]; URIBL_RED(3.50)[]; BAYES_HAM(-2.51)[97.77%]; MV_CASE(0.50)[]; HAS_ANON_DOMAIN(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:27699, ipnet:2804:431:c000::/37, country:BR]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; NEURAL_HAM(-0.00)[-0.983]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]
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, 12 May 2023 02:31:54 -0000

> Em 6 de mai. de 2023, à(s) 12:20, John Levine <> escreveu:
> It appears that Joe Abley  <> said:
>> 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. ...
> Thirty years ago, when you did domain registrations by e-mail, the
> registry which was then called Network Solutions did indeed check that
> your name servers were active before delegating the domain. It was not
> an accident that they stopped doing so, and it seems vanishingly
> unlikely that any gTLD registry would do so now, regardless of
> what people here might think.

Actually, there is one gTLD that does that: .rio. A domain can be registered without working DNS servers, but it won’t be delegated until DNS servers answer with authority for that domain. 

.rio also checks DNS authority when a domain updates its delegation set, and promptly denies the update if not (different from the create where there is a continuous check waiting for authority to appear). 

But this is likely due to .rio getting infrastructure from a ccTLD operator that happens to do similar checks… although in .br lack of DNS authority prevents registration, different from .rio. 

It’s not that pre-delegation checks add friction per se; it does if TLDs A, B, C do not perform them and TLDs X, Y and Z perform such checks. This makes other parties in network the graph (regardless of them being commercial, education, non-profit etc.) expect one behavior or the other, and fail in some regard when the practice of a TLD is different. 

But I will add one other party to the network graph that benefits from pre-delegation checks: Internet connectivity providers. Lame delegation makes DNS recursive servers to spend more resources to get no usable response, transferring load from registries/DNS operators/hosting companies to them. 

So, it would be really interesting if a standards-track document defines which behavior to follow so everyone can sing the same song. I just don’t see that happening.