[dd] Re: DELEG and draft-ietf-deleg-requirements

Petr Špaček <pspacek@isc.org> Thu, 13 November 2025 11:16 UTC

Return-Path: <pspacek@isc.org>
X-Original-To: dd@mail2.ietf.org
Delivered-To: dd@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6344888AE34C for <dd@mail2.ietf.org>; Thu, 13 Nov 2025 03:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="JGpuqLs9"; dkim=pass (1024-bit key) header.d=isc.org header.b="go+2ADls"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiQZ3JFPcJM9 for <dd@mail2.ietf.org>; Thu, 13 Nov 2025 03:16:29 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E613188AE340 for <dd@ietf.org>; Thu, 13 Nov 2025 03:16:28 -0800 (PST)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (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 mx.pao1.isc.org (Postfix) with ESMTPS id 2D59E4E453C; Thu, 13 Nov 2025 11:16:28 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 2D59E4E453C
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1763032588; cv=none; b=C4A2JdcwKm09cTyqg72lE33ZkckQ+ixisaPsTE4dC+sgi+neClHbh1Ov+VrIFHyQRM04CYeGW1qnetSJDRzM6USCweghxGfTuhHI854BVry3TzD+xj/p4es/E+KsRPr7rib0BzmnSNZpk+gwcxLjfcGX3RJPp3cf+45OJOGvwjM=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1763032588; c=relaxed/relaxed; bh=TQdQyTejGpyZZo/I19dF+BGFKZJlXn1rKlAzSIy0tPI=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=pUzdwZMnrUdJQ4Nd7FaRYkp6s+IBL2mstqcqxIPdQBWBxLHIhGvy7DCqiH/AwCBbFPImrfPsNSqYSUZbqD8M2Id/LZp7VQTJsMHTZfo/S7nVePiZ2Ox9zJc421fm2bXOHWQJBz07V3Un5vfp0KKbCEdBnCw4WzmzvreC5oBsyPQ=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 2D59E4E453C
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1763032588; bh=4oPC3Tje4l/BviQBygsBgWjxQcOS/qaWkpq8DHWveEE=; h=Date:Subject:To:References:From:In-Reply-To; b=JGpuqLs9dfqjBxnsa9foxQMN5ciFJQdmBKs8oAtHjDikvS697uJ9hIW7MyNKBBJDB 5+q5peHzf95dVZ5VBMhDjhOCCfri4PRjv2tW89PZSi9zhGPphMUQL7z7WCJdFerCGS NLvWjBQ2W0xj/lt/NWDeR9BRhZMV2gTD3pHd6Qk0=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 296CE2E60235; Thu, 13 Nov 2025 11:16:28 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id 25EE32E6024E; Thu, 13 Nov 2025 11:16:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org 25EE32E6024E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1763032588; bh=TQdQyTejGpyZZo/I19dF+BGFKZJlXn1rKlAzSIy0tPI=; h=Message-ID:Date:MIME-Version:To:From; b=go+2ADlsAvM/YCv7YE2YgJtSnmmPVHyx8/EKAnZOcnO12Jb8TF1yl+O/ktDIDJ65Z SGTxy+F9zkSZKOVv8zNKKi318BS1TOpYr9oMdqMmM/gjlTvM+2Db4G+ZmfbwxAzZO6 fV7jAOH0v/c3K33Net5TMO+GxXq5vzwHc44Kx1jY=
Received: from [192.168.35.197] (ip-86-49-241-95.bb.vodafone.cz [86.49.241.95]) by zimbra10.isc.org (Postfix) with ESMTPSA id 996FC2E60235; Thu, 13 Nov 2025 11:16:27 +0000 (UTC)
Message-ID: <b80a4583-fad1-4ceb-a1a0-32c13fa33dcd@isc.org>
Date: Thu, 13 Nov 2025 12:16:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Dave Lawrence <tale=40dd.org@dmarc.ietf.org>, dd@ietf.org
References: <m1vITOh-0000NWC@stereo.hq.phicoh.net> <01499496-E6D4-4A94-99C3-46BC2AA5BA14@strandkip.nl> <26899.41867.286676.213818@gro.dd.org> <aRO3whK9ZVPPftib@isc.org> <CAKW6Ri6-qjoLtoLY7RL=Use5KA7sS+rxDOXUSP9dYO6_=3j9Pw@mail.gmail.com> <26900.822.28917.864407@gro.dd.org> <m1vJ5qI-0000NVC@stereo.hq.phicoh.net> <26900.32365.331378.28050@gro.dd.org>
From: Petr Špaček <pspacek@isc.org>
Content-Language: en-US
Autocrypt: addr=pspacek@isc.org; keydata= xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmd7vqsFCQmG4S0ACgkQq9WHzfBlga5H dA//SNIJAXyYxpoIrQwtTSOded93J+CIYHd2ArxCsS+ZXzeaSkHcqp2QfneLY2yyiQwjeivu MfqEBIASNZ94T+4OjhEHAFaAUJQtYMY7qmH69Q5h1PQMk/HZX4QNEDB6dihjz4wunB2mRcac GnRziAQUAnlHSSZDU2EtTddmRYTCaeX9rU8O5ja0+qPBJket7PjS0yT8DQJF+aKRsQz17ywT 3rNR7NBgeKrkBud4/zE7VRoxSRCPkWkgixEog+AotZt22psgQTv+kWx89+7cTiFZaLMmtV6v Ws8QTpDRDM3hCJBCI6qk61k8SLuQ+5VuVWBM/ozoN1ON2J9anxVTrxhNsFM3RLHV/Qh9p/0y T4our7JxB6dsos3HtlRR2npXS1PMrrXt7ZnnfYao+9zbOrZHC7NRY3feaLhieLx1pKmdDRHT CAbqaGnqX22hYYemtYFzSAv7stCdqdncAEkZJy4HByjQwFVGn8A6rp7H1xV2LmlkNAMEoWrT GJ+wH8A+VA3qbZF9Ab8Ht2GRj3mQQ4h8NnRYjKyqecCQOI5Xmn4S61nQ9y+wOBUSTlAQ6a5n LmMpCVe2/D4pWFxpUxc1z8Hq+uEN95sPgbihiSdgBR50DRdqW57ulFHA9LKJ0AEnBtQfvVth qAkvG8iBYl+UpoX1xW+dbX2g6nI5Rbx8u+EojKXOwU0EX84n/gEQANARNXihDNc1fLNFZK5s O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC Z3u+zwUJCYbhUQAKCRCr1YfN8GWBrmljD/45mvtqiWzATkikxkJjTlxfhJBGUFXUoPXqvo8l 8zACTTnn6/K7v1TcFmtSHtLqQiTGwwq1vGQSjEG+UFzdXohex9MTv+7JHr+fcQfxFtxYeVGn k9fSkRkIdtpUzuCnBC27VYbq5S+nk4+ophmjm7rFVWd4tz+XTFZkuHTRImWxbaF9EZ/fuWmm XaICw+lzGan9BteM1ZSLIjzSPd7LoG55SuoVtAV91J5oLPo6KDOzgPEffalm2LJo7+ZaAeW6 diQUXxQpvAAROR/l1D1DIIQ0OJOqv0QRFyHt/zBbKgWmGaTQqF5aNab4ukVAt0LMsCkCjA11 HhcUnUwrixHR4V8G3UlHTQsWReiXfPerv/BewTsPHSzIfmufNlrBDfS/uIYdwquZfhOSsK9Z DUJFkaHudJC6tRVQ5LBVFqjgtZDllpAj1cOG7WmlTwHblj/r2+LMpOVHApByNkehEOA2c4Bn tcQ/8qSeorJCyd1/5A5+bUFIfIAJbRz4Ja21JgH107oCMX3hsGEzMnuwplYTf9NP4Dq0FQhK vkXzdnDhhXef8nUqF7l32hj9x1BCLFZ4FFe6iuKD7Q9p83Ca1HDdxauIrsrXTsEr1bjg2o/A JXI4A3sUunmiIf/tu+3riXUhA10P1IG11yEQ4y9ogE6knvOraRBwZ8gvFT7J2YLXJrF5mQ==
In-Reply-To: <26900.32365.331378.28050@gro.dd.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: ZAWYFLLEA2T7S32R3334YSCMEJSQOLFI
X-Message-ID-Hash: ZAWYFLLEA2T7S32R3334YSCMEJSQOLFI
X-MailFrom: pspacek@isc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dd] Re: DELEG and draft-ietf-deleg-requirements
List-Id: DNS Delegation <dd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/7NdL0-Cma-wJQL6sDF8H8e7okXQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Owner: <mailto:dd-owner@ietf.org>
List-Post: <mailto:dd@ietf.org>
List-Subscribe: <mailto:dd-join@ietf.org>
List-Unsubscribe: <mailto:dd-leave@ietf.org>

On 12. 11. 25 13:32, Dave Lawrence wrote:
> Philip Homburg writes:
>> Similarly, if a query with DE=1 results in a delegation using DELEG
>> records then the same query with DE=0 SHOULD/MUST result in a
>> delegation with NS records.
> 
> This might surprise you, but I agree.  We can say that.  My main
> positions are that we should not require NS records that point to
> usable nameservers, and NS records should not be generated from DELEG
> records directly.
> 
> On the first, we already don't demand NS records like that, even in a
> pre-DELEG world.
> 
> On the second, it means putting more stuff in the DELEG record whose
> only point is to be used for synthesis, which can be achieved by other
> means.  It is an unnecessary complication in the DELEG RR.
> 
> I'd be pretty content with something like:
> 
>    * when answering a DE=0 / DELEG-only query, use [delegation-to-nowhere]
>    * [delegation-to-nowhere] might well be "NS ." (works with your text above)
>    * zone generators are free to use external mechanisms to get
>      different behavior for other possible NS records

My view:
- Currently all variants (NS only, DELEG only, NS+DELEG) are technically 
possible within the current wire protocol spec.
- There is no _technical_ reason for limiting this.

If particular operators of authoritative servers want to always have NS 
present - sure that's local policy. IETF should not be making policy 
decisions for protocol users, which are a very broad group.

During IETF 124 me and Ralf spoke to 4 different registries and none 
objected to the current protocol definition (all variants possible).


Another reason to NOT hard-wire NS synthesis to spec is that it might 
limit possibilities of how to implement it:
- It might be easy to do arbitrary RR generation in with online signing.
- It would be uglier for generic auth with offline signing.
- It can be handled in DNSSEC signer software.
- It can be handled in zone management software, e.g. the thing which 
translates registry database into zone file. Suddenly we are way outside 
scope of DELEG protocol itself.

I don't see any technical reason to prescribe how exactly it should be 
done, when, where and by whom.

-- 
Petr Špaček