Thank you very much for your detailed and thoughtful review of the draft, and for sharing valuable insights from the ISP deployment perspective. We would like to clarify that the scope of this draft is not limited to enterprise networks. It is designed to support structured error response signaling across a wide range of deployment scenarios, including home networks, BYOD use in enterprise networks, and mobile networks. The examples provided in the draft are intended to be illustrative.
We have already received similar feedback and are working to update the document to explicitly include EDE Code 16 (Censored) alongside Blocked, Filtered, and Forged Answer. Fields such as j, c, o, and l can be conveyed along with EDE 16. We are being careful not to expand sub-error codes beyond this scope at this time, as there is currently no WG consensus on doing so, and the IETF does not endorse censorship policies. The purpose of this mechanism is to enable transparency and interoperability, not to promote any censorship behavior. That said, the draft does include a provision via registration procedure for adding new sub-error codes through IETF review, should future consensus support their inclusion. Regarding localization: the "j" field is intended solely for IT diagnostic purposes and is not meant for end-user display. Based on WG discussion, we avoided introducing URLs or arbitrary free-form fields to reduce the risk of misuse by resolvers. The rationale behind introducing the new "Blocked by Upstream DNS Server" EDE is to distinguish filtering performed by local routers (e.g., home or enterprise gateways) from filtering by upstream recursive resolvers. This distinction is important in deployments where DNS filtering may occur at multiple layers. It is worth noting that home routers are increasingly capable of supporting DoT/DoH, as demonstrated in deployments such as dnsdist in router environments <https://blog.open-xchange.com/dnsdist-as-a-router-ready-solution>. -Tiru On Mon, 28 Apr 2025 at 04:40, Asbjørn Sloth Tønnesen <a...@fiberby.net> wrote: > Hi, > > Sorry that I haven't commented earlier, I wasn't aware of this draft until > recently. > This review is based on draft-ietf-dnsop-structured-dns-error-14.txt > > I work for an ISP in Denmark, and I have previously worked on an EDE > propagation > testbed at some of the RIPE/DNS-OARC DNS hackathons: https://ede.dn5.dk/ > (I am happy to add some I-JSON based endpoints as well) > > I am currently conducting a survey of how sanctioned domains are blocked > across > the EU, and will present my findings in a session at the DNS WG at RIPE90 > in a few weeks, incl. EDE propagation tests and RFC 7725 adoption. > > In general the enterprise use-case seams to take up most of this I-D, > where as > the ISP use-cases doesn't seams to have studies as closely, and therefore > seams > less coherent when read from an ISP's point of view. > > In the introduction, in the first paragraph "filtering required by law > enforcement" > and "requirement imposed by an external entity" is hinting towards that > this I-D > should also be usable with the "EDE code 16 - Censored". > > https://datatracker.ietf.org/doc/html/rfc8914#name-extended-dns-error-code-16- > > In section 1: "can return extended error codes Blocked, Filtered, or > Forged Answer" > and in other places: Why is "Censored" not included? The censored error > code is > highly relevant for adoption of this I-D for ISPs. > > In controlled enterprise deployments, I assume that Blocked, Filtered and > Forged is relevant. > For residential ISP's Blocked, Filtered, Censored and Forged can be > relevant. > Blocked if the provider has a mandatory malware/phishing filter. > Filtered if the provider has a voluntary malware/phishing filter. > Censored for governmental mandates. > Forged forged for any of the above, when accompanied by a HTTP-only block > page. > > In Denmark, block pages are expected, and design/content is often a part > of the blocking order. The governmental agencies like to promote their > logo's. > (served with 451 Unavailable For Legal Reasons - RFC 7725). > > List of affected domains in Denmark: > https://www.teleindu.dk/brancheholdninger/blokeringer-pa-nettet/ > > We would rather send a "Censored" EDE, than "Forged Answer", but > politically > it is not so easy to get rid of the HTTP block pages. > > There should also be some sub-error codes related to the "Censored" EDE. > In Denmark, we have the following kinds of censored sites: > sanctions (rt.com, etc.), copyright, unlicensed gambling, > product safety, security and CP. > > Given the use-cases listed in the introduction I think that these > sub-errors should be included in this I-D, rather than a follow-up. > > In section 3, I agree that HTTP block pages are not a good fit in the > modern > HTTPS-by-default world, but "certificate validation error" is not > commonplace. > But "Connection refused" is since block pages are hosted on a dedicated IP > where TCP/443 (HTTPS) is greated with an ICMP rejection message. > > Section 6 seams thin, considering all the obstacles to deployment. > It might be easy in a controlled enterprise setup, but for it to work in > a FTTB ISP setup, with BYOD / regular of-the-shelf home routers, then it > will require propagation to work. Currently EDE propagation is only > described > as a MAY in RFC8914 and I believe that this should be changed to a SHOULD. > In practice EDE propagation is currently very limited. > > I like Mark's proposal to move localization data over to HTTP, as the > alternative for us would be to try and cram both Danish and English in > there. > > I don't get the need for the new EDE "Blocked by Upstream DNS Server". > If we have a field with a operator ident, as Mark suggests. Then when a > request is received over an unencrypted channel, e.g MITM'ed by a dumb home > router, can be authenticated by the application, by re-attempt the request > with DoT directly towards the resolver. Requiring the whole chain to be > encrypted, is not realistic in to be deployed in residential ISP networks > in > the near future. I think it would be better to add a field indicating that > it > was received over an unencrypted channel, rather than discarding the > EXTRA-TEXT data. > > Lastly, thank you for trying to fix this technological gap, I hope that you > find some of these ISP / deploy-ability notes useful. > > -- > Best regards > Asbjørn Sloth Tønnesen > Network Engineer > Fiberby - AS42541 >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
