Cloudflare DoH: Netflix problems on SmartTV

Help
,
21

This happens when Netflix is running on an Xbox on the network, I don't think a regular URL would cause it. I did some more testing with tcpdump running and found the following - I'm not a network engineer so bear with me:

With the regular DNS servers set ("working" environment set to 1.1.1.1) it seems all the DNS queries and replies from the Xbox involving Netflix are done over UDP. When it is set to one of the "bad" environments, for some reason the Netflix app isn't satisfied with the first UDP reply so it does another request via TCP instead of UDP. After this TCP reply, dnsmasq hangs.

I thought first that just the TCP request was the problem so I tested doing the same query via TCP from another machine and it didn't crash it. I think the Netflix app isn't properly ending the stream - or at least it looks different - compare the following:

Broken (X is Xbox):

  1. X > pi [SYN]
  2. pi > X [SYN, ACK]
  3. X > pi [ACK]
  4. X > pi Standard query A api-global.netflix.com
  5. pi > X [ACK]
  6. pi > X Standard query response
  7. X > pi [ACK]

When I did a similar query from another linux machine (X is linux machine) as dig @pi +tcp api-global.netflix.com it looks like this:

  1. X > pi [SYN]
  2. pi > X [SYN, ACK]
  3. X > pi [ACK]
  4. X > pi Standard query A api-global.netflix.com
  5. pi > X [ACK]
  6. pi > X Standard query response
  7. X > pi [ACK]
  8. X > pi [FIN, ACK]
  9. X > pi [FIN, ACK]
  10. pi > X [ACK]

I'm not sure if that matters or not, but it seemed like one of the only differences.

I also looked at the query before the TCP one, to see if there was something obvious about why it would change from UDP to TCP on the next query. The only thing I can tell is that in the "broken" case, the response is larger (647 bytes) - the answer section seems to show the entire hostname in the Hex view of the packet, while the "working" case it seems to be some kind of abbreviated response (281 bytes total) but the info showin in Wireshark is identical as far as the server names and addresses.

2 Likes
22

Very interesting!

@Jason_A Could you try to prevent this TCP request from reaching your Pi-hole? Something like

sudo iptables -A INPUT -i eth0 -p tcp --destination-port 53 -j REJECT
sudo iptables -A INPUT -i eth0 -p udp --destination-port 53 -j ACCEPT

(provided your networking interface is called eth0)

1 Like
23

Seems happy with that - so far Netflix is running and I'm seeing the queries in the log, and it's not breaking.

3 Likes
24

Confirmed also working for me here running Netflix app on Xbox

1 Like
26

Can also confirm that Netflix is working after the iptables is added.

2 Likes
27

I have modified the DNS resolver slightly. It does now spawn child processes for handling individual TCP queries. By this, Netflix (or any other application) shouldn't be able to claim the resolver for itself.

@PromoFaux @vstoms @Jason_A (and anyone lese
I'd be very thankful if you could try again with the most recent version of FTLDNS after removing those iptables rules. There is no guarantee that this will work as I'm not able to reproduce it myself.

3 Likes
28

@DL6ER is this the correct version to test?
Current Pi-hole version is v3.3.1-74-g557372b
Current AdminLTE version is v3.3-92-ga83592b
Current FTL version is vDev-3656ba2

29

@DL6ER Confirmed working:
Current FTL version is vDev-3656ba2

Though, to make sure I've done the right thing (no experience with iptables) I just ran sudo iptables -F INPUT to kil off those two rules (I had nothing else there) Is that all I need to do?

@Jason_A
That is the correct version, yes.

1 Like
30

@PromoFaux Thanks for confirming version.

@DL6ER I also can confirm it works for me. Thanks!

2 Likes
31

Works for me too :slight_smile:

2 Likes
32

Works here too :slight_smile:

2 Likes
33

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.