[Add] Paul Wouters' Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS)
Paul Wouters via Datatracker <noreply@ietf.org> Sun, 31 March 2024 01:51 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: add@ietf.org
Delivered-To: add@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F01BC14F603; Sat, 30 Mar 2024 18:51:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-add-resolver-info@ietf.org, add-chairs@ietf.org, add@ietf.org, tojens@microsoft.com, tojens@microsoft.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Message-ID: <171184989711.29383.9811877433419506782@ietfa.amsl.com>
Date: Sat, 30 Mar 2024 18:51:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/40yhdwGSBL_VHMtRVeHW1c43mcA>
Subject: [Add] Paul Wouters' Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS)
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2024 01:51:37 -0000
Paul Wouters has entered the following ballot position for draft-ietf-add-resolver-info-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In general, I am not sure what this document wants to achieve. It states: DNS clients can use the resolver information to identify the capabilities of DNS resolvers. It then defines qnamein, exterr and infourl. The latter should not be used by the DNS client. So what should a DNS client do with the information that QNAME Minimalization is used, or that the DNS resolver code base supports EDE (but EDE might not be in use anyway). What behavioral change is expected from "DNS Clients" that are targeted by this document? If no change in behavior is expected, why should a DNS client support and perform this query? Furthermore, none of the answers can be trusted without some form of enterprise provisioning. Why inform the resolver is using qname minimalization? What makes this optional special, compared to other things like 0x20 support, the infra-rr hardering support, DNSSEC support? Why is it not providing keywords for DoH or DoT or DoQ support? Why not show what normally would be in the CHAOS version.bind data like dns implementation name and version? If the DNS client would behave differently based on the setting of qnamein, what would it be and how would it determine the security of the returned value (eg why wouldn't the target DNS resolver just lie to cause the DNS Client to do whatever behavior it does differently when it sees qnamein?). If this is meant only for administrators doing DNS diagnostics, why not ONLY return an infourl and have qnamein and exterr contained in infourl, or even more keywords based on a DNS yang model list of keywords? What is the DNS Client expected to do with the exterr values returned? What does "supported" mean, eg versus "configured". What different DNS Client behavior is expected based on this value? The "infourl" seems a bit risky. While the documents tries to limit the impact, I don't understand its approach. Why insist on "https" ? It's a public API that anyone that can query the nameserver can presumably retrieve anyway? That is, I assume such a infourl would not require HTTP level authentication. I don't see why it should be forced over https. Why is the information presented a text/html and not plaintext ? Or json? Or yang? This would avoid various risks of exposure to the enduser which are not meant to consume this anyway according to the document. The URL SHOULD be treated only as diagnostic Why is that not the case for qnamein and exterr? Why is that not a MUST? A DNS client MAY choose to display the URL to the end user Why is this not a MUST NOT ? if and only if the encrypted resolver has sufficient reputation This is not something an implementer can write code for reading the RFC. It further more pushes centralization towards "reputable DNS resolvers". How does the DNS client get updates about the reputable status of a DNS resolver? I feel just like "captive portals", that this can/will be misused and be used for advertisement or other non-DNS purposes. Forcing this to be text/plain or json/yang would make this "less consumable" to endusers and thus make them more safe against abuse. In Section 7 it states: 1. Establish an authenticated secure connection to the DNS resolver. [...] It is important to note that, of these two measures, only the first one can apply to queries for 'resolver.arpa' How can anyone establish a secure authenticated connection to "resolver.arpa"? If they do, either the client has to authenticate it is the real "resolver.arpa" but then its contents cannot apply (it's something on the internet, not local) or it authenticates to "something else", in which case how can that be secure, or if it is secure but populated with information that validates "starbucks", how meaningful is "authentication" in this context? The section contains another set of "weasel wording" on determining reputation of the resolver that is not really implementable in code.
- [Add] Paul Wouters' Discuss on draft-ietf-add-res… Paul Wouters via Datatracker
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… tirumal reddy
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… mohamed.boucadair
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Paul Wouters
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… tirumal reddy