Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-03.txt

[Joe Abley <[e-mail]>]

On Sat, May 27, 2023 at 04:50, <[[e-mail]](mailto:On Sat, May 27, 2023 at 04:50,  <<a href=)> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Domain Name System
> Operations (DNSOP) WG of the IETF.
>
> Title : Structured Error Data for Filtered DNS
> Authors : Dan Wing
> Tirumaleswar Reddy
> Neil Cook
> Mohamed Boucadair
> Filename : draft-ietf-dnsop-structured-dns-error-03.txt
> Pages : 21
> Date : 2023-05-26

I see this version still has the text citing resinfo in the security considerations section.

As I said earlier (below, but with a subject that perhaps wasn't very helpful) I think this needs some more thought.

Joe

---------- Forwarded message ----------
From: Joe Abley <[e-mail]>
Date: On Fri, May 26, 2023 at 11:34
Subject: Fw: Re: [ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error] Client requests including empty EDE isn't currently interoperable (Issue #26)
To: <[e-mail]>
Cc:

[This arrived the other day from github, and I don't know what kind of mess I will make if I just group-reply to it, so I'm following up on the list. List seems better for general discussion anyway.]

On Tue, May 23, 2023 at 23:25, Dan Wing <[[e-mail]](mailto:On Tue, May 23, 2023 at 23:25, Dan Wing <<a href=)> wrote:

> The justification for signaling draft-ietf-add-resolver-info is in Security Considerations where it currently says:
>
> An attacker might inject (or modify) the EDE EXTRA-TEXT field with an DNS proxy or DNS forwarder that is unaware of EDE. Such a DNS proxy or DNS forwarder will forward that attacker-controlled EDE option. To prevent such an attack, clients supporting this document MUST discard the EDE option if their DNS server does not signal EDE support via RESINFO [I-D.ietf-add-resolver-info]. As recommended in [I-D.ietf-add-resolver-info], RESINFO should be retrieved over an encrypted DNS channel or integrity protected with DNSSEC.
>
> should we soften that? The authors have argued back and forth on the risk of this attack versus deployment, code, and operational complexity of draft-ietf-add-resolver-info signaling.

RESINFO provides a statement of intent about what you can expect from a particular resolver service. I am not convinced it is an adequate substitute for a negotiation of capabilities between the endpoints of a DNS transaction.

For many significant DNS servers that we arguably care most about troubleshooting problems with (and hence where extended error codes might provide the most benefit) the particular server (host, process, implementation) that handles a query sent to address A is usually not the same server that handles the next query sent to the same address.

The root servers are an example of a set of servers that use anycast with intentionally-different DNS implementations deployed in different places. Most resolver clusters relied upon by any significant population of clients are not single instances of software bound to an address on just one host interface.

Software and metadata (in general) is routinely released incrementally, meaning that the software running on one particular origin server in an anycast deployment is not in general the same as that on other servers, and cannot always be expected to behave the same (otherwise you would never be able to roll out or roll back new features).

EDNS options are attached to a particular response and refer to that self-same transaction, which is why they are a good choice for things like EDE, NSID, buffer negotiation, etc.

(NSID is an improvement over CH/TXT/HOSTNAME.BIND or CH/TXT/ID.SERVER for the same kind of reasons that I'm waving my hands about here.)

Information published by RESINFO (or by other means disconnected from the transaction about which information is required, on a web page maybe, on a mailing list!) seems like good input to a human troubleshooting expedition but a poor choice for a client that is trying to make real-time, automated decisions about how to handle a request for name resolution.

I think perhaps this risk and its suggested mitigation need some more thought.

(I'm not actually sure I agree this is a risk that needs a mitigation.)

Joe

>