> On May 24, 2023, at 12:00 AM, tirumal reddy <kond...@gmail.com> wrote: > > On Wed, 24 May 2023 at 01:48, Tommy Pauly <tpauly=40apple....@dmarc.ietf.org > <mailto:40apple....@dmarc.ietf.org>> wrote: >> 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. > > Dependency on draft-ietf-add-resolver-info was added to address the threat > where an attacker might inject (or modify) the EDE EXTRA-TEXT field with an > DNS proxy or DNS forwarder that is unaware of EDE.More details are discussed > in Section 10 of the draft.
Using encrypted DNS to a known/trusted resolver can achieve this as well, so I think it is better as a recommendation of one way, but not a required way. Tommy > > Cheers, > -Tiru > >> >> Tommy >> >>> On May 23, 2023, at 9:52 AM, Dan Wing <danw...@gmail.com >>> <mailto: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 <mailto: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 >>>>> <mailto:ma...@isc.org>> wrote: >>>>> >>>>> >>>>> >>>>>> On 23 May 2023, at 02:20, Tommy Pauly <tpauly=40apple....@dmarc.ietf.org >>>>>> <mailto: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 <http://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 <mailto:DNSOP@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org <mailto:DNSOP@ietf.org> >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> _______________________________________________ >> 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
