DNS Piracy Blocking Orders: Google, Cloudflare, and OpenDNS Respond Differently - 8.8.8.8 refuses queries, 1.1.1.1 returns status 451, and OpenDNS geoblocks European IPs

Link (Archive)

The frontline of online piracy liability keeps moving, and core internet infrastructure providers are increasingly finding themselves in the crosshairs.

For rightsholders, site blocking remains the go-to response in many cases. Until recently, the majority of blockades were implemented by consumer ISPs, but expanded legal efforts are now targeting standalone DNS resolvers.

Over the past year, courts in France, Italy, and Belgium have ordered OpenDNS, Cloudflare, and Google to alter their responses to certain DNS queries. Instead of leading visitors to the domains of pirate sites, the companies are required to intercept queries and redirect them elsewhere.

The main rationale for targeting public DNS resolvers is their growing use for bypassing blocking measures rolled out by Internet providers. However, the American tech companies now being targeted are not happy with the role of ‘Internet police’ and appeals of these orders are still pending.

OpenDNS Says Farewell​

While these legal battles play out in court, the DNS resolvers still have to comply one way or another. This has resulted in different responses, with Cisco’s OpenDNS taking by far the most drastic action.

When OpenDNS was first ordered to block pirate sites in France, the company made a simple but drastic decision to leave the country entirely, effectively affecting all French users. Last week, it repeated this response in Belgium following a similar court order.

Instead of blocking access to more than 100 sports piracy sites, as the Belgian order requires, OpenDNS announced its departure; at least temporarily.

“Due to a court order in Belgium requiring the implementation of blocking measures to prevent access within Belgium to certain domains, the OpenDNS service is not currently available to users in Belgium,” the company said.

Cloudflare Complies Using ‘Alternate Mechanisms’​

Not all DNS resolvers take such drastic measures. Cloudflare chooses to comply with court orders in its own way. Cloudflare DNS (1.1.1.1) users who try to access the targeted domains in countries where blocking orders are issued, see the following notice instead.

livescooerclou.jpg.webp

Interestingly, Cloudflare maintains in its transparency report that it is not blocking content through its public DNS resolver. Instead, it points out that it uses “alternate mechanisms”.

“Given the extraterritorial effect as well as the different global approaches to DNS-based blocking, Cloudflare […] identified alternate mechanisms to comply with relevant court orders. To date, Cloudflare has not blocked content through the 1.1.1.1 Public DNS Resolver,” the company writes.

dns-blocked.jpg.webp


The result for Cloudflare DNS users appears to be the same, however. Those who try to access the blocked domains in the applicable countries will be redirected to the HTTP 451 error.

The good news is that affected users are informed about the reason for this technical blockade via the Lumen Database. That doesn’t appear to be the case with Google.

Google’s DNS Blackout​

After running tests in both Belgium and France, using various blocked domains, it’s clear that the targeted websites are no longer accessible through Google’s public DNS resolver (8.8.8.8). However, unlike Cloudflare, there is no notification whatsoever.

Instead, Google appears to simply refuse the DNS query, which means that the domain lookup is not linked to any IP address.

refused.jpg.webp


While this is effective in the sense that the pirate sites are no longer available, it’s not very transparent. Users who try to access the domains will simply see a browser error, which could be caused by various DNS issues.

Google’s basic response is not limited to the recent Belgian court order. We observed the same query refusal for domain names that were included in French blocking orders over the past several months.
livesoccerblocked.jpg.webp

Transparency is Paramount​

While the different responses from DNS resolvers are interesting, Google’s approach doesn’t make blocking efforts more transparent. These orders are still relatively new, so it’s possible that the company is working on offering more transparency in the future, but currently it only adds to the confusion.

Google’s response also appears to go against the advice of the Belgian court, which required the DNS providers to redirect users to a dedicated page, presumably to provide further detail.

redirect.jpg.webp


If these blocking orders are upheld by various courts, a more streamlined approach will be welcome. Interfering with DNS is a big step that can’t be taken lightly, so transparency is paramount. That’s relevant for the United States too, where a new site-blocking bill also proposes public DNS resolver blockades.



For context, a copy of the recent Belgian court order shared by Cloudflare is available here (pdf)


@Null this may be of interest to you.
 
The article glosses over the most insidious bit that Cloudflare is doing, impersonating the site in question. Shockingly Google along with OpenDNS is doing the least evil thing here.

Cloudflare is a certificate authority. It can issue a certificate for any website and contemporary browsers trust it explicitly. Using Cloudflare's DNS is not only hijacking the question, "where is this website?", it's hijacking the question "what's on this website?". In the screenshot the https:// is not crossed out - the browser trusts Cloudflare to serve the content it expects, and since it presents a valid certificate, it makes no complaint that the content is genuine.

So if Cloudflare wanted, yeah, it could fuck with you actively rather than just ignoring what you're asking for. It is a very good argument against CF as a whole if they are willing to do this.
 
Imagine not running your own DNS server. Imagine not blocking ads with DNS because you have your own DNS server. Imagine giving every query you make directly to google, cloudflare, or your ISP instead of using dnscrypt on your DNS server. Imagine being niggercattle.

Couldn't be me.
 
A new front. All this is the perfect backdoor for mass internet censorship. We can't allow ghouls to push any further in the US with this shit.
The insanity of it all is getting scary.. and old real quick.

Crashing the CR system with no survivors, is pretty much the only hope at this point.
 
Last edited:
I just run my own DNS, which gets its responses directly from a root server. I never have any of these issues.
I run a local DNS but it never occurred to me to actually go to a root. I've always just thought of local DNS as more of a DNS cache and used public DNS servers as forwarding. Fuck I'm retarded. Do I just remove forwarding servers and my local server will have no choice but to go to root servers?
 
I run a local DNS but it never occurred to me to actually go to a root. I've always just thought of local DNS as more of a DNS cache and used public DNS servers as forwarding. Fuck I'm retarded. Do I just remove forwarding servers and my local server will have no choice but to go to root servers?
Disclaimer to the following: I'm still an abject retard when it comes to DNS stuff...

I'm going on the assumption that you're running Pi-Hole here, but you can't just remove the forwarding. My Pi Hole forwards to 127.0.0.1 (localhost), but I have Unbound (an actual DNS server, not a filter) running on that interface and it's set to ignore anything that doesn't come from Pi-Hole (which is good for security). Being a proper DNS server, Unbound will always go to a root server when an address isn't in the cache.

This is a decent guide on setting it up. The only thing I did in my config was set do-ip6 to "no" since IPv6 is a huge pain in the ass IMO.

I also use the DHCP server built into Pi-Hole since it gives me a bit more control than the shitty options my router has. And since Pi-Hole is handing out IP addresses, anything that connects to my network automatically has its DNS settings pointed to Pi Hole. Requests that aren't in Pi-Hole's filters or cached get kicked over to Unbound. Anything Unbound doesn't have cached gets sent to a root server. And I can still use Pi-Hole as a local DNS so I can always get to things like myphone.local or mediaserver.local rather than having to remember their IP (or even set them as static in the first place).
 
Back