Blocking Netflix Auto-play Trailers

While sitting at home, working on a new coding project, I wanted to have something playing in the background. While looking for something…

Blocking Netflix Auto-play Trailers

While sitting at home, working on a new coding project, I wanted to have something playing in the background. While looking for something to watch on TV, I became very annoyed of the trailers that pre-roll as I scrolled through the clunky interface of Netflix. I then minimized my coding project and decided, I wanted to put an end to this annoying bug in the software Netflix hasn’t been able to fix (/s).

TLDR; I fix it with my firewall, it stopped the trailers, but videos also take longer to load as it needs to pull from servers further away.

My network

Let me start by saying, my network is a little more advanced than your typical network. I have a firewall (+IPS) that logs all connections to a log server, including my internal BIND (DNS) server. Using these tools, and my Xbox One, I was able to navigate Netflix and watch the DNS queries and IP connections being made.

Netflix DNS

My first thought was that the Netflix app was making DNS calls to a collection of servers that held the trailers. Seemed like a simple approach, but in retrospect, people would have posted the DNS entries online and this would be a quick and easy fix. I saw these DNS queries coming through (and more):

api-global.netflix.com
cdn-0.nflximg.com
secure.netflix.com

After blocking and unblocking each DNS entry, including ones not in this list, I found that api-global.netflix.com is needed to start the application, get the trailer, and load videos. Ultimately, watching the DNS queries in the logs didn’t help much but stop Netflix from working altogether.

IP Connections

The next step was checking what connections were being made by the application. I narrowed down the logs to my Xbox and started navigating the UI. I noticed that certain IP addresses were being accessed while the trailers were being loaded. With that said, I think the api-global subdomain is returning IP addresses so that the application doesn’t need to resolve DNS entries for the trailers or videos. However, I don’t see the content of the response because I haven’t looked into the packets. I think this because I don’t see different DNS entries when loading a movie or TV show, only the API server.

What I Found

I grabbed the handful of IP addresses I found while looking at the logs. I then did a reverse DNS lookup dig -x <IPADDRESS> on each IP address that I found — there wasn’t many. I found that these IP addresses belong to my ISP, which makes sense. I’m sure Netflix has worked something out with ISPs to put these servers as close to their customers as they can. With that said, I then began to block these IP addresses. I have to assume there’s more than just three IP addresses that I found hosting these trailers, so I ended up using a couple /24s out of the /16s that ICANN has listed my ISP as owning in that range.

Sure enough, after closing down Netflix and re-opening, I was able to navigate the UI without having any trailers play. I only needed to block three /24s in my firewall. Once I attempted to watch a TV show, as I expected, the video took a little longer to buffer. Not only that, but the quality looked poor for at least a minute while the video downloaded. With that said, it’s important to note, you will not have the best watching experience for some of these high quality movies if you need to reach out to servers that are much further away and you don’t have a good connection. You will also need to find the IP addresses that your ISP is using, I doubt ours are the same.

What Was Blocked

Before I end this post, I’d like to share what connections were blocked on my firewall. Also, it’s important to note, I did to find and block these IP addresses, but it can be done by anyone with networking skills. You don’t need a network like mine to load up Wireshark and watch the connections being made. Also, what you’re doing is what every major enterprise in the world does, they all look at network traffic logs, so this is a known and exercised practice, no need to reverse engineer anything.

DST=69.47.64.14 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=59186 DF PROTO=TCP SPT=50314 DPT=443 WINDOW=32768 RES=0x00 SYN URGP=0
DST=69.14.162.42 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=35528 DF PROTO=TCP SPT=50206 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
DST=45.57.63.152 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=28481 DF PROTO=TCP SPT=50120 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0