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

Wes Hardaker <wjhns1@hardakers.net> Thu, 26 February 2026 15:43 UTC

Return-Path: <wjhns1@hardakers.net>
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 D15F0BECDE94 for <dnsop@mail2.ietf.org>; Thu, 26 Feb 2026 07:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_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 (1024-bit key) header.d=hardakers.net
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 ftazpI2I5dkz for <dnsop@mail2.ietf.org>; Thu, 26 Feb 2026 07:43:26 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (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 3D2EABECDE8D for <dnsop@ietf.org>; Thu, 26 Feb 2026 07:43:26 -0800 (PST)
Received: from localhost (wsip-70-168-62-114.sd.sd.cox.net [70.168.62.114]) by mail.hardakers.net (Postfix) with ESMTPA id 2D3A023083; Thu, 26 Feb 2026 07:43:24 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 2D3A023083
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1772120605; bh=IEMPrnLyTtNnRDjX8XgzmagWeqOiGWUya4GPAa4lcdo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Dd/Iu54Cx/rB/SPck5rvv7Izlo4pBMugmjqjEcveZVC0NdOmBpoVfFT1HzBAry0JI k3mYQ/Cvu7W//YkhqFX0y825oBI6rrRAsatM+L2DnL7Kh3ii/m7nMzVfdxCbSavTaU BYCxVKAheKcWSn1OXNGN/7QoeqUsN2ScOidtalkw=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Florian Obser <florian+ietf@narrans.de>
In-Reply-To: <m1jyvza6b9.fsf@narrans.de> (Florian Obser's message of "Thu, 26 Feb 2026 16:11:06 +0100")
References: <ybla4y6lwjf.fsf@wx.hardakers.net> <m17bsdf74s.fsf@narrans.de> <yblfr6ol783.fsf@wx.hardakers.net> <m1jyvza6b9.fsf@narrans.de>
Date: Thu, 26 Feb 2026 07:43:24 -0800
Message-ID: <yblbjhbh5nn.fsf@wx.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Message-ID-Hash: JR5I2FZHNGDEF2HWSDVOQUVAHJP2EVVT
X-Message-ID-Hash: JR5I2FZHNGDEF2HWSDVOQUVAHJP2EVVT
X-MailFrom: wjhns1@hardakers.net
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: Wes Hardaker <wjhns1@hardakers.net>, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: 4 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/u53JwQFE5ovv5f38BCGC1xTahI4>
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>

Florian Obser <florian+ietf@narrans.de> writes:

> How can the LocalRoot server figure out what the real expire time is
> when using http? At what time should it stop using the zone file and
> switch to querying the root name servers?

Ah, thanks for the clarification.

There are a few options.  One thing people have suggested to me
elsewhere that would be helpful in general is to add a timestamp to the
zone presentation format file.  That'd help consumers of that (but not
AXFRs).

> The zone file might have sat on the CDN for 10 days already. If the
> LocalRoot server starts the expire timer from when it fetched the zone
> it will treat it as not-expired for an additional 7 days, at that point
> the zone will be 17 days old and signatures will have expired.

And looking at the signature times is definitely one of the
possibilities, but I'm not sure that's the perfect solution either.
Certainly if the signatures are expired then the zonemd record won't
validate and the LocalRoot implementation will need to switch to regular
DNS.

At a minimum, it might be good to state signatures must be valid for at
least X hours or something.

Suggestions welcome!

-- 
Wes Hardaker
Google