Why site blocking doesn’t work

By · · 4 mins read · Tech

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:

$ dig thepiratebay.se

; <<>> DiG 9.8.3-P1 <<>> thepiratebay.se
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58446
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;thepiratebay.se.		IN	A

;; ANSWER SECTION:
thepiratebay.se.	14376	IN	A	202.136.99.185

;; Query time: 4 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Thu Apr 20 17:44:15 2017
;; MSG SIZE  rcvd: 49

The IP address returns the disabled message for any request.

I started digging and it appears that the TPG group of companies are using a common set of infrastructure to simply return a different message based on the IP, for example:

202.136.99.184 - TPG
202.136.99.181 - iiNet
202.136.99.186 - AAPT

So what happens if we change our DNS resolvers to something like Google DNS or OpenDNS?

Simply changing the DNS resolvers on my computer meant that I immediately started seeing the real IP addresses of the site returned:

$ dig thepiratebay.se

; <<>> DiG 9.8.3-P1 <<>> thepiratebay.se
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3828
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;thepiratebay.se.		IN	A

;; ANSWER SECTION:
thepiratebay.se.	300	IN	A	104.31.16.3
thepiratebay.se.	300	IN	A	104.31.17.3

;; AUTHORITY SECTION:
thepiratebay.se.	14249	IN	NS	dean.ns.cloudflare.com.
thepiratebay.se.	14249	IN	NS	sofia.ns.cloudflare.com.

;; ADDITIONAL SECTION:
dean.ns.cloudflare.com.	14249	IN	A	173.245.59.153
sofia.ns.cloudflare.com. 14249	IN	A	173.245.58.223

;; Query time: 201 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Apr 20 17:44:54 2017
;; MSG SIZE  rcvd: 153

With that in mind I tried to connect again, and voila!

It Works

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.