IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Thu, 01 May 2025 16:07 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 8935223AA808 for <dnsop@mail2.ietf.org>; Thu, 1 May 2025 09:07:55 -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 PENK0pr2c_OI for <dnsop@mail2.ietf.org>; Thu, 1 May 2025 09:07:55 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) by mail2.ietf.org (Postfix) with ESMTP id 2675223AA803 for <dnsop@ietf.org>; Thu, 1 May 2025 09:07:55 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa4.dc.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 541G7icd015016 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 May 2025 09:07:44 -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 09:07:51 -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 09:07:51 -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: AQHbufYhzE3K79eEgkiG45Kk3DqAzbO9cUKAgAD2iQA=
Date: Thu, 01 May 2025 16:07:51 +0000
Message-ID: <31972B9D-D604-43BF-9638-5DC7F36C0FCE@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>
In-Reply-To: <b5e95596-ffa7-491f-86c5-27a9c98b4336@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: <839E835E03DE8A4E8AFD1515BFAA2A58@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: VZUPZ5UPSDLJDVGQOLDUOEHCVH7CHZBA
X-Message-ID-Hash: VZUPZ5UPSDLJDVGQOLDUOEHCVH7CHZBA
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/3Nc9tOVi9nGLYS6VsWHG7KlZS3s>
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 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.

> Even if it does, unless it uses DoH, the edge router can intercept the query.

The IETF does not promote "edge router can intercept the query". :-) Further, even in that scenario, then there is no reason for an insecure delegation: no delegation works fine.

> 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.

--Paul Hoffman

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