Re: [Pearg] Responding to "Concerns over DNS Blocking" technical error(s)

[Marwan Fayed <[e-mail]>]

Mirja,

Fantastic, and agreed on all points. This is a great outcome, and very much
the one I'd hoped for. I am happy to help advance the conversation with
Vint, or otherwise, as appropriate.

I'll only add or reiterate the following (for list readership as much as
anything else):

On pt 1: The very nature of IP's design means that it is *always*
inappropriate to use IP addresses for content filtering. It is non-trivial
to know what lies behind an IP address (content, machines, other networks),
and so content-blocking via IP should be disqualified from the conversation
--- including in IPv6 that, just like IPv4, is about addressing and routing
to interfaces, that themselves may or may not be associated with (still
many) server or content names.

On pt 2: To clarify, the DNS is the only 'network layer' control that
provides any transparency to the user. Indeed, yes, there are
"higher-layer" alternatives that come with their own challenges, e.g.,
whether they are implemented, inter-op, etc. However, at network layers,
there is only DNS, SNI, and (shouldn't be, as above) IP. Since DNS is
_really_ an application, it is the only one of the three that can give
_meaningful_ feedback to the user --- i.e. some transparency (via return
codes).

Also a general note for the wider readership that is known to many but
worth restating: With respect to 'regional' qualities, not all recursive
resolvers can be treated as equal. Specifically, private in-network
resolvers have finely granular knowledge about their stubs' locations and
operating environments. In contrast, open public resolvers have no such
knowledge and are routed to via public BGP routing outside of the public
resolver's control. Any attempt to geo-gate service is subject to open
routing behaviour and/or the inaccuracy of IP geo-localization (that we
know is highly problematic) --- even ignoring performance penalties and
engineering challenges.

I claim that this distinction is a feature of the Internet's reliable and
resilient design --- an amazing engineering and interoperability feat that,
40+ years on, is worth celebrating.

Thanks all, for the feedback; also Mirja again for the positive and
constructive engagement.

--marwan

On Thu, 3 Aug 2023 at 15:12, Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> Hi Marwan,
>
>
>
> thanks for your feedback. This is really good input for me. Please see my
> replies.
>
>
>
> On your point 1: The sentence about content filtering and IP blocking has
> to be seen in context. The context of this whole letter is that the
> proposed regulation would impact DNS providers globally (not only regional
> ISPs). I believe the regulators see a need for this as more user have
> switched to open DNS providers and therefore ISP-level filter isn’t seen as
> sufficient. The letter argues against measure that have such global impact
> and in this context points out that other regional, ISP-level measures
> exists. I never read it, when I was co-signing, as endorsing these
> techniques. However, you are right that it can be interpreted that way, and
> I will relay this to Vint and the other co-signers.
>
>
>
> On your point 2: I agree that DNS filtering or other blocking and
> filtering techniques are generally problematic. I’m not sure about your
> point about transparency; you can also design mechanisms to provide
> feedback about the blocking on other layers; however, if these things get
> implement is a different question. Still, for this letter it wasn’t the
> intention discuss blocking and filtering generally but point of the global
> implication of this proposed regulation. I find that even more problematic
> because there is always the option for a global/non-regional to not comply
> with a regulation (and depending on the market condition) not serve a
> certain service in a certain region anymore, which finally can really
> “break” the Internet. We don’t see this for DNS (yet) but we already see it
> e.g. in the regulatory “fights” about news content.
>
>
>
> Mirja
>
>
>
>
>
>
>
> *From: *Pearg <[e-mail]> on behalf of Marwan Fayed <marwan=
> [e-mail]>
> *Date: *Monday, 31. July 2023 at 13:37
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[Pearg] Responding to "Concerns over DNS Blocking" technical
> error(s)
>
>
>
> Dear wg, and more--
>
>
>
> There is a just-published open letter [1], also summarized at 117's pearg
> [2] in response to a proposed initiative that (as is summarized) can
> require ISPs to block domains via DNS without a court order.
>
>
>
> This is no doubt a concern for all, but the open letter has two
> significant problems, one of which is a factual and technical error that
> would be great to correct, and another that merits wider conversation:
>
>
>
> 1. [Technical Error] The open letter suggests that IP blocking is a viable
> and less harmful alternative to blocking content via DNS. This is patently
> false because the consequence of blocking via DNS is all content at a
> domain name; an IP address block, by the very design of the Internet
> Protocol itself, could affect (and has affected) many more domains than
> intended [3]. For example, a block of 11 addresses in Austria last year
> affected thousands of domains and websites [4]. (As an aside, the lack of
> transparency about the practice is a particular concern, at least as much
> as the practice itself.)
>
>
>
> How best to address the error in the open letter? Ideally we can find a
> fix as a community, and one that involves the signatories (and their
> organizations, despite having signed in a personal capacity).
>
>
>
> The text of concern that needs redress reads, "Several alternatives exist
> which would avoid the concerning implications mentioned above. Domestic
> Internet Service Providers (ISPs) have a number of tools at their disposal
> to block infrastructure deemed malicious by French authorities. This
> includes blocking HTTP/HTTPS connections to the offending site, and
> blocking the IP addresses." [1]
>
>
>
> 2. [Wider conversation] The idea that the use of the DNS deserves more
> attention than simply being "blanket bad." There are no doubt challenges,
> not least that the DNS is composed of many role-types, namely recursive
> resolvers and authoritative servers, also local-network private resolvers
> and open-public resolvers. Each of these entities in the DNS are different
> and warrant separate consideration.
>
> However, when thinking about 'in-network' controls, the DNS has one very
> large and important advantage that is unavailable when blocking by name or
> address: The DNS offers **transparency**, which is not available when
> blocking via name or address. From RFC 8914 [5], recently introduced codes
> in sections 4.16 to 4.19 are useful, to start. At a minimum, support from
> resolvers and clients means that users could get insight into service
> interruptions, and the reasons for them.
>
>
>
> If blocking in the network has to happen, the transparency offered by DNS
> in RFC 8914 should be considered when engaging in the wider discussions.
>
>
>
> Hopefully these comments help contribute to a positive and productive
> discussion.
>
>
>
> Many thanks,
>
> --marwan
>
>
>
> [1] https://medium.com/@vgcerf/concerns-over-dns-blocking-988ef546a100
>
>
>
> [2]
> https://datatracker.ietf.org/meeting/117/materials/slides-117-pearg-proposed-laws-on-dns-blocking-00
>
>
>
> [3] https://blog.cloudflare.com/consequences-of-ip-blocking/
>
>
>
> [4]
> https://www.derstandard.de/story/2000138619757/ueberzogene-netzsperre-sorgt-fuer-probleme-im-oesterreichischen-internet
>
>
>
> [5] https://www.rfc-editor.org/rfc/rfc8914.html
>
>
>