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

Paul Hoffman <paul.hoffman@icann.org> Wed, 30 April 2025 17:34 UTC

Return-Path: <paul.hoffman@icann.org>
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 5F9AD233C9F3 for <dnsop@mail2.ietf.org>; Wed, 30 Apr 2025 10:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 U8zxv3nNh2qk for <dnsop@mail2.ietf.org>; Wed, 30 Apr 2025 10:34:37 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) by mail2.ietf.org (Postfix) with ESMTP id DEC16233C9EE for <dnsop@ietf.org>; Wed, 30 Apr 2025 10:34:36 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 53UHYTxg006860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Apr 2025 17:34:33 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 30 Apr 2025 10:34:31 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1544.011; Wed, 30 Apr 2025 10:34:31 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [DNSOP] [Ext] Re: Call for Adoption: draft-davies-internal-tld
Thread-Index: AQHbufYhScHgJzjlpUujLd/0jup3fw==
Date: Wed, 30 Apr 2025 17:34:31 +0000
Message-ID: <1359A8E4-E436-4EC5-B5C7-E0713A3E8182@icann.org>
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>
In-Reply-To: <87f219df-34f0-48fa-89cf-8cb8300c86c2@app.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E655D4A61A576446AA3441DD5A7E395C@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-04-30_05,2025-04-24_02,2025-02-21_01
Message-ID-Hash: CVNFCSWQO45FAQUP27MGSNJWRHCJHJFT
X-Message-ID-Hash: CVNFCSWQO45FAQUP27MGSNJWRHCJHJFT
X-MailFrom: paul.hoffman@icann.org
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/n8ggYbir6HDAn_zv2XdqyVGdO1o>
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 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