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

Both of these seem viable, and I’ll let the authors and WG decide which is the 
right way forward.

Best,
Tommy

> On May 22, 2023, at 5:00 PM, Mark Andrews <ma...@isc.org> wrote:
> 
> 
> 
>> On 23 May 2023, at 02:20, Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> 
>> wrote:
>> 
>> Hello DNSOP,
>> 
>> In draft-ietf-dnsop-structured-dns-error, there’s a description of how 
>> clients should indicate that they understand extended DNS errors (EDE) by 
>> sending an empty EDE option. 
>> 
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-02.html#name-client-generating-request
>> 
>> This is something that makes a lot of sense to me, and provides a great way 
>> to indicate that a client would prefer to receive proper blocked/filtered 
>> errors (with possible extra text) as opposed to a forged answer.
>> 
>> However, in testing this out, I’m seeing inconsistent compatibility with 
>> some public resolvers. I was testing enabling this for encrypted resolvers 
>> only, and I see the following behavior for a sampling of resolvers using DoH:
>> 
>> 1.1.1.1 - NOERROR, works fine!
>> 9.9.9.9 - NOERROR, works fine!
>> 8.8.8.8 - FORMERR on all responses
>> dns.adguard-dns.com - SERVFAIL on all responses
>> 
>> Do we think that this should be allowed in queries (and thus this is a bug 
>> in resolvers like 8.8.8.8 or AdGuard)? Or is there a problem with the 
>> approach this document is suggesting?
> 
> RFC 8914 left whether EDE in requests was permitted or not undefined.  I can 
> see an EDE implementation making the option parser return FORMERR if the EDE 
> option length was less than 2 and applying that to both requests and 
> responses.  RFC 8914 really should have said that EDE in requests should be 
> ignored and then there would have been a possibility on extending behaviour 
> based on adding EDE to a request.  We are already 10 years into trying to fix 
> unknown EDNS option behaviour and are still getting FORMERR on unknown EDNS 
> options in requests.  If the working group want to allow extending EDE by 
> adding it to a request is should obsolete RFC 8914 now with RFC8914bis that 
> specifies that EDE in requests are to be ignored.
> 
> At the moment draft-ietf-dnsop-structured-dns-error-02 really should use 
> another EDNS option code point.  It really is not backwards compatible with 
> EDE the way it is currently specified. 
> 
> 
>> Best,
>> Tommy
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: ma...@isc.org 
> <mailto:ma...@isc.org>
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to