This gist was essentially created out of my own rant about Netflix being hostile to IPv6 tunnel services since June 2016. You are welcome to read my opinion on the matter, this is the more technical side to the issue and how to combat it within your own network.
Since I wrote this, various GitHub users have contributed their thoughts and ideas which has been incorporated into this gist. Thank you to everyone who have contributed their own methods and implementations.
Netflix now treats IPv6 tunnel brokers (such as Hurricane Electric) as proxy servers. A while ago it became apparent to users and Netflix that somewhat by accident, IPv6 tunnel users were being served content outside of their geolocation because of the way Netflix was identifying the tunnel services and their geographical origin. The problem was further compounded by certain opportunstic indiviuals deciding to create a business model out of providing the Netflix US (and others) content library via networks like Hurricane Electric and ruined it for everyone. Netflix and friends got all stressy about it and now all IPv6 tunnel users are considered to be naughty proxy pirates. Also because big media is stuck in the 1990s, they think this block is actually effective, when in fact it just inconveniences most legitimate users, that simply want IPv6 connectivity, because their ISP is stuck in 1995.
Netflix has a help article on the matter: https://help.netflix.com/en/node/277
In the early days this article didn't mention anything about IPv6 tunnels, but now it pretty much spells out if you use a tunnel service for IPv6 you are on your own and won't get any support from Netflix about it, but there is a potential workaround. In order to maintain keeping your IPv6 tunnel active while browsing Netflix you need to basically prevent any traffic to Netflix going over IPv6 and fallback to IPv4, which will likely be using your normal WAN connection from a ISP or provider which Netflix won't treat as a proxy/VPN.
To implement such a workaround you'll need to have a DNS setup that you can fully control. You'll need to have the ability to implement one of the following implementations:
- Return a null response on AAAA lookups for certain Netflix domains.
- Conditionally forward certain Netflix domain lookups to another DNS resolver that strips AAAA records from lookup responses entirely.
- Block or sink hole Netflix IPv6 ranges (not recommended, explained in more detail later on).
This gist focuses on using dnsmasq (commonly found in embedded products i.e. routers) but the overall concept of modifying AAAA lookup responses can be applied to other services like unbound, bind etc.
- netflix.com
- netflix.net
- nflxvideo.net
- nflximg.net
- nflximg.com
- nflxext.com
- nflxsearch.net
- nflxso.net
Netflix through their Open Connect programme, also lists the top level domains which requests will come from.
The configuration below basically returns an AAAA response with a NULL address on any domains provided. The only downside to this method is you have to generate a matching server and address line for each domain, otherwise you will unwillingly remove A record responses. Your dnsmasq.conf could get quite long very quickly using this method. If you have a bulk load of domains you could write a script to output the server and address lines to a file with the domain being a variable in a loop, fed by a list or another source.
# Null AAAA response on these domains
server=/netflix.com/#
address=/netflix.com/::
server=/netflix.net/#
address=/netflix.net/::
server=/nflxext.com/#
address=/nflxext.com/::
server=/nflximg.net/#
address=/nflximg.net/::
server=/nflximg.com/#
address=/nflximg.com/::
server=/nflxvideo.net/#
address=/nflxvideo.net/::
server=/nflxso.net/#
address=/nflxso.net/::
server=/nflxsearch.net/#
address=/nflxsearch.net/::
If you are already running dnsmasq, this is the most simpliest method, without having to worry about additional configurations or services. After this configuration is applied a DNS lookup for a domain in this list would now return ::, which is the NULL response. This would prevent netflix.com requests going over IPv6 and fallback to IPv4.
; <<>> DiG 9.10.3-P4-Raspbian <<>> AAAA netflix.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6272
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;netflix.com. IN AAAA
;; ANSWER SECTION:
netflix.com. 2 IN AAAA ::
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 28 11:23:40 GMT 2018
;; MSG SIZE rcvd: 57
A slightly more involved method is to conditionally forward DNS requests for certain Netflix domains to another DNS resolver that will strip AAAA records from domains. In this scenario, there will be another DNS resolver running somewhere in the network.
Using dnsmasq as an example, you can define conditional forward rules like so:
# Resolve these domains with another resolver
server=/netflix.com/127.0.0.1#2053
server=/netflix.net/127.0.0.1#2053
server=/nflxext.com/127.0.0.1#2053
server=/nflximg.com/127.0.0.1#2053
server=/nflxvideo.net/127.0.0.1#2053
server=/nflxso.net/127.0.0.1#2053
server=/nflxsearch.net/127.0.0.1#2053
server=/nflxext.com/127.0.0.1#2053
127.0.0.1#2053 is the DNS resolver that will resolve the request. The DNS resolver could be anything or running anywhere. In this example, a DNS resolver is running on UDP 2053, in reality this can be anything. I will use bind for the resolver.
I chose bind as it has a specific parameter filter-aaaa-on-v4. The example below is a very minimal configuration for bind. Its one purpose is basically to strip AAAA records from DNS lookups. It has the advantage of being domain agnostic, meaning it will strip any AAAA records from any domain passed to it. This is useful if other services other than Netflix start blocking IPv6 tunnels in a similar fashion or simply want to force IPv4 for other services for whatever reason.
options {
directory "/tmp";
forwarders {
208.67.222.222;
208.67.220.220;
};
forward only;
dnssec-enable no;
auth-nxdomain no;
listen-on port 2053 { 127.0.0.1; };
// listen-on-v6 port 2053 { ::1; };
filter-aaaa-on-v4 yes;
};
You can use any forwarders you like, the example below uses OpenDNS. If you are running this on an external facing IP address, you should be careful and make sure you only allow recursion on specific requests and ACL accordingly. Not doing so will make you an open DNS resolver, it won't take long for someone to start abusing your server and generating a high rate of traffic.
The --enable-filter-aaaa option must be enabled at compile time in order for this config to work, see this page for more information:
https://kb.isc.org/article/AA-00576/0/Filter-AAAA-option-in-BIND-9-.html
Where this resolver runs is entirely up to you. If you are running something like OpenWRT or DD-WRT you could run bind on a non-standard port like the example to avoid a port collision with an existing DNS setup i.e. dnsmasq.
Once everything is setup, you can query any of the following Netflix domains listed above against a public DNS resolver and compare the output to a query made to the additional DNS resolver you've setup.
AAAA DNS request made via Google Public DNS
Google's public DNS servers will always return AAAA records, this is what a typical request to netflix.com will look like:
dig @8.8.8.8 netflix.com AAAA
; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @8.8.8.8 netflix.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21293
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;netflix.com. IN AAAA
;; ANSWER SECTION:
netflix.com. 59 IN AAAA 2620:108:700f::36d6:fc9
netflix.com. 59 IN AAAA 2620:108:700f::36d6:177c
netflix.com. 59 IN AAAA 2620:108:700f::36d6:fed
netflix.com. 59 IN AAAA 2620:108:700f::36d6:25bf
netflix.com. 59 IN AAAA 2620:108:700f::36d6:d62
netflix.com. 59 IN AAAA 2620:108:700f::36d6:1cd2
netflix.com. 59 IN AAAA 2620:108:700f::36d6:22b2
netflix.com. 59 IN AAAA 2620:108:700f::36d6:1699
;; Query time: 36 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 25 12:51:43 GMT 2016
;; MSG SIZE rcvd: 264
AAAA DNS request made via the BIND DNS server we setup
Making the same request to our primary DNS resolver that has been configured to strip AAAA records, we should get no AAAA records returned, even if we explicitly request them.
dig @127.0.0.1 netflix.com AAAA
; <<>> DiG 9.9.9-P3 <<>> @127.0.0.1 netflix.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36923
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;netflix.com. IN AAAA
;; Query time: 130 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Nov 25 12:51:43 GMT 2016
;; MSG SIZE rcvd: 40
If you get no AAAA records returned on your DNS resolver with Netflix queries, you're in business. Future Netflix connections should now only use IPv4. If you don't get the expected output this can be due to DNS caching and depending on your setup you might have to wait a bit of time for the correct DNS lookup information to be returned. You can flush the DNS cache of dnsmasq and/or on your local device. Alternatively, you may wish to reboot your router or device supplying DNS to ensure DNS caches are cleared. If you have a DNS chain, you'll need to ensure all DNS resolvers in the chain are not caching.
If you get issues like timeouts, check to make sure the DNS server is actually running and your firewall is permitting the DNS traffic, especially if using a non-standard port for DNS traffic.
While this method can work, the problem with it is that it is static and not as future proof as DNS related options. The problem is Netflix uses various content delivery networks and obtaining the ranges for them all is difficult. Netflix can also add new IPv6 ranges at anytime. While all of the workaround options can be "broken" by Netflix changing something, in my opinion domain based rules are cleaner than IPv6 ranges. Be mindful that blocking IPv6 ranges may require you to block non-Netflix networks like content delivery networks, which could have side effects for non-related services.
If however you wish to null route or block IPv6 ranges, this can be achieved like so with ip6tables:
ip6tables -I OUTPUT -d 2a01:578:3::/64 -j REJECT
ip6tables -I FORWARD -d 2a01:578:3::/64 -j REJECT
You may have to experiment with additional ranges in order to stop Netflix using IPv6 for your geolocation.
You may have to implement further changes if you experience problems with Google/Android devices.
Devices like Google Chromecast don't allow direct control of the DNS servers used and always try to use Google's Public DNS resolvers (both IPv4 and IPv6), these of course will return AAAA records and will undo any DNS workaround when streaming Netflix from such a device. You can however leverage a fallback option built into Chromecast devices (and likely other Google devices), where by if you block access to the Google Public DNS resolvers, it forces the Chromecast device to use the DHCP supplied DNS information and hence the DNS workaround will work.
An example of doing this with iptables:
iptables -I FORWARD --destination 8.8.8.8 -j REJECT
iptables -I FORWARD --destination 8.8.4.4 -j REJECT
In addition, some Google devices may also make DNS lookup requests over v6 to Google's public DNS servers, you may have to also block this traffic as well:
ip6tables -I FORWARD --destination 2001:4860:4860::8844 -j REJECT
ip6tables -I FORWARD --destination 2001:4860:4860::8888 -j REJECT
REJECT is a bit more friendly than DROP in this case, as the "fail" response will be quicker. You want the request to fail quickly in this case. You'd use DROP in a more defensive/security scenario.
If you happen to use Google's DNS resolvers at the network level for general DNS queries you can limit this block to the IP address of your Chromecast device with the -s option, allowing you to use Google's DNS resolvers for other devices still. This would require you to use static DHCP in order to create a fixed LAN IP address for any Chromecast devices you have, so you know where they are on the network.
There are several reports that some Google based devices like Android tablets don't seem to like having the Google public DNS resolvers sinkholed. If you experience problems streaming with devices like Chromecasts, Google tablets etc. after blocking Google DNS requests, you might want to instead intercept the requests rather than block them. This can also be achieved via iptables:
iptables -t nat -A PREROUTING -s 192.168.x.x/24 -d 8.8.8.8 -p udp --dport 53 -j DNAT --to 192.168.x.x
iptables -t nat -A PREROUTING -s 192.168.x.x/24 -d 8.8.4.4 -p udp --dport 53 -j DNAT --to 192.168.x.x
- 192.168.x.x/24 - Range of your LAN, example:
192.168.1.0/24 - 192.168.x.x - The device that is running DNS i.e. router
192.168.1.1
This method essentially allows DNS requests to 8.8.8.8 or 8.8.4.4, but the request itself will be intercepted and actually resolved by a DNS server of the users choosing, alebit transparently. You can run the Google DNS test example if you apply this method and confirm that no AAAA records are returned, because the DNS server used was actually something else.
DNS traffic is typically UDP based, but there are circumstances where TCP is used as well, however, it is unlikely any Google DNS request will be using TCP, hence why the rules above only target UDP and should be fine for this purpose.
To implement this, you'll need to have a full root access to your router.
Enjoy your Netflix again!
In case you have any questions about the purpose/reasons for this workaround, here's some answers to potential questions you might have.
Q. Will I be able to stop using this workaround at some point?
A. Once your ISP provides a native IPv6 subnet to you, you can disable your IPv6 tunnel and use the IPv6 subnet delegated to you by your ISP (likely a /56 or something similar).
To clarify, Netflix is only blocking IPv6 tunnels because it cannot accurately confirm your exact country of origin and sees any usage of a IPv6 tunnel as a way of circumventing geo-restrcitions on content that is licensed to specific countries, despite this being the intention or not. In the case of Hurricane Electric, while it operates tunnels in loads of different countries, the IPv6 address space they have registered ultimately identifies as US to a lot of geo based systems concerning IPv6. Various Geo IP services may also differ on what country it believes the IPv6 space to be part of, which can be inconsistent. This problem however is now redundant as Netflix decided to just block any HE tunnel IPv6 prefix from even connecting to their streaming service, which is why you know get the VPN/proxy message.
Q. I use a VPN and I get the same error message, will this workaround work for this?
A. Using a VPN with Netflix is very tricky because Netflix actively blocks such services. You'll likely want to look at something called split tunnelling where by you have a VPN connection active, but send Netflix traffic through your WAN (non VPN gateway). This however is out of scope of the original purpose of this gist, but you should read up on split tunnelling options to avoid this problem.
Q. Will Netflix block my ISP connection?
A. They shouldn't do. When you use your ISPs connection, the IP address you connect from shouldn't be considered a proxy/VPN. There have been cases of false positives leading some residential IP addresses being flagged. If you are unlucky enough to end up in this situation you will need to alert your ISP/Netflix to resolve.
Q. How does this workaround work?
A. In short, the workaround forces Netflix traffic to use IPv4 for any requests when streaming. While you might think "why can't I just to make things use IPv4 first?" in reality, this is both against the general behaviour of IPv6 first and difficult to actually enforce, especially if you need to do this across different devices. Doing it at the router/DNS level allows you to control all variables required. This does require a bit of technical knowledge and control over your network however and might not be for everyone admittedly.
Q. Does Netflix support IPv6?
Yes and to their credit they have done for many years. The issue is not IPv6 itself, it is the fact that those who wish to have IPv6 but don't have native IPv6 from their ISP have opted to use tunnels using a protocol called 6in4 (Encapsulating IPv6 packets on specifically configured IPv4 links). However because of Netflix's stance on IPv6 tunnels being classified as "proxies", those that use them are now facing the challenge of not being able to access Netflix over IPv6 as when IPv6 connectivity is available this will be tried first.
Q. Will this workaround stop working in the future?
A. Depending on how you implemented it, it should be pretty robust, but if Netflix introduce a new domain not covered in the list above that has some form of IPv6 connectivity test which then determines proxy/VPN usage, it may have to be expanded, I have personally used this workaround since June 2016 and it hasn't let me down yet.
Q. Does this workaround allow me to bypass geo-restrictions?
A. No. It is simply designed to allow connectivity to Netflix, while having an IPv6 tunnel active. This does not allow you to obtain access to library content outside your region. This is basically the reason why this workaround had to be implemented in the first place for us legit IPv6 tunnel users. This is why we can't have nice things!
Q. Will Netflix unblock IPv6 tunnels in the future?
A. Probably not, they were likely pressured into it in the first place by media companies and license holders. Once the secret was out about how IPv6 tunnels were providing access to what should have been geo-restricted content, action was swiftly taken. To be honest, Netflix probably doesn't care that much about this (as long as your paying your monthly subscription!). It was more likely being lent on by higher powers, hence the rather bold straight blocking approach.
Its also worth noting that IPv6 tunnel services are intended as transitional mechanisms and shouldn't be a permanent solution for IPv6. Hassle your ISP to sort out their IPv6 (or lack of!). While you wait you can also read the hilarious IPv6 excuses Twitter account for some nerdy IPv6 banter: https://twitter.com/ipv6excuses?lang=en.
Q. Do any proxy/VPN services still work with Netflix?
A. There are likely some services that might still work, but they are likely operating on borrowed time, as Netflix will be monitoring and updating their blocklists regularly. Most of the well known proxy/VPN services are blocked. More recently VPN providers are trying to get clever by routing their traffic through what look like residential IPs to look less obvious to bypass blocks, but again Netflix is always watching and will ban these IPs too eventually.
Q. I'm not able to install additional software like bind, are there any alternatives?
A. Yes. There is a excellent lightweight DNS proxy specifically for Netflix IPv6 tunnel purposes. Written in Python, it should work on most Unix/Linux systems with little setup required.
https://github.com/cdhowie/netflix-no-ipv6-dns-proxy
The same concept applies, you need to have your primary DNS resolver forward requests to this proxy, be aware this DNS proxy is specifically for Netflix domain usage and won't strip the AAAA records of other domains if sent to it. You can edit the source code to expand it if you wanted to though.
Q. Who is "big media"?
A. My pet name for the media rights corporations who are probably in the illuminati stuck in the past and clearly don't understand technology.
@brianjmurrell It's a good question, although unless the situation changed Netflix ended up blocking any HE IPv6 tunnel prefix in the end, so I'm not sure it would help now. Depending on how regularly or if new pops are added, there might be a couple that get through, until Netflix update their blocklist.
It's been a long time but if I remember correctly the original problem was using a HE tunnel meant you got served different geo content in contradiction to your account settings, i.e. US when in UK. this was because of a lot of the HE IPv6 space just being branded as US origin by whatever geo IP data was in use, given the IP allocations being from ARIN. Then Netflix went up a gear and straight blocked HE tunnels entirely which as far as I know is still the case. I assume Netflix may have also adjusted how it determines what content to show, given they could just look at the Country of Residence on your Netflix account and know there's a difference, but geo IP data can be very hit and miss as you've pointed out from the varying databases entries.
So unless they've not blocked HE tunnel ranges anymore, I don't think geo IP data is going to help. They've essentially banded HE tunnels as proxy servers and treat them in a similar way to VPNs.