On Sat, May 27, 2023 at 04:50, <[internet-dra...@ietf.org](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 <jab...@strandkip.nl>
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: <dnsop@ietf.org>
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 <[notificati...@github.com](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
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
