On Wed, 24 May 2023 at 01:48, Tommy Pauly <tpauly=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. Cheers, -Tiru > > 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 > 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 > > > _______________________________________________ > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
