Re: [Add] draft-ietf-add-resolver-info-09
Steffen Nurpmeso <steffen@sdaoden.eu> Tue, 20 February 2024 19:30 UTC
Return-Path: <steffen@sdaoden.eu>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4740C180B43 for <add@ietfa.amsl.com>; Tue, 20 Feb 2024 11:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIOOQ6gmB01l for <add@ietfa.amsl.com>; Tue, 20 Feb 2024 11:30:28 -0800 (PST)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8BCC151078 for <add@ietf.org>; Tue, 20 Feb 2024 11:30:26 -0800 (PST)
Date: Tue, 20 Feb 2024 20:30:23 +0100
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: tirumal reddy <kondtir@gmail.com>
Cc: Mark Andrews <marka@isc.org>, add@ietf.org
Message-ID: <20240220193023.t8iYjP8Z@steffen%sdaoden.eu>
In-Reply-To: <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-y1VxxbTmfooC4AWo5Mw@mail.gmail.com>
References: <7F756639-9CB4-4F1A-9F77-C47101CE292A@isc.org> <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-y1VxxbTmfooC4AWo5Mw@mail.gmail.com>
Mail-Followup-To: tirumal reddy <kondtir@gmail.com>, Mark Andrews <marka@isc.org>, add@ietf.org
User-Agent: s-nail v14.9.24-598-g53c2ea4337
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/jNHJiK52HkaaOJvmdbZCtE76c-I>
Subject: Re: [Add] draft-ietf-add-resolver-info-09
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Tue, 20 Feb 2024 19:30:29 -0000
tirumal reddy wrote in <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-y1VxxbTmfooC4AWo5Mw@mail.gmail.com>: |On Thu, 15 Feb 2024 at 06:02, Mark Andrews <marka@isc.org> wrote: |> Why is it necessary to change the standard processing of queries for |> RESINFO when we already have a signal (AA=1) about whether the answer |> is coming from elsewhere or not ? | |It is introduced to handle a scenario where SUDN is used to discover the |encrypted resolver, and if the discovered resolver does not support |RESINFO, it will forward the query upstream. An attacker might provide a |RESINFO response with AA=1. The proposed mechanism aims to help the client |identify whether the response is coming from the discovered encrypted |resolver. By the way i am really not worth being noted for anything acknowledgeable regarding the work of this WG. At all. If you have another iteration of the document, i would prefer if you would simply scratch my name from your work. It is solely your work, for sure. And the above is possibly very smart: my DNS work was two decades ago, and i could not even tell whether i have ever seen authority section entries being passed through or not. My main topics are simplicity so small teams can still exist competetively as was true over two decades ago (ie, with knowing the entire picture, not by delegating to "trusted" external modules in uncounted numbers), when there were <3000 RFCs. As such i very much appreciated RFC 8499, but i alone from my superficial out-of-interest reading have 17 DNS-related RFCs added locally since then, plus the draft of yours and whatever else from this WG. And a different way to get the TLS trust (or, rather, use existing ways of various kind eg rpki, ikev2, or simply public keys as is done by DKIM (certificates are a bit larger, but with the TCP that is more and more needed per se, or QUIC; or even the permanent HTTP proxying of everything, that is "no problem")) away from CA pools, to DNS/TLS + DNSSEC zone records. Thank you for that, too! Ciao, and greetings from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
- [Add] draft-ietf-add-resolver-info-09 Mark Andrews
- Re: [Add] draft-ietf-add-resolver-info-09 tirumal reddy
- Re: [Add] draft-ietf-add-resolver-info-09 Steffen Nurpmeso
- Re: [Add] draft-ietf-add-resolver-info-09 Mark Andrews
- Re: [Add] draft-ietf-add-resolver-info-09 mohamed.boucadair
- Re: [Add] draft-ietf-add-resolver-info-09 mohamed.boucadair
- Re: [Add] draft-ietf-add-resolver-info-09 Steffen Nurpmeso
- Re: [Add] draft-ietf-add-resolver-info-09 Ben Schwartz
- Re: [Add] draft-ietf-add-resolver-info-09 Ben Schwartz
- Re: [Add] draft-ietf-add-resolver-info-09 Mark Andrews
- Re: [Add] draft-ietf-add-resolver-info-09 Mark Andrews
- Re: [Add] draft-ietf-add-resolver-info-09 mohamed.boucadair
- Re: [Add] draft-ietf-add-resolver-info-09 Ben Schwartz
- Re: [Add] draft-ietf-add-resolver-info-09 Mark Andrews