Netflix detects Toronto tunnel server as being in the US.

[rldleblanc]

I already had a bind9 server, so setting up dnsmasq was just not appealing. After some trial and error, I think I got something that works.

Create an IP alias on an adapter in a subnet that you aren't going to use. ifconfig eth0:0 192.168.254.1/24 (You might be able to use an alias on the loopback device)

In the options section, be sure it is "listen-on { any; };" or has the IP address in the list. I created a new view for Netflix:

view "nf-fix" {
        match-destinations { 192.168.254.1; };
        recursion yes;
        dnssec-enable no;
        filter-aaaa-on-v4 yes;
};

And then in my view that my clients use for resolution I added:

zone "netflix.com" {
        type forward;
        forwarders { 192.168.2.1; };
        forward only;
};

This would be much easier if you could just specify filter-aaaa-on-v4 in a zone config. Basically, we are setting up a virtual bind instance to only handle forwards for Netflix and then we send our client requests for Netflix to it which strips off the AAAA records. Nice thing is that you can just add zone name for any other zones that are going to misbhave like Netflix. I've noticed that sometimes dig will cause bind to barf, but "host netflix.com" always seems to work just fine. I'm not where I can actually test Netflix at the moment, but I'll follow up if I run into some major issues.

An example of the error is:
named[4536]: DNS format error from 192.168.2.1#53 resolving www.latency.prodaa.netflix.com/ANY for client 192.168.21.10#38097: Name . (NS) not subdomain of zone netflix.com -- invalid response
named[4536]: error (FORMERR) resolving 'www.latency.prodaa.netflix.com/ANY/IN': 192.168.2.1#53

I hope it helps someone.

[rldleblanc]

OK, after getting home, the computer worked fine, but the Android phone didn't. Turns out that even after setting up radvd to send RDNSS and DNSSL info, Android still insists on using their name servers for IPv4 and IPv6 bypassing the work done on bind. So iptables to the rescue....

Code Select Expand

# If IPv6 DNS queries are not destined for our DNS server, redirect them to it
ip6tables -t nat -A PREROUTING -p udp --dport 53 -s 2001:470:wwww:xxxx::/64 ! -d 2001:470:wwww:xxxx::1 -j DNAT --to-destination 2001:470:wwww:xxxx::1
ip6tables -t nat -A PREROUTING -p tcp --dport 53 -s 2001:470:wwww:xxxx::/64 ! -d 2001:470:wwww:xxxx::1 -j DNAT --to-destination 2001:470:wwww:xxxx::1
# Protect packets already destined for our ipv4 DNS server by accepting them
iptables -t nat -A PREROUTING -p udp --dport 53 -d 192.168.yyy.1 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 53 -d 192.168.yyy.1 -j ACCEPT
# If IPv4 queries are not destined for our DNS server, redirect them to it
iptables -t nat -A PREROUTING -p udp --dport 53 -s 192.168.yyy.0/24 ! -d 192.168.yyy.1 -j DNAT --to-destination 192.168.yyy.1
iptables -t nat -A PREROUTING -p tcp --dport 53 -s 192.168.yyy.0/24 ! -d 192.168.yyy.1 -j DNAT --to-destination 192.168.yyy.1

This allows the Android phone to use Netflix without getting the tunnel error and without having to hack the phone's DNS. There is a delay to start watching videos as it tries really hard to get an AAAA record through both IPv6 and IPv4 and by requesting AAAA records specifically before trying A/ANY records. At least it is watchable and I don't have to sacrifice any other IPv6 sites.

[bjo]

Yay, the Fritzbox 7390 beta firmware supports IPv6 routes now, so I could nullroute the netflix prefixes.

[customcomputerca]

Using pfSense I was able to get Netflix to work by blocking 2620:108:700f::/48 on the LAN interface, TCP port 443 only.  If another range of addresses comes up I'll update this post.

Update: Had to block 2406:da00:ff00::/48 as well.

[mikerichardson]

I had a much easier workaround when using Tunnel Broker.

In /etc/hosts (and/or the Windows equivalent)

Code Select Expand

::1            www.netflix.com
52.86.14.136   www.netflix.com

Replace the IP with some random one from a "host www.netflix.com".

If the site breaks later, update the IP.

This is obviously impossible to do directly on a ROKU, etc. so the other solutions would still apply. (does a ROKU obtain an IPv6? I know that an old TiVo HD does not)

For some reason, if the initial contact is not via IPv6, none of the subsequent will be via IPv6 either.

[DyslexicFish]

I don't understand the reasoning for blocking, because Netflix clearly have some kind of geoip system in place. I have had the same content on IPV6 and IPV4.

Because it's not relevent. I could register a HE Tunnel via your local he.net ipv6 tunnel broker,. and yeah, netfix may now be able to geo-locate it, but it will now be located to your country.

In other words, if you wanted USA content, you'd be able to register with a USA endpoint, and voila!

Netfix is correct in basically considering ip6 tunnels a proxy. It may proxy ipv6 -> ipv4 instead of ipv4 -> to ipv4, but it'a still a proxy!

Incidentally, I'm not sticking up for the issue of geo-blocking -- I'm also not blaming netflix if the studios give them no choice, but hopefully when they have enough clout, they'll use it. Or maybe I'm wrong. Dunno. My point is, I'm not making any business/political/law comment in my post, purely technical.

Finally, unless you are having problems with routing, or you don;t run an ipv4 stack, why is this even an issue? I use ip6 to allow 'direct' access to my intternal hosts, and to show a unique address when connecting to my (and others) external servers. I also want to generally run ipv6 for programming, and learning reasons.

I don't use Netfilix, but Youtube is used quite a lot, as well as regular offsite backups, and I set them all to use IPv4 to not waste HEs bandwidth unnecessarily (I know I'm a tiny tiny tiny fish in the pond, but I try to be a good neighbour, and every bit can help) [ as a bonus, I'm now only 3 hops away from youtube via ip4 due to my ISP now hosting google servers in-house. - An event I may not have noticed otherwise)

I'm not having a go, I'm honestly curious to why you want ipv6 to netflix if you aren't using it to get around geo-restrictions?
I can see no reason to prefer tunneled IPv6 over IPv4 in these scenarios

[lobotiger]

Using pfSense I was able to get Netflix to work by blocking 2620:108:700f::/48 on the LAN interface, TCP port 443 only.  If another range of addresses comes up I'll update this post.

So I just setup my tunnel again (last time was the summer) and it looks like things are still blocked.  I tried the above prefix and while it appears to work for my desktop, I found that on my Android app, Netflix would be extremely slow to load up anything.  Typically this behaviour is due to it having an IPv6 address and still thinking that it has IPv6 connectivity.  The Netflix app will try and try and try to get the content via that method and eventually times out and goes over IPv4.  However, every time you load a video, the same process repeats itself and can take up to a full minute or more for a video to start playing.

Has there been any other news about how we can resolve this?

LoboTiger

[rudimeier]

The posted bind/dns proxy solutions are working best I guess. Quick an dirty you could simply add the A records only to /etc/hosts

Code Select Expand

dig www.netflix.com A +short  | sed -n 's/\([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\)/\1 www.netflix.com/p' >> /etc/hosts


For me it works also quick and dirty just to block the outgoing ipv6 traffic to netflix

Code Select Expand

$ ip6tables -A OUTPUT -j REJECT  -d www.netflix.com

This results in some auto-resolved rules, looks like this on my site

Code Select Expand

$ ip6tables -L OUTPUT
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
REJECT     all      anywhere             2a01:578:3::3412:fe98  reject-with icmp6-port-unreachable
REJECT     all      anywhere             2a01:578:3::3411:c7fc  reject-with icmp6-port-unreachable
REJECT     all      anywhere             2a01:578:3::3412:e37c  reject-with icmp6-port-unreachable
REJECT     all      anywhere             2a01:578:3::3411:d9a8  reject-with icmp6-port-unreachable
REJECT     all      anywhere             2a01:578:3::3411:ddb0  reject-with icmp6-port-unreachable
REJECT     all      anywhere             2a01:578:3::3411:d15b  reject-with icmp6-port-unreachable
REJECT     all      anywhere             2a01:578:3::3411:dea9  reject-with icmp6-port-unreachable
REJECT     all      anywhere             2a01:578:3::3412:297f  reject-with icmp6-port-unreachable


Don't know if they change their IPs very often, probably you should write a small shell script to re-new the rules from time to time automatically.

[snarked]

Re - "auto-resolved rules."  You should look into the ipset extensions to iptables.  With ipset, you can have a single iptables rule that covers all the IPs.  One can also add or subtract from the set (using ipset commands) and iptables will automatically adjust to the changes.

See http://ipset.netfilter.org/ for details.

If you're targeting a single organization, you should use their CIDR bitmask (/32 to /64).

[cbuijs]

If you use DNSMASQ as local resolver, add this to dnsmasq.conf:

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=/nflxvideo.net/#
address=/nflxvideo.net/::

This will result in only A-Records being resolved and the IPv6 tunnel not be used.

[zanechua]

For those using Unbound DNS you can use this:

local-zone: "netflix.com" typetransparent
local-data: "netflix.com IN AAAA ::"

local-zone: "netflix.net" typetransparent
local-data: "netflix.net IN AAAA ::"

local-zone: "nflxext.com" typetransparent
local-data: "nflxext.com IN AAAA ::"

local-zone: "nflximg.net" typetransparent
local-data: "nflximg.net IN AAAA ::"

local-zone: "nflxvideo.net" typetransparent
local-data: "nflxvideo.net IN AAAA ::"

local-zone: "www.netflix.com" typetransparent
local-data: "www.netflix.com IN AAAA ::"

local-zone: "customerevents.netflix.com" typetransparent
local-data: "customerevents.netflix.com IN AAAA ::"

local-zone: "secure.netflix.com" typetransparent
local-data: "secure.netflix.com IN AAAA ::"

local-zone: "adtech.nflximg.net" typetransparent
local-data: "adtech.nflximg.net IN AAAA ::"

local-zone: "assets.nflxext.com" typetransparent
local-data: "assets.nflxext.com IN AAAA ::"

local-zone: "codex.nflxext.com" typetransparent
local-data: "codex.nflxext.com IN AAAA ::"

local-zone: "dockhand.netflix.com" typetransparent
local-data: "dockhand.netflix.com IN AAAA ::"

local-zone: "ichnaea.netflix.com" typetransparent
local-data: "ichnaea.netflix.com IN AAAA ::"

local-zone: "art-s.nflximg.net" typetransparent
local-data: "art-s.nflximg.net IN AAAA ::"

local-zone: "tp-s.nflximg.net" typetransparent
local-data: "tp-s.nflximg.net IN AAAA ::"

[fir3drag0n]

Yay, the Fritzbox 7390 beta firmware supports IPv6 routes now, so I could nullroute the netflix prefixes.

How does it look like in the configuration of the Fritzbox?

[fir3drag0n]

any help here?

[bjo]

I'm using the unbound-solution now, so no need for nullrouting prefixes in the Fritzbox, so I can not provide any screenshots.

[chadblose]

For those using Unbound DNS you can use this:

local-zone: "netflix.com" typetransparent
local-data: "netflix.com IN AAAA ::"

local-zone: "netflix.net" typetransparent
local-data: "netflix.net IN AAAA ::"

local-zone: "nflxext.com" typetransparent
local-data: "nflxext.com IN AAAA ::"

local-zone: "nflximg.net" typetransparent
local-data: "nflximg.net IN AAAA ::"

local-zone: "nflxvideo.net" typetransparent
local-data: "nflxvideo.net IN AAAA ::"

local-zone: "www.netflix.com" typetransparent
local-data: "www.netflix.com IN AAAA ::"

local-zone: "customerevents.netflix.com" typetransparent
local-data: "customerevents.netflix.com IN AAAA ::"

local-zone: "secure.netflix.com" typetransparent
local-data: "secure.netflix.com IN AAAA ::"

local-zone: "adtech.nflximg.net" typetransparent
local-data: "adtech.nflximg.net IN AAAA ::"

local-zone: "assets.nflxext.com" typetransparent
local-data: "assets.nflxext.com IN AAAA ::"

local-zone: "codex.nflxext.com" typetransparent
local-data: "codex.nflxext.com IN AAAA ::"

local-zone: "dockhand.netflix.com" typetransparent
local-data: "dockhand.netflix.com IN AAAA ::"

local-zone: "ichnaea.netflix.com" typetransparent
local-data: "ichnaea.netflix.com IN AAAA ::"

local-zone: "art-s.nflximg.net" typetransparent
local-data: "art-s.nflximg.net IN AAAA ::"

local-zone: "tp-s.nflximg.net" typetransparent
local-data: "tp-s.nflximg.net IN AAAA ::"

I tried this in my OPNsense configuration and it didn't work, Netflix still gave me a proxy detected error. I'm not sure if it has to do with me using Stubby as my stub resolver with this configuration:
forward-zone:
name: "."    # Allow all DNS queries
forward-addr: 127.0.0.1@8053