EDE length=2 with INFO-CODE=0 works nicely. Also because non-EDE-aware DNS responders can be vulnerable to attacks described in Security Considerations, the Security Considerations section currently suggests clients use draft-ietf-add-resolver-info to check if server supports EDE. This needs better clarification in the document that client has to check draft-ietf-add-resolver-info before including EDE OPT in its DNS query. This check will further help interop by only sending EDE in requests to servers that indicated support via draft-ietf-add-resolver-info. However, it creates draft-ietf-add-resolver-info as another hurdle to deployment of Structured DNS error. Thoughts?
(I also put the above text into our github issues; I don't know which folks prefer. https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/issues/26) -d > On May 22, 2023, at 7:44 PM, Tommy Pauly <[email protected]> > 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 > > 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 <[email protected]> wrote: >> >> >> >>> On 23 May 2023, at 02:20, Tommy Pauly <[email protected]> >>> 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 >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: [email protected] >> <mailto:[email protected]> >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
