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
