To clarify, the point of the signal in the request is to indicate that the client knows how to handle EDE responses of filtered/blocked/etc.
When a resolver is filtering, it has to deal with both legacy clients and EDE-aware clients: - For legacy clients, it will send a forged answer that sends a browser, etc, to a page that explains that they’re blocked. This technique is very problematic (breaks TLS cert trust, etc), but is very common, and unfortunately many resolvers won’t be willing to stop doing this for legacy clients. - For clients that understand EDE for filtered/blocked etc, particularly if extra-text can be used, the resolver would instead prefer to use that mechanism. However, these EDE codes can’t be used with a forged answer, so the resolver needs to know the client understands how to deal with the errors in a sensible way. Just using the OPT pseudo-RR isn’t enough — clients will include padding for DoH, etc, but still not know how to deal with EDE. So an explicit signal is preferable here. Tommy > On May 23, 2023, at 12:45 AM, Mark Andrews <ma...@isc.org> wrote: > > > >> On 23 May 2023, at 17:11, Petr Špaček <pspa...@isc.org> wrote: >> >> On 23. 05. 23 7:03, Ralf Weber wrote: >>> Moin! >>> On 23 May 2023, at 4:44, Tommy Pauly 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 >>> I don’t think we need a new code point. Just having a valid opt record >>> without a further option will work as RFC8914 states: >>> The Extended DNS Error (EDE) option can be included in any response >>> (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes >>> an OPT pseudo-RR [RFC6891]. This document includes a set of initial >>> codepoints but is extensible via the IANA registry defined and created in >>> Section 5.2. >>> and as the mechanism in draft-ietf-dnsop-structured-dns-error just defines >>> a special format for the EDE EXTRA-TEXT field the most backward compatible >>> solution IMHO is just to rely on the mechanism defined in RFC8914, and not >>> to define any special handling. >>> So I would propose 5.1 to be: >>> When generating a DNS query, the client includes the OPT pseudo-RR >>> [RFC6891] to elicit the Extended DNS Error option in the DNS response. >> >> I agree. Sending empty EDE in requests seems superfluous to me. > > The point of adding it to the request is to signal that that client will do > the filtering. > > Even if signalling is removed the current text is incompatible with EDE. > Read it in “perverse” mode (client will be stupid). > >> -- >> Petr Špaček >> Internet Systems Consortium >> >> _______________________________________________ >> 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
