Using length=2 and INFO-CODE=0 sounds fine to me. For the dependency on draft-ietf-add-resolver-info, I don't think we need to impose that dependency. I'd much prefer to allow clients to look at that optionally, but still be able to include the hint and use the extra text if it parses correctly.
Tommy > On May 23, 2023, at 9:52 AM, Dan Wing <danw...@gmail.com> wrote: > > 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 <tpauly=40apple....@dmarc.ietf.org> >> 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 <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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
