[DNSOP] Re: on the more general problem of delegating to other namespaces in the DNS
Peter Thomassen <peter@desec.io> Tue, 24 June 2025 10:28 UTC
Return-Path: <peter@desec.io>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C7F6738AE88E; Tue, 24 Jun 2025 03:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=desec.io
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 Bvimq10h4G-U; Tue, 24 Jun 2025 03:28:56 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A587738AE889; Tue, 24 Jun 2025 03:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=desec.io; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jbkOAmfT1BIvbDID64O7mFN3bgjQwV1yUkmlc9B1kNc=; b=EcznsZGZ2t/ZcEeFwnsx2ghwGR /ymAJDGEk2CuFcgiUIatRGSqwNzjSnx0FWQrZHKox7P8XTy2zx8s2BZkuCRSJ2KW/eHolaxVc3o0s uvFJlPHhUgU52Uft6qJbMH+Fqq8Pho+J1TJC/ANEp73KdqEFfeWa7yl7FeWGzAy0C3speaZc9usnb 18RRpWLBYJpGhyXFmi8ZoWhiSy3SNjbnT+RAgLyDhvB3pG3EbO6Z/xZXeD9lZDmTeHtGdhnNIoZ6E eKJujnD9A5KD0PFNgU/GoPzH/VxdMbwuSwZ3CGPaA9eouu6HWLLqseh5bMoBbGt4CzPYQq9s46Uzm +/GRguPQ==;
Received: from [2a02:8109:9296:1600:fcef:b714:fb1c:b7a1] by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97) (envelope-from <peter@desec.io>) id 1uU0ta-00000006AaW-0WWX; Tue, 24 Jun 2025 12:28:55 +0200
Message-ID: <cd7a5589-b966-42ea-a9c5-05bfedaa14fa@desec.io>
Date: Tue, 24 Jun 2025 12:28:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Andrew McConachie <andrew@depht.com>, Joe Abley <jabley=40strandkip.nl@dmarc.ietf.org>
References: <33857674-E1AC-48E7-A4E5-B6953535A86F@depht.com> <D60A06A4-DC62-49A6-9351-BB7EE6323D05@strandkip.nl> <35BF9B4D-175B-4442-B379-3B4D9D6FDA2F@depht.com>
Content-Language: en-US, de-DE
From: Peter Thomassen <peter@desec.io>
Autocrypt: addr=peter@desec.io; keydata= xsFNBFRjVn0BEADXqtra70yxQrT4MQ9DEhN0mxG6XRAOHE6nP18mqxwSlcET7D6w+z3h4ole v0tyvUU02c2wg04X8WVfjoHnAvIa1dfUcNpB1+QmfFsw0xIJlbT1ogHkMiPQqR4ChDvE3ND/ 6YCS5+HT6hY+tfU+hpLsKw4l+u1Pg2NPVLYosET1jU84b7xhFnoicnCV3kUNltLtxLKSBAfk AXtp1AWWKJbfCr3y0qKElMriicoe5DUZfLrZK2iPcWBxh+n7KMO2g7aqx3aQqwW1+S7Sq7Is l6iSurYfIcHb4AfUy4o5nPB8kKACR6BuJmkEQ5WLuTGruWA2fcxaNpICmolMinTzW1CrIjgN PoskMYCNIZ2uWxS6LN8hBiGCRL4h9aL4wuT09SvR13oAPI1HD5ph+mH6wD37/ONBXrdjcFNb 1l/uVkHU/SwwcKDJOsX18T60Ao00fciTbFHgmKtFube0xGK/vjh461TyU+xKD8Orvyeovvxy MzCwM3UVq/dkdG2Ys/7Qy/4bUC1nJEwKlLv7ZTdtSckdoU2M6JpPX6i4KDB2YCMbwtqJ842z 8A/UuE2bL9aDimh/sF8WgPIhlxqF1STNqW1JTIbDPv8HeZnM4nyJOUWStj4uRiETQhBClPLz YWtnR+EUsfbSLy81vfupbMqRasDlt6aASobgn+K7Rb1Xs/mDnwARAQABzSBQZXRlciBUaG9t YXNzZW4gPHBldGVyQGRlc2VjLmlvPsLBeAQTAQIAIgUCVGNWfQIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQ79YUOj7yLS88Dg//SbHnFGrtaImEiM69wyj4GzWnuGk9/upCym/R RzdBALCYHU9FUFFHwusiO9A0pnO8qv/GEtqqTHrcL205a6FTivkdZmOsWuN4oo7r4HBc/taI FLLUDg2wd8q4m4387sYEqrc3olGfyRB6hrMtEWVJLXHJmpcrxAaI1F2QO4Bu7kcdTnyGFz/p ZD8XAof2TWHqJb2ux69DFhiAJeAZlV+h9QrxTedL84l4hq3x1VWsnOEFaCJiThDX920kTnhJ ijrDocgAbmQBCniPACpPHYhBhmCJxfVqgfMuLMNsukOmKxsGcGV6rO1zB5ZUhm3O/Ixk6ow3 6FDKALWihg6Z4P/cJYySMn0iqvHkO8ryT9oJKX//mKaYoF6henXDRLCcRjKwGxFQTEgX+6yc pjgvX3rlypjkPT5ho4yEc5ePkQ2gIIHhvZburm1Zr4nDPx6v8+3XUjpXBRTWQ8/0/h0rtLJe yOPwGJxcfKf/GutTCqiio0mS01mIY9c2i7JWcljlIuSEUit6CHotc5lBOm2GJwguRJG6cXPY SQecwBdcjH3RTzBOv/DN6xWAIV7BmbX/e7DSGAc60mBO1/M0ut+a6CkxRQK8TaE3B3zh1/QO nG0XvtZfIY8ZYdTrdEDSV1Pj5pof/fqhhegHRxN2qi4qIuVcrW0jsUsx10IgAynHR7qQKsvO wU0EVGNWfQEQAPBA8iPCS4ZRX8stW0WuW7579axSq/Luyik4MWDFalt68lzvUbV0f6faN15+ aV7VwMTw3rSa2tP0U8crYAAAZ5NrRHXlYms5BK9vsi1322dAvhyNRawdprP627SO+Ez/84tY xz1X3M9esbN7gpJtHP6mHW76zYpT447v6c2qlbldjobZTDb6kKSGFCIrPJz9M4jVfya+ovxe 2Ab7hn2R0CcyMHATV5g1Ry0XXaj5y3bWypActbG9nflRn3NjhHZynu+WEPDUJCO8kNVNYKOw HObNTeaLvgvU0ONB8pYJv35kDXMhZLwo5MJuJd5i54CXwpo9mECwLJT1RpJi7u98nBrWyyaH s2brG9LPCRKBKOhiHFu57H+cElh+kOvehuS7DFTzjqDwJlkQzP5Hq0G++hZxfdYocKdcdFoh RP3dtDAe+Lfiy9qzJicZ6ACbzoQIN58xj0VWAn1W7SuMErOjv84D/FiXHD2Kxtx09wQl8vH0 Nbh9UgyDBNupToM0ixT+8Ko8eBuYHR53RPxshQhFw4EMIhXiOaxNe1W2Z95QPnYhUGOMoy3I v4fxMQUHa4kZSF2qxsFB1Cxol/aBPGwkwoqUvzp23pLQtJ6youYXtLgvx3pR4L52Q5CUzHMa HvM67XWgW1KqtnvNBXN9PwtDz/a9fQX1YO4CegrXv8C9Ro+LABEBAAHCwV8EGAECAAkFAlRj Vn0CGwwACgkQ79YUOj7yLS8rXA/9EGX2QRfJS94JTdtseu7saTK9a3IKwk6E33GpfXyUVpMt sOqV756XQwULZSWoxInRQtWojA8pQxDUYrbA4MpX0Efr2Dx1xIsJ5F3JajOqViB1SbOD2m0f bxXbcoWKitsKoag2SlvNOd8rD9FcgDvrkacnaQZcZE8DyyGx0JU451tfoD/igu85NZpTDaWG 6fth7QRlxmdGWrGXRdXAP29jq1n0I1wIyF/bXlZ7MXjOSsfyPddzsnHFTvNMZKps0QXNF+hi ESg9chIeo/IFDDVu6pCtm6mftojx84rczTZiNk8r2T3TU4N8uwWtXn/nj9xd61pnxD0xkTPH zxJrCs59WSfYqj3aFNkWO3Lg0/HGnO9wHQKMXcGPsnKITHVzxCNBQtVHomNA7ds6Kt3/WJgS pU2ciICvrpvKgPNWQ0d/SeY3vYIRvDLZ12Svx6M3eXDrsgZOT5be7kGVr3t7dBOYKcRHkZUq kU1kCcgp0vetISVDOc5fkpdUkAtd5/13pIpz4ikVR3OM4Br4XMVShm6RvoP4pyA+ftCi1+bw 0UbRCrnHgnG+wtCf5nMDGVLc04vITnII+ESZqlF02a1IFj0Z2MuQK2Oszl2Nsx/LG60G1e/R pzKEXIIJgHfbwUCWtV1zQu6v9Ng5H8EqVeWcdaPUwSQMGcDg/sPa4s/OxhgrYBg=
In-Reply-To: <35BF9B4D-175B-4442-B379-3B4D9D6FDA2F@depht.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: Q4HR7JNJIOCNVAVSTLYJKKFDZMTIYEHT
X-Message-ID-Hash: Q4HR7JNJIOCNVAVSTLYJKKFDZMTIYEHT
X-MailFrom: peter@desec.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: on the more general problem of delegating to other namespaces in the DNS
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nGUFMrdV4vWu4GERBnJNJLrplS4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
Hi Andrew, On 6/24/25 12:20, Andrew McConachie wrote: > Regarding the DNSSEC trust chain, it’s broken with both a zone cut to nowhere and a non-existent name. I guess the point this draft makes is that a signed lame delegation is better than a signed proof of non-existence. Either way the private resolver or private authoritative will have to ‘fake’ some DNSSEC data, because there can never be a ‘real’ signed DS RR in the parent zone. Only when the child is supposed to be secure. When it's insecure, the parent claiming that its own DNSKEYs are applicable is just wrong. The delegation to nowhere provides a semantically more correct carve-out. Coincidentally, a secure delegation to nowhere allows provisioning a trust anchor for a private zone, which may be desirable in certain organizational settings. I'm not saying this is a reason to have this spec; I'm just listing actual (above) and potential (this) benefits. > I’m still left with the question of: Why is a (signed/unsigned) lame-delegation better than (signed/unsigned) non-existence? I've tried to answer it above. Cheers, Peter
- [DNSOP] on the more general problem of delegating… Joe Abley
- [DNSOP] Re: on the more general problem of delega… Ted Lemon
- [DNSOP] Re: on the more general problem of delega… Joe Abley
- [DNSOP] Re: on the more general problem of delega… Ted Lemon
- [DNSOP] Re: [Ext] on the more general problem of … Paul Hoffman
- [DNSOP] Re: [Ext] on the more general problem of … John Levine
- [DNSOP] Re: [Ext] on the more general problem of … Joe Abley
- [DNSOP] Re: [Ext] on the more general problem of … Paul Hoffman
- [DNSOP] Re: [Ext] on the more general problem of … Joe Abley
- [DNSOP] Re: [Ext] on the more general problem of … Libor Peltan
- [DNSOP] Re: DNSOP[Ext] on the more general proble… Wes Hardaker
- [DNSOP] Re: on the more general problem of delega… Andrew McConachie
- [DNSOP] Re: on the more general problem of delega… Joe Abley
- [DNSOP] Re: on the more general problem of delega… Andrew McConachie
- [DNSOP] Re: on the more general problem of delega… Peter Thomassen
- [DNSOP] Re: on the more general problem of delega… Joe Abley
- [DNSOP] Re: on the more general problem of delega… Petr Špaček
- [DNSOP] Re: on the more general problem of delega… Ted Lemon
- [DNSOP] Re: on the more general problem of delega… Joe Abley
- [DNSOP] Re: on the more general problem of delega… Peter van Dijk
- [DNSOP] Re: on the more general problem of delega… Peter van Dijk