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

[Petr Špaček <[e-mail]>]

On 23. 05. 23 7:03, Ralf Weber wrote:
> 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.

I agree. Sending empty EDE in requests seems superfluous to me.

-- 
Petr Špaček
Internet Systems Consortium