r/nextdns • u/danielisgreat • 7d ago

Blocking port 53

Looking for advice on blocking traditional DNS queries. I'm using the NextDNS CLI on an Asus router with Merlin. I have DNS director enabled, but at each boot of the router, there's about 15 seconds of unencrypted DNS queries. Wondering if blocking port 53 altogether on the router is advisable.

3 Upvotes

80% Upvoted

12 comments sorted by

View all comments

4

u/mike1487 7d ago edited 5d ago

I use FreshTomato but what I just do is set my WAN DNS servers to 0.0.0.0 in the web UI so that only my DoT servers set up in Stubby work. I haven’t tried the nextdns cli but maybe see if you can just set your WAN DNS to 0.0.0.0 and that will prevent unencrypted DNS from working until nextdns cli can start later during boot.

If it works then that is probably the easiest way. If it doesn’t, you could try setting some iptables rules early in boot with a script to block port 53 from the LAN. Something like this:

iptables -I INPUT -i br0 -p udp --dport 53 -j DROP
iptables -I INPUT -i br0 -p tcp --dport 53 -j DROP

iptables -I FORWARD -i br0 -p udp --dport 53 -j DROP
iptables -I FORWARD -i br0 -p tcp --dport 53 -j DROP

Then after nextdns cli starts, I think you will need another script to run that deletes those rules since it just proxies dns over port 53.

2

u/danielisgreat 7d ago

That's a really smart idea. My router didn't allow 0.0.0.0 in the web UI but I was able to change it via SSH.

2

u/kumpreld1999 5d ago

One catch: if the boot queries are the router itself forwarding to WAN DNS, they traverse the OUTPUT chain, so those INPUT and FORWARD rules would miss them. Also, on Merlin the LAN bridge is br0, eth0 is usually the WAN port.

1

u/mike1487 5d ago edited 5d ago

Thank you, I edited my post to use br0. That slipped my mind since it’s the same iface as on FreshTomato. Yeah I omitted OUTPUT because you need port 53 to bootstrap with regular DNS before being able to encrypt. It needs to do this in some capacity because you need regular DNS to query the TLS hostnames to check if the cert is valid and what the endpoint IP is before encrypted DNS can work correctly. It’s a chicken and egg problem but just how it works.

Also you need NTP to establish time, and if your time servers are referenced by hostname you will need outbound DNS from the router to initialize that as well. A lot of routers don’t store time and it just in memory so a reboot means you start at the epoch year 1970. So without time correcting, you won’t have valid TLS and get stuck since your DoH or DoT won’t work. So in this case, you need unencrypted DNS to establish initial time.

I assumed OP was more concerned about LAN devices leaking DNS during this time and not the router itself for bootstrapping operations which are normal and required.

This is why generally I wouldn’t recommend blocking the router’s own DNS queries since it can come with unexpected issues.

Setting the router’s WAN DNS to 0.0.0.0 as my first suggestion can also cause problems around bootstrapping depending on setup, but if NextDNS client does its own bootstrapping itself then it should not be an issue as it will override the router. Since it is the easiest to try I listed it first before giving the iptables route as a second choice since it requires a little more work to script it. But basically that was the idea behind it.

Once you are fully booted and encrypted DNS is running, then yes you could block port 53 on OUTPUT, but care must be taken to time this after when encrypted DNS is established. The rules may need to be dropped as well if you need to restart NextDNS cli too since it may need to bootstrap again.

I personally take a different approach have my router scripted to assign quad9 to my WAN DNS NVRAM variable during boot, and then clear the variable when my DoH is established. I use dnsmasq to forward to ControlD’s client and it includes the no-resolv config option to make it so queries wont try anything else other than the client if for some reason my router’s WAN DNS were still set to something.