[DNSOP] Re: DNSOP4 documents for consideration about the future of LocalRoot behavior.

Joe Abley <jabley@strandkip.nl> Thu, 05 March 2026 11:22 UTC

Return-Path: <jabley@strandkip.nl>
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 D5CE1C4D8425 for <dnsop@mail2.ietf.org>; Thu, 5 Mar 2026 03:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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=strandkip.nl
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 N_AamTbvvTRw for <dnsop@mail2.ietf.org>; Thu, 5 Mar 2026 03:22:37 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [185.233.34.146]) (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 5F91BC4D8419 for <dnsop@ietf.org>; Thu, 5 Mar 2026 03:22:37 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.4.100]) (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) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4fRRw62hvrz88; Thu, 5 Mar 2026 11:22:30 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4fRRw60QsTzKP; Thu, 5 Mar 2026 11:22:30 +0000 (UTC)
Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=strandkip.nl header.i=@strandkip.nl header.a=rsa-sha256 header.s=soverin1 header.b=UNrc2Q7Q; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=soverin1; t=1772709750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fLQgreOkOLxuJ88QiK7OVEwfWRUKOobVD9pKbNGuVAU=; b=UNrc2Q7Qeb4LaKiu92KjHESF7E2y1W7dphjRawlrjeFyhn25ZW5WIRvXFZ6khMwCyMdAFl iXlcpZ64yyKrRfg33t3AG8Vh2iqNdi+wTX4vP7kBWnM0iRI7o4QcLws9QHvsj03qXP827A RHFYgbCvU4Dt9qj281dlOp4orRmRsT+vBFHLwkIGXiEZNinSqAYhs8J65ofl1uheV0/ezt 494cs8507ftfBsk1UVLhHDffHHGVOv0nOzVgPjhFuPYMg3ckeFv6jY/spuN9NCgjEZILkX MO/7xJdHH4k667GejKSNaKISe/rafTBGB0yvUnJ5vSTYzr2C0FZmIH+w612iFg==
X-CM-Envelope: MS4xfLlCjFYOc9444d2cgT1HLUcx4ay/IUwZVRlSju1f6+Z/egSuHEtJPOVo8TC8X5Mj3OQhOsvLtecjh2napG8lSHndRqOpyTTeLovrp+pSP+BD1Q2EVrgm /s1NBHGwxQ3n5ZnTAV93O1/pxeccWzj807XlGmM1xu6pNZ04unAE2gnY3cyc7pE9Sm/OOv/+rI65zC8z+3QOlG2HRHHlRdPWaBNjyTT+IBwe4Qhwu2lx8sJj DyOzR5pdne/uZJJf0YzUYmlJhv0yc9ffF9JD4Dh+iAsEmLQZFBEQGD6vlajxNSTcZJgdGdj1mElLeXqOvafZQQ==
X-Soverin-Id: 019cbdbc-24f0-7326-baa9-1511926de822
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@strandkip.nl>
Mime-Version: 1.0 (1.0)
Date: Thu, 05 Mar 2026 11:22:19 +0000
Message-Id: <84F4C1C1-5EA4-460F-868B-2AAA07A97F3F@strandkip.nl>
References: <CAKr6gn3bWq_0ZeysVkA1tLAdR-0h+642d8OcNSW=E7MN=jWODQ@mail.gmail.com>
In-Reply-To: <CAKr6gn3bWq_0ZeysVkA1tLAdR-0h+642d8OcNSW=E7MN=jWODQ@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
X-Spampanel-Class: ham
Message-ID-Hash: DJ5MNWCWLL6GK35RISZYQUXOHMAWVTR2
X-Message-ID-Hash: DJ5MNWCWLL6GK35RISZYQUXOHMAWVTR2
X-MailFrom: jabley@strandkip.nl
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: Paul Vixie <paul@redbarn.org>, Geoff Huston <gih902@gmail.com>, dnsop@ietf.org, Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: DNSOP4 documents for consideration about the future of LocalRoot behavior.
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RDSzoGX-7sgwsIBMtfHUulST6xI>
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>

On 5 Mar 2026, at 00:24, George Michaelson <ggm@algebras.org> wrote:

> I have run local root. I don't see any problems with my service, running local root.

I am not doubting your operational diligence George, but for many people I can imagine persistent and enduring failures that will go unnoticed and the result will be new TLDs that are not universal or retired TLDs that persist. If you don't use something and you don't measure it, how would you expect to see failures?

I appreciate that DNSSEC is there to save us from such problems, but software has bugs and humans make mistakes and our goal ought to be to protect the namespace expecting that those things are true, not trying to legislate that they must be false. We have certainly seen fixes to DNSSEC validation failures of the form "turn off validation". Hope is not a strategy. 

> I don't see the relevance of fetch mechanisms to success or failure here, or the rate of churn in the root as a significant issue for a local root copy mechanism.

Me neither. The data transfers are minuscule with or without incremental transfers and I do not understand some of the strong opinions about data distribution mechanisms unless they are anchored in not-invented-here.

However, to avoid the risk of sounding too much like I am in favour of all of this, let us continue...

> I do accept that there are a cohort of people who have downside consequences of reduced traffic to the roots.

We have a root server system that is already quite hard to measure, an easy example of which was the extensive fear and loathing around the first KSK rollover, but we manage to come up with plausible numbers for availability and system health that are sufficient to convince us that the system is stable and secure. 

I don't know how we convince ourselves of such things if local-root becomes prevalent. Some are saying that this is a rare and niche local optimisation and prevalence is not expected, but I also hear that this is all fine because we can trust the major implementations to do this safely and well. But if all the major implementations are doing this then it no longer seems rare and niche; it seems like one default setting away from mainstream. 

This all sounds like a solution looking for a problem to me. Unless the problem is actually "let's make the root server system unnecessary" I don't really know what this is all for; I don't see arguments for increased security, observability or stability. 

I am not arguing against this work. I have concerns but I don't think it's actively harmful. Just because I think it smells funny doesn't mean others shouldn't enjoy its delicious and heady flavours.


Joe