IETF Logo Mail Archive

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

Wes Hardaker <wjhns1@hardakers.net> Sat, 24 January 2026 04:09 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 9845FAC520A2 for <dnsop@mail2.ietf.org>; Fri, 23 Jan 2026 20:09:32 -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_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=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 gc_xkL2ro2Rf for <dnsop@mail2.ietf.org>; Fri, 23 Jan 2026 20:09:32 -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 F0D37AC5209C for <dnsop@ietf.org>; Fri, 23 Jan 2026 20:09:31 -0800 (PST)
Received: from localhost (unknown [203.117.154.201]) by mail.hardakers.net (Postfix) with ESMTPA id A645220D22; Fri, 23 Jan 2026 20:09:28 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net A645220D22
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1769227771; bh=c388Kn4sXhm/z5LbWDXxInU2bY4Rl5mPhyUdXJVls5g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ELXXtn2jx2TLsuGHRiUSoz2q2uPILVigqMbWFMV82cDXKZkqKGu/VAMD1N6cFAeon bJw2uMkDPkjxyW5hDxR5YGoTLIdzFwhIQwOUP1yyyomu5NQgrzoDJzJOC17FKD2bhZ 8msq8zHg2YquCuy1vDSEicWN3zC62hJDJvcdqwfM=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <22208.1769187954@obiwan.sandelman.ca> (Michael Richardson's message of "Fri, 23 Jan 2026 12:05:54 -0500")
References: <ybla4y6lwjf.fsf@wx.hardakers.net> <234729DC-6EFD-4D22-B3B4-EA143CDC2430@fl1ger.de> <yblldhohck9.fsf@wx.hardakers.net> <76252438-9F03-4C5E-878A-980006C95380@fl1ger.de> <22208.1769187954@obiwan.sandelman.ca>
Date: Fri, 23 Jan 2026 20:09:26 -0800
Message-ID: <ybltswbejnt.fsf@wx.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Message-ID-Hash: IXEDGMYVWEP3RIVJV55YTAKIGDFECJGY
X-Message-ID-Hash: IXEDGMYVWEP3RIVJV55YTAKIGDFECJGY
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: Ralf Weber <dns@fl1ger.de>, 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/qwGEzZC8_nTGX3R4Wcca6aSnMSc>
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>

Michael Richardson <mcr+ietf@sandelman.ca> writes:

> It could be equally be XoH, AXFR-over-DoT.

Do note that if you are checking ZONEMD and DNSSEC then HTTP is just
fine without the S.  You most likely don't need the integrity or
privacy.  Some signed firmware for "things" are downloaded over http
because it aleviates the problems related to ensuring the TLS stack
works properly when the protection is provided at the object layer.

-- 
Wes Hardaker
Google

v2.46.0 | Report a Bug | By Email | System Status