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

Joe Abley <jabley@strandkip.nl> Thu, 01 May 2025 17:15 UTC

Return-Path: <jabley@strandkip.nl>
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 958CC23B1C2B for <dnsop@mail2.ietf.org>; Thu, 1 May 2025 10:15:03 -0700 (PDT)
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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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=strandkip.nl
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 pHnMKqYNOhnC for <dnsop@mail2.ietf.org>; Thu, 1 May 2025 10:15:02 -0700 (PDT)
Received: from outbound.st.icloud.com (npq-east2-cluster1-host3-snip6-4.eps.apple.com [IPv6:2a01:b747:3001:204::31]) (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 2FED123B1C26 for <dnsop@ietf.org>; Thu, 1 May 2025 10:15:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; bh=kUAQT+IjuPjEBIzcGIb/Miw3jl28HqxkoeqWLKHdNwg=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme; b=bcXlm8m4oIAPS75ppU+WWUg67sxIUfYv6QRegIwq/3sxD7KGIFesReurXapkUXSEj 4e4bGHR6G6dJgRQsIufQfGG1LSrENXnmrSV2dKjVmhFR+4Eo5BQQvZjf3fulKVfm9E HEs5RfDpUs5R5V1bOYBAJRUQCUHJE+SjI56D9NfWs+WeckewR0ZucFoGTJjM+Zr4a9 mCDfKVKdb3Y5YVPXhgLk1XzjcnL7j7SBUgQXYmh3XpkvBfqWkatyZjuz/lGUP9OZOt 9F8E7EA5Jsb8D8AohstfgAInyjkFkDgJOhHnrTDrou6Zzr5sq/29GEX3K1ayaNFGxZ K+6SUMnIzMKNg==
Received: from smtpclient.apple (unknown [17.42.251.67]) by outbound.st.icloud.com (Postfix) with ESMTPSA id 6D80618001CD; Thu, 1 May 2025 17:14:59 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <m1uAXQQ-0000LmC@stereo.hq.phicoh.net>
Date: Thu, 01 May 2025 19:14:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BF63680-46C9-452B-9DFB-E5666D6EB6BD@strandkip.nl>
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> <B080C29F-9086-4E08-A277-37835AAB8A2D@isc.org> <4E28195C-BFF2-470D-BA89-23F6F5B6255C@icann.org> <m1uAXQQ-0000LmC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-dnsop-6@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3826.500.181.1.5)
X-Proofpoint-GUID: bEdzQhXED6FEFW1mo0eitbWd8AHqw9t2
X-Proofpoint-ORIG-GUID: bEdzQhXED6FEFW1mo0eitbWd8AHqw9t2
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
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 adultscore=0 mlxscore=0 clxscore=1030 mlxlogscore=999 bulkscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2505010131
Message-ID-Hash: CZC2LFQND2O3RVQRZHVCHV7CI6IGKXPV
X-Message-ID-Hash: CZC2LFQND2O3RVQRZHVCHV7CI6IGKXPV
X-MailFrom: jabley@strandkip.nl
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, Paul Hoffman <paul.hoffman@icann.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/59ROFENVCj_Rye7BsgcGx9B4ZVQ>
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>

Hi Philip,

On 1 May 2025, at 19:10, Philip Homburg <pch-dnsop-6@u-1.phicoh.com> wrote:

>> The latter is true, but that doesn't explain the "No". If a stub
>> resolver gets an NS record from an authoritative source (in this
>> case, the root zone), and it gets a second NS record from a trusted
>> source (in this case, its configured resolver), why wouldn't it
>> use both of those records? I see nothing in any of the DNS standards
>> that says it should not, but I might be missing something.
> 
> I don't understand your model of a stub resolver.
> 
> My model of a stub result is that the stub resolver formulates a DNS
> query packet and sends it to a (recursive) resolver. The stub resolver
> doesn't care about NS records and does not try to combine information
> from multiple sources.

I think a stub resolver that cares about validation does care about those things. It sends queries to its chosen resolver with CD=1 and DO=1 and gathers enough information to be able to validate the response its application is looking for from whatever trust anchors it has at its disposal.

I also think that validating stub resolvers in the real world are borderline fictional, however, so it's possible that my mental model doesn't match other people's mental models and all of us are right since there's no real-world data to disagree with.


Joe