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
