Roku evading DNS interception

Balance 20x running firmware 8.1.1 with a Roku box behind it.

I don’t trust Roku, so I am logging its outgoing requests and I notice something unusual. The Roku is making outbound requests to Google DNS at 8.8.8.8 and 8.8.4.4 on TCP port 53 rather than UDP port 53.

The Balance 20x is doing DNS interception, that is, legacy DNS from any device on the LAN should be forced to use the DNS servers in the router. Specifically:
network → network settings → DNS proxy is enabled and Include Google Public DNS Servers is disabled
network → service forwarding → DNS Forwarding is enabled
The router is not using Google for DNS.

So, I wonder what is leaving the WAN port. Are the TCP requests to Google DNS being intercepted by the router or not? Turns out, they are not intercepted.

I know this because the Balance 20x sits behind a Surf SOHO also running 8.1.1. I set the B20x to log every outgoing request from the Roku box. I set the Surf SOHO to log both TCP and UDP to port 53 from the Balance 20x. Here are the log entries

Balance20x
Mar 19 11:03:59 Firewall: Allowed CONN=vlan
SRC=192.168.5.42 DST=8.8.8.8 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=12781 DF
PROTO=TCP SPT=36041 DPT=53 WINDOW=42340 RES=0x00 SYN URGP=0 MARK=0x3

Surf SOHO
Mar 19 11:03:59 Firewall: Allowed CONN=lan
SRC=192.168.2.8 DST=8.8.8.8 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=12781 DF
PROTO=TCP SPT=36041 DPT=53 WINDOW=42340 RES=0x00 SYN URGP=0 MARK=0x2

nmap shows that 8.8.8.8 has TCP port 53 open. Here is the output of a quick scan

Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-19 11:24 Eastern Daylight Time
Nmap scan report for dns.google (8.8.8.8)
Host is up (0.058s latency).
Not shown: 98 filtered ports
PORT STATE SERVICE
53/tcp open domain
443/tcp open https

It seems that Roku has successfully evaded the router rule on DNS and forced the use of Google DNS.
Is there anything I can do about this?
Should the router also be intercepting TCP port 53?

Off-topic: It seems you can block outbound TCP port 2350, which Roku often uses, without any noticeable effect.

Yes, it probably should be - not like DNS over TCP53 is a new thing!

Do you have any capture of the outdoing DNS queries from the Roku itself?

Typically TCP53 is used only when the response would be larger than 512k bytes or if UDP is explicitly blocked (I assume you get valid answers from queries sent to 8.8.8.8 via UDP behind the 20X?).

Edit - Do you get valid answers from the 20X if it intercepts a query that would get a response greater than 512k bytes, I wonder if the Roku is asking for a specific domain that is getting dropped / truncated by the DNS proxy in the 20X and therefore it falls back to using TCP for the outgoing query?

I still find numerous firewalls today that have DNS inspection / interception features that do not respect EDNS etc and they cause all sorts of odd problems!

1 Like

I did some nslookup commands on a Windows PC behind the B20x and they showed that the B20x was also not intercepting UDP port 53 either. The server used by default was one from Windows rather than the router. Generated a diagnostic report and will open a ticket.


NOTE: This is not true, it was a mis-understanding with two causes.

Even when normal UDP port 53 is being intercepted, the client devices are not aware of this. Software running in Windows, for example, thinks it is talking to the DNS servers that Windows is configured to use. Even the nslookup command is fooled.

The other issue was that, in some cases, the router does not log outgoing UDP port 53. Being investigated.

FYI: Tech support confirmed that for DNS they do not intercept TCP port 53, they only intercept UDP port 53. TCP port 53 is normally used for DNS zone transfers. So, it seems that Roku has indeed found a way to use Google DNS.

This is technically incorrect.

Sure, zone transfers are done via TCP53 but TCP53 will also be used by regular clients quite a bit these days - hence me asking if you had a capture of what domains it was trying to call home to.

This blog from Infoblox does a good job of explaining this behaviour, in the future you are also going to have to consider clients that fall back to DoT / DoH if they cannot get out on UDP/TCP 53 and intercepting that traffic is a whole lot more problematic:

This is why for me if I really want to enforce the use of a specific DNS in my network I will explicitly block the outgoing traffic at the firewall / router (preferably with a stateless ACL), rather than try and hijack / intercept people trying to use another service.

When they get no answers at all it is quite clear that something is not working, when you get mangled DNS behaviour you create a potentially intermittent problem.

I can not argue about TCP and DNS.
At least we understand what the firmware does.
Thanks for the link to Infoblox

Just an FYI for the community: While investigating this, I tried to log outbound UDP DNS requests on port 53 and came up empty. It turns out that when DNS service forwarding is enabled, there is no logging. DNS service forwarding is the option that forces all client devices to use the legacy DNS servers configured in the router. When DNS service forwarding is disabled, then these requests are logged.