Why site blocking doesn’t work

April 20, 2017

Recently Village Roadshow commenced proceedings in the Australian Federal Court to block customers of some of Australia’s largest ISPs (including Telstra, Optus, TPG + subsidiaries, and others) from accessing a raft of sites associated with online piracy.

The court ordered the ISPs to block access to these web sites using one or more of the following steps:

DNS blocking by the target domain names.

IP address blocking (or rerouting).

URL blocking of the target domain URLs. ;or

“any alternative technical means” (as agreed between the applicant and the respondent)

Given how transient compute is today, IP address blocking simply isn’t a viable solution. IP addresses can be easily changed (and some of the proposed sites already change their IP regularly) - not to mention that some of the proposed sites use content delivery networks (CDNs) such as CloudFlare where blocking the IP addresses would result in other legitimate sites being blocked also.

It’s not 1995 anymore and ISPs don’t generally run transparent proxy servers, so that removes the option to block based on URLs. Many of the sites are also using HTTPS and while it’s possible to extra the hostname from a request as this is sent in plain text during the certificate negotiation, the investment required to inspect every HTTPS request across a customer base would be substantial.

Ignoring “any alternative technical means” this leaves us with the path of least resistance - DNS blocking. ISPs run their own DNS resolvers that clients would typically be configured to use by default and it’s trivial to configure these resolvers to return arbitrary responses for a given query.

Customers on Internode for example would see the following page when accessing a blocked site:

If we look at the DNS request that’s being returned, Internode’s resolvers return 202.136.99.185 in response to any DNS lookup for a blocked domain:

I would suggest that someone who is capable of setting up a torrent client along with the usually requisite port forwarding rules in that user’s router is certainly more than capable of getting around the site blocking in a manner of minutes by changing their DNS resolvers.

If a user is already using DNS resolvers outside their ISP’s network, then they probably didn’t even notice that the “block” was in place — which really means that this whole exercise was simply a waste of everyone’s time and money.