[DNSOP] Re: sign the whole zone, was optimisng root zone signing for iXFR

John Levine <johnl@taugh.com> Mon, 16 March 2026 16:34 UTC

Return-Path: <johnl@iecc.com>
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 6D58ECB6C3A1 for <dnsop@mail2.ietf.org>; Mon, 16 Mar 2026 09:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b="mmCkJn1R"; dkim=pass (2048-bit key) header.d=taugh.com header.b="g/5Py9uK"
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 7oTuCdN7c_MA for <dnsop@mail2.ietf.org>; Mon, 16 Mar 2026 09:34:35 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 EA4ABCB6C39C for <dnsop@ietf.org>; Mon, 16 Mar 2026 09:34:34 -0700 (PDT)
Received: (qmail 57078 invoked from network); 16 Mar 2026 16:34:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=deec69b83114.k2603; t=1773678858; x=1774024458; bh=fyJA3+r6JvvM2evvIl4YfsXbnZCGu69Z/z10Cg/4e6Y=; b=mmCkJn1RmWQWdbbEfinyiJACGgCbWaK9t7+dOD1yXxZIKGNYsLZRRklMrrCQOLIXVeTjqeLZgzQvfzlnWwQXP0Z9UomiCXW/v3L1E5J9Q8rmfEDMmQ1t5HMbKYP/cVv+/XjWgKDRXAozVwrAILfAby51Nr6lYEK9UUBr5Vnz8nAbesZuvZaATWNPXbTVxKG0uYV4ykozYMsZCV0Iur80HAA9yyUMtExM/HyGx1IHQwwaRS8Du23rSteo90ojUJkzg724YDf2YMuNR+4n7fni9HslpmKkhilD5AhJJ7dxXEWifl6gFlReW4o3HI3UYp5poNvltRWY9Yt+hyzepidCKA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-transfer-encoding:cleverness; s=deec69b83114.k2603; bh=fyJA3+r6JvvM2evvIl4YfsXbnZCGu69Z/z10Cg/4e6Y=; b=g/5Py9uK6se20OYpSpZWueSuaUeyFvvo/6yTUzoKUevFeMtz7UFcYgVyQS+4524GcYQeK/KCtKL6ycBt4mgkHImMymZ/2TP+pG6fQNh6kIaal9zSnSVDWKd+58LXoEQpbHC77B9CZO2Yx3XUi6grVKhuOxzWSXWmWEaaxlcP67o7f+rbLlEhqWK7kev00htR//TiyVrdW/eWIKAOyBxD4CRlHs3EcYwv2uU+scVbyV29DLN2AdXVvTXTepYhj1v2OgH48TsYQyDdy1oHMKwjsXoA862vsgewHNxeKWj5Uba/7I96B20wUKfHJaf9f3qaQaZPi8LUGeWXFrEZcCOXyg==
Received: from ary.qy ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126:0:78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA CHACHA20-POLY1305 AEAD) via TCP6; 16 Mar 2026 16:34:27 -0000
Received: by ary.qy (Postfix, from userid 501) id 5F8CEFC99343; Mon, 16 Mar 2026 12:34:27 -0400 (EDT)
Date: Mon, 16 Mar 2026 12:34:27 -0400
Message-Id: <20260316163427.5F8CEFC99343@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
In-Reply-To: <a736f6ad-653a-4afd-85c9-78b9434ed026@nlnetlabs.nl>
Organization: Taughannock Networks
References: <ybla4y6lwjf.fsf@wx.hardakers.net> <ybla4y6ia6t.fsf@wx.hardakers.net> <CAKr6gn1L=hHOj2he0Rs_38B5n3pnNZw3xFMx36QLcjthJfUosQ@mail.gmail.com> <yblwm1agppa.fsf@wx.hardakers.net> <25556.1769124242@obiwan.sandelman.ca> <DS0PR15MB567499ECC061876A8A244F35B394A@DS0PR15MB5674.namprd15.prod.outlook.com> <ybl8qdng7r4.fsf@wx.hardakers.net> <20260124030638.D7CFBF2E6F2E@ary.qy> <ybly0lneka7.fsf@wx.hardakers.net> <CAKr6gn2nV+B0mjdCixKG+2UpdmtHFxp_1ZqzK5WFuK4Hxd9GGg@mail.gmail.com> <DS0PR15MB5674E9944F3090E1D48F62CFB393A@DS0PR15MB5674.namprd15.prod.outlook.com> <ybl1pjc8324.fsf@wx.hardakers.net> <DS0PR15MB5674B258DE6F9A2AC9EEF9D2B393A@DS0PR15MB5674.namprd15.prod.outlook.com> <yblfr7p7n5t.fsf@wx.hardakers.net> <m1vlp0d-0000NnC@stereo.hq.phicoh.net> <yblwm0z3sbi.fsf@wx.hardakers.net> <DS0PR15MB5674FC8D569A11B35878298DB39FA@DS0PR15MB5674.namprd15.prod.outlook.com> <014EE668-54E1-408D-A67C-AE4A5DCE75F9@RFC1035.com> <a736f6ad-653a-4afd-85c9-78b9434ed026@nlnetlabs.nl>
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Message-ID-Hash: WN6F3LX6KKLV6BYTAVANVFHQCLYY5HWA
X-Message-ID-Hash: WN6F3LX6KKLV6BYTAVANVFHQCLYY5HWA
X-MailFrom: johnl@iecc.com
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: willem@nlnetlabs.nl
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: sign the whole zone, was optimisng root zone signing for iXFR
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/X5_W0QQ1lpAs3PNre-rT5Qyamws>
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>

It appears that Willem Toorop  <willem@nlnetlabs.nl> said:
>So in theory, the resolver could do with a transfer of the zone without 
>the RRSIGs for the DSes, provided (for example) that there is also a 
>ZONEMD + RRSIG for the unsigned data ...

>Only for validating clients (still rare?) that will query for the DS of 
>the delegations explicitly, an exception needs to be made and a query 
>needs to go to the root server to get the DS with RRSIG then anyway.

This is starting to bleed into DELEG. The main point here is that if
you are sure you can trust whatever is giving you your DNS answers,
you can skip the validation. (We'll skip over the detail that there
are basically no validating clients, so in practice we do so now even
without a trusted channel.)

That's clearly the direction we're going so we might give some thouught
about how to get there without reinventing the wheel more times than
we have to.

R's,
John