Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

[Ralf Weber <[e-mail]>]

Moin!

On 23 May 2023, at 4:44, Tommy Pauly wrote:

> Thanks, Mark.
>
> For what it's worth, I just ran two other tests, and for both of these cases, all of the resolvers I tried did accept the request:
> - Choose a new EDNS option code point (I just tested 50, randomly)
> - Use EDE but set the length to 2 and the error to 0 (other error), rather than a length of 0

I don’t think we need a new code point. Just having a valid opt record without a further option will work as RFC8914 states:

The Extended DNS Error (EDE) option can be included in any response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes an OPT pseudo-RR [RFC6891]. This document includes a set of initial codepoints but is extensible via the IANA registry defined and created in Section 5.2.

and as the mechanism in draft-ietf-dnsop-structured-dns-error just defines a special format for the EDE EXTRA-TEXT field the most backward compatible solution IMHO is just to rely on the mechanism defined in RFC8914, and not to define any special handling.

So I would propose 5.1 to be:

When generating a DNS query, the client includes the OPT pseudo-RR [RFC6891] to elicit the Extended DNS Error option in the DNS response.


So long
-Ralf
——-
Ralf Weber