[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

Ted Lemon <mellon@fugue.com> Thu, 01 May 2025 01:38 UTC

Return-Path: <mellon@fugue.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 6796A2370E85 for <dnsop@mail2.ietf.org>; Wed, 30 Apr 2025 18:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=fugue.com header.b="nBq/+/hv"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="oiq/cpgi"
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 UGAmGlF3ZVVS for <dnsop@mail2.ietf.org>; Wed, 30 Apr 2025 18:38:49 -0700 (PDT)
Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) (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 BCEFA2370E7E for <dnsop@ietf.org>; Wed, 30 Apr 2025 18:38:49 -0700 (PDT)
Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailflow.stl.internal (Postfix) with ESMTP id 5F5201D4259F; Wed, 30 Apr 2025 21:38:49 -0400 (EDT)
Received: from phl-imap-10 ([10.202.2.85]) by phl-compute-12.internal (MEProxy); Wed, 30 Apr 2025 21:38:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue.com; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1746063529; x=1746070729; bh=wTxYUg14s7 OMAWoC4h9dRn+c/n99jGDWXzIZWndrf/4=; b=nBq/+/hv72OlatmSYwhDbWs5sk 9UM3SBd7WGA1w0wJXKjf2PRR5GAWX2UPBH8cgw2GGipuCfngkNriCRMIntKMb0t9 dIhMvCRgaczGD2BBQH8vSL5jiCpJjZWng7ixP85/5yiFXOnvIOHLYl2DjEIGDqiT Hg7Ll+9q0KUlTrrBDa5hITtiabQ575Kr3n3wOZs8rAyeijVQvvFvG43mSxCjdpNO ubdQfF8CIvFIEQW+iykRpFCRoYgbRHDOgCi7sPoyszL0qbbDKFv1EfzhzOS7ULjI p5FjvohtT+2Nd0tRu9kiAv5PgvdyyeKizzR03iQyQWbipu+qNwGy2+MDVfcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1746063529; x=1746070729; bh=wTxYUg14s7OMAWoC4h9dRn+c/n99jGDWXzI ZWndrf/4=; b=oiq/cpgiAsL6zUls3icsWm7bKT3HHCczPMZp+SsThYdlapnZZgA 7bmJNrmJ/lGJw2JlUljeCalq8SfHYlwvu6q3biW8bfL7tbqe3b8Rp9R48HmzMWVB ORy14y1kEbk+hN72OwB+4oftL3GadZBo0pmf+ug6H95Pgifl/l8cCs/RmBjXaaCG gEh52/vVNag7zyOaaZF8ZJgl8eFYblSmfiPuqjw9agZPc49PNnSxSZxE/zbroaH8 jbj9RPs0P+zV+dqm9R1oUAPnZGz3ZhzSr285CP+oQ7DXW19lxGi/hIPmzFNRYjAb y/OiVIOoefEE6r67D96Yu7amRRc32/t1dlQ==
X-ME-Sender: <xms:qdASaPLlBLMAQZUH_W9Gn4KJ0eqjY6N4dC4pvBCt3CeM6rt-i3Zgxg> <xme:qdASaDJwu761IRSqH2UlMC_4m_AUrbJb-FrmQr6nI_UKXC0t-1iUYR3KW4OUjO5-Z Kae77EKe8JSWhjeY1A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvieekvdekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgesrgdtreerredt jeenucfhrhhomhepfdfvvgguucfnvghmohhnfdcuoehmvghllhhonhesfhhughhuvgdrtg homheqnecuggftrfgrthhtvghrnhepfeeugfdttdffkeefieejueduieevuefgvddvleel jedvjeejhedvtdfgleevudetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhgvlhhlohhnsehfuhhguhgvrdgtohhmpdhnsggprhgtphhtthho pedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehprghulhdrhhhofhhfmhgrnh esihgtrghnnhdrohhrghdprhgtphhtthhopegunhhsohhpsehivghtfhdrohhrgh
X-ME-Proxy: <xmx:qdASaHsJFF45f1pPnAhKa7bkql7xotm2HoQa-XqqtfzLwG3EKiClxw> <xmx:qdASaIb3U7vtGe8wWxPi2ue93Xmon5ekufqE0A6-xYPW9F1Zu2YVOA> <xmx:qdASaGaM7tKfO_1tiiFYZd-OWpFhturkxn9eAXDTKNAh6P-RTG1PRw> <xmx:qdASaMAHpIS9DFdoPvSD5SRmKcLyKeRrXnFWuQhwEZJc5SvOLTJ0_Q> <xmx:qdASaHFiU6nPNl0ffr0-3GGZph6QeeARemjq_p00iglP5l-TOwVqhfqO>
Feedback-ID: i1136489e:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id EBD5D3C0068; Wed, 30 Apr 2025 21:38:48 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: Teb8ce65f3fed0dd8
Date: Wed, 30 Apr 2025 21:38:28 -0400
From: Ted Lemon <mellon@fugue.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Message-Id: <6ad73a8b-aab7-4765-9f85-49d7483ca917@app.fastmail.com>
In-Reply-To: <b5e95596-ffa7-491f-86c5-27a9c98b4336@app.fastmail.com>
References: <m1u5h1G-0000LcC@stereo.hq.phicoh.net> <83666fd3-a51f-46e1-a5ac-0b9a46361480@desec.io> <49E3B1B6-E960-4A46-9C5D-2721FD57132D@depht.com> <3b5fb9e7-8a2b-420f-a2fb-dd6f6a0b88ae@isc.org> <89047B78-A2B1-43F2-A996-94DF1E90538A@depht.com> <cc84f69c-c349-4d91-b942-80221b564a9b@isc.org> <ac48e27d-479f-42f3-b87f-891220ef2fe8@app.fastmail.com> <BE721880-6254-48F4-9F91-567A99E0511B@icann.org> <m1u7asT-0000MtC@stereo.hq.phicoh.net> <01E23110-9A50-4187-8A54-34D514504F9B@strandkip.nl> <3A48CBC3-B55B-4FCF-B713-A7CA4C7BB7CC@strandkip.nl> <8E36C1B8-C67B-4704-9E3B-7143863E2262@icann.org> <87f219df-34f0-48fa-89cf-8cb8300c86c2@app.fastmail.com> <1359A8E4-E436-4EC5-B5C7-E0713A3E8182@icann.org> <b5e95596-ffa7-491f-86c5-27a9c98b4336@app.fastmail.com>
Content-Type: multipart/alternative; boundary="58bbba58a24a47d983ec971981557d3c"
Message-ID-Hash: N7IONTLV35M36YBTMCXNSZPZQ6BAKSQ5
X-Message-ID-Hash: N7IONTLV35M36YBTMCXNSZPZQ6BAKSQ5
X-MailFrom: mellon@fugue.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: "dnsop@ietf.org WG" <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Phwt81HtT7t5OMsqUEl3R0l4dyw>
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>

Er, I should add that since using DoH is pretty common, if .internal isn’t listed in the locally-served domains registry its subdomains probably will indeed show up as nxdomain. 

On Wed, Apr 30, 2025, at 9:25 PM, Ted Lemon wrote:
> The local resolver can safely lie about the delegation, so unless the stub resolver queries the root directly this isn’t an issue. Even if it does, unless it uses DoH, the edge router can intercept the query. But this isn’t generally necessary. If you’re doing DNSSEC the only reason not to trust the local resolver is if it doesn’t give enough answers to construct the proofs. 
> 
> On Wed, Apr 30, 2025, at 1:34 PM, Paul Hoffman wrote:
>> On Apr 30, 2025, at 10:21, Ted Lemon <mellon@fugue.com> wrote:
>> > 
>> > The reason to do an insecure delegation is so that the public dns doesn’t securely deny the existence of the zone. If there is a secure denial of existence, a validating stub resolver will not use responses from the local resolver because they will be bogus. 
>> 
>> This seems to be talking about a validating stub resolver that is configured to also get answers from a particular recursive resolver, yes?
>> 
>> 1) Wouldn't the stub get two conflicting NS records for .internal, one from the root itself and the other from the recursive? All attempts for lookups would have a 50% chance of going to the blackhole nameserver.
>> 
>> 2) Wouldn't having an insecure delegation in the root prevent the recursive from signing .internal itself because the root responds with an NSEC proving there cannot be a DS? 
>> 
>> Again, I could be missing something, but it seems that both of those would hurt the validating stub resolver. A validating stub resolver could instead easily be configured with the trust anchor for the recursive resolver it is configured for.
>> 
>> --Paul Hoffman
>> 
>> 
> 
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org
>