> 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 > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
