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

Paul Hoffman <paul.hoffman@icann.org> Thu, 01 May 2025 17:55 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 B9F7423B5E58 for <dnsop@mail2.ietf.org>; Thu, 1 May 2025 10:55:46 -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 XKR-uslEtklz for <dnsop@mail2.ietf.org>; Thu, 1 May 2025 10:55:46 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) by mail2.ietf.org (Postfix) with ESMTP id 5D44723B5E53 for <dnsop@ietf.org>; Thu, 1 May 2025 10:55:46 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa4.dc.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 541HtZ6o005685 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 May 2025 10:55:36 -0700
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; Thu, 1 May 2025 10:55:43 -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; Thu, 1 May 2025 10:55:43 -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: AQHbufYhzE3K79eEgkiG45Kk3DqAzbO9cUKAgAD2iQCAABe1gIAABm8A
Date: Thu, 01 May 2025 17:55:42 +0000
Message-ID: <70480CD5-1299-480B-98F9-5C418940A80C@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> <1359A8E4-E436-4EC5-B5C7-E0713A3E8182@icann.org> <b5e95596-ffa7-491f-86c5-27a9c98b4336@app.fastmail.com> <31972B9D-D604-43BF-9638-5DC7F36C0FCE@icann.org> <4642026e-81d6-4620-b4c5-6af67d59e6d5@app.fastmail.com>
In-Reply-To: <4642026e-81d6-4620-b4c5-6af67d59e6d5@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: <EBAF03B25133974681026298C9E3F40C@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-05-01_06,2025-04-24_02,2025-02-21_01
Message-ID-Hash: WFGJWFHMNP2UUMA72Y2ZVLPIHCXODBWU
X-Message-ID-Hash: WFGJWFHMNP2UUMA72Y2ZVLPIHCXODBWU
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/sktlmaA8IMrc1b4J52K2yaBPSzk>
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 May 1, 2025, at 10:32, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Thu, May 1, 2025, at 12:07 PM, Paul Hoffman wrote:
>> 
>> 
>> On Apr 30, 2025, at 18:25, Ted Lemon <mellon@fugue.com> wrote:
>> > 
>> > The local resolver can safely lie about the delegation, so unless the stub resolver queries the root directly this isn’t an issue.
>> 
>> A validating stub resolver would indeed query the root to create the chain of trust. That's the whole point of *validating* stub resolvers.
> 
> 
> The stub resolver queries the chain of trust, but why would it send a packet to a root server?

It could ask the configured recursive for the chain-building data, but it is more reliable to ask the source zone.

> Is that what we want it to do?

Unless we have specified otherwise (and I don't think we have for validating stub resolvers), what we want is irrelevant.

> Normally I would expect it to query the local network resolver and then validate. I think that’s what our implementation does unless DoH is configured. Is yours different?

In the cases discussed here (the recursive has a record at foo.internal, and either .internal is missing from the root zone or has an insecure delegation in the root zone), how does your implementation help the validating stub resolver build the chain of trust? And what happens if "DoH is configured"?

> I’m under the impression that no delegation at the root means the delegation can be proven not to exist. Am I mistaken?

You are not mistaken: there is no NSEC record for .internal (but there is for .int and .international).

>> > 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. 
>> 
>> You may feel that way, but that's not the model adopted by the DNSSEC standards.
> 
> 
> Again not my understanding of how existing validating stub resolvers work, but I’m curious to know what your experience with this is. My sample is one at the moment—the one in Apple’s operating systems. 
> 

See my question above. The IETF has given no guidance for how a validating stub resolver should be configured, and yet that is quite important for this discussion.

--Paul Hoffman