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.
-Tiru
On Mon, 28 Apr 2025 at 04:40, Asbjørn Sloth Tønnesen <ast@xxxxxxxxxxx> 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
