Forcing DNS for Roku/smart devices(HTTPS-DNS-PROXY)

I am running HTTPS-DNS-PROXY forcing ports 53,853 to port 5053.

I was doing some wiresharking and saw one of our roku's is hard coded for google dns 8.8.8.8

Is there a reason that this is not being forced through openwrt's HTTPS-DNS-PROXY?

You need to set dnat rule to force its hand.
https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns

1 Like

This is already configured by HTTPS-DNS-PROXY. My firewall port forwards show the following

Could be https aka DoH fallback. You need to set canary trap like /use-application-dns.net/

The only DoH server set is cloudflare. I removed the google entry that came default.

do you mean on the client device(roku)? As in it's querying 8.8.8.8 over 443/https?

Yes, like not dns. Because dnat rule would divert any dns request to your server.

It will never work. Port 853 is used by DoT and downgrading it to DNS@53 will not work.

Likely serves thepurpose and looks sophisticatinated

I thought so too but it doesn't. Luci-app-adblock offers ports 53, 853, 5353 in its "Forced ports" (it just adds those ports in "Firewall - Port Forwards"), I used tcpdump actually to test it and it always fails. It is clearly a bug, only port 53 can be hijacked this way.

1 Like

Older applications could fall back to unencrypted DNS, but in reality this rule is more or less equivalent to a blocking rule either forcing the application to fall back to plain DNS or have no resolution.
So in this respect it serves its purpose, I think.

3 Likes

What is the name of this application that supports downgrade of DoT@853 to DNS@53? I wish to test it.

... it is an obvious bug in implementation of DoT protocol.

My dns hijack rule drops anything that is destined for ports 53,853 and is not my pi-hole. Then banIP handles blocking all DoH bound requests via IP. The android devices on my network don't resolve their "google connectivity" checks and always complain about "no network connection" even when the browser is playing online media.

1 Like

This is the default implementation of https-dns-proxy

I just tested, and any client set to use any other DNS does indeed still go through my https-dns-proxy, but the roku is somehow still forcing its hardcoded DNS even with the forward rules...

I need to reopen this one for assistance.

I am running both DoH and adblock.

it appears adblock is handling the forcing of local DNS.

I still have a roku device making port 53 DNS queries to 8.8.8.8 and bypassing my attempted DNS Hijacking.

I'm getting confused a bit. DoH is running on 5053 and forcing 53, adblock is forcing all dns requests to the local dnsmasq server running on openwrt. How is this device making requests to port 53 without my rules forcing it to my DoH?

I removed all of the adblock forwards and replaced it with one forward for port 53 as described in the DNS Hijacking wiki

https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns

Sigh... it is not resolved. I thought it was, but I see the roku still making requests to google via DNS. Just from a purely theoretical perspective, I would like to know how it's possible that port 53 is not being hijacked on this device.

Anyone have any ideas?

How are you testing this? ELIM5.

Also, between two packages which can manage firewall and VLANs on your router, you might have to post your adblock, firewall, https-dns-proxy and network configs to get a reasonable response.

Generally speaking, with the default OpenWrt install, using https-dns-proxy with force_dns enabled is enough to intercept Roku's DNS requests, at least with my Roku device (which may not be running the latest Roku OS tho).

1 Like

The way that i'm testing:

I run wireshark and filter all requests made on port 53.
Wait some time... most requests go through my router's dns.
Then the roku's will somehow be making calls to dns.google (8.8.8.8) via port 53.

I have the default DNS hijacking settings configured within https-dns-proxy - I have confirmed they are applied. Adblock configured some forced port rules, but I have removed them for simplicity.

This is my DNS-Intercept rule as well.

                meta nfproto ipv4 tcp dport 53 counter packets 28 bytes 1680 redirect to :53 comment "!fw4: DNS-Intercept"
                meta nfproto ipv4 udp dport 53 counter packets 7249 bytes 502727 redirect to :53 comment "!fw4: DNS-Intercept"
        }

There have been a few posts on this, that's the expected behaviour as far as I remember, the sniffer sees the request to the hardcoded server, but it doesn't see the request being mangled/hijacked and resolved by the router, which still happens.

I guess one way of testing it is to change the router's dns setting so that resolution would fail, hard-restart Roku and ensure that it can't resolve anything either.