Why site blocking doesn’t work

Shaun Ewing Technology 0 Comments

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:

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:

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

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.

Why site blocking doesn’t work was last modified: May 1st, 2017 by Shaun Ewing

Leave a Reply

Your email address will not be published. Required fields are marked *