[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
- [dd] DELEG and draft-ietf-deleg-requirements Paul Hoffman
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Wessels, Duane
- [dd] Re: DELEG and draft-ietf-deleg-requirements Philip Homburg
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Paul Hoffman
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Philip Homburg
- [dd] Re: DELEG and draft-ietf-deleg-requirements Ralf Weber
- [dd] Re: DELEG and draft-ietf-deleg-requirements Joe Abley
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Michael Richardson
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Philip Homburg
- [dd] Re: DELEG and draft-ietf-deleg-requirements Joe Abley
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Paul Hoffman
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Joe Abley
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Evan Hunt
- [dd] NS mandatory? (Was: DELEG and draft-ietf-del… Stephane Bortzmeyer
- [dd] Re: DELEG and draft-ietf-deleg-requirements Ralf Weber
- [dd] Re: DELEG and draft-ietf-deleg-requirements Evan Hunt
- [dd] Re: [Ext] Re: DELEG and draft-ietf-deleg-req… Paul Hoffman
- [dd] Re: DELEG and draft-ietf-deleg-requirements Tim Wicinski
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Paul Vixie
- [dd] Re: DELEG and draft-ietf-deleg-requirements Evan Hunt
- [dd] Re: [Ext] Re: DELEG and draft-ietf-deleg-req… Paul Hoffman
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dick Franks
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Evan Hunt
- [dd] Re: DELEG and draft-ietf-deleg-requirements Philip Homburg
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Joe Abley
- [dd] Re: DELEG and draft-ietf-deleg-requirements Havard Eidnes
- [dd] Re: DELEG and draft-ietf-deleg-requirements Ralf Weber
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Paul Hoffman
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Petr Špaček
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Dave Lawrence
- [dd] Re: DELEG and draft-ietf-deleg-requirements Stephane Bortzmeyer
- [dd] Re: DELEG and draft-ietf-deleg-requirements Petr Špaček
- [dd] Re: [Ext] DELEG and draft-ietf-deleg-require… Petr Špaček
- [dd] Re: DELEG and draft-ietf-deleg-requirements Petr Špaček
- [dd] Re: DELEG and draft-ietf-deleg-requirements Petr Špaček
- [dd] Re: [Ext] Re: DELEG and draft-ietf-deleg-req… Paul Hoffman