DNS-over-TLS - disable possibility for regular DNS requests from asus router

[asus86user]

Hi,

Long time reader of these forums and grateful for all the advice. Running RT-AC86U smoothly.

Configured DNS-over-TLS with all DNS traffic from LAN intercepted and answered by Router. This works flawlessly. (Got answer back for a "dig nas.lan @1.1.1.1 that only exists on my lan and couldn't have been answered but the asus router.)

I just wanted to achieve something extra: block all outgoing regular DNS traffic (port 53) from my router.
Unsuccessful so far. I tested with running on the router as admin (ssh) "dig linux.org @1.1.1.1" that I expect to timeout, while "dig linux.org" should resolve. But they both resolve.
I tried:
- Network Services Firewall: did nothing (as router address is not seen as part of the LAN maybe?)
- "iptables -I OUTPUT -s routerip -p udp --dport 53 -j DROP" (and also for -p tcp). Didn't work.

Any advice?

Thanks,
Chris

 

[bbunge]

LAN/DNS Filter set filter mode to Router. Merlin Firmware only

 

[asus86user]

Thank you for your super quick reply!

I have the LAN/DNS Filter set to Router. And behaviour is as expected.

Router is querying upstream DoT, and this is working as expected too. I just want to avoid that -for whatever reason- my router starts falling back to query upstream servers via regular DNS (port 53).

 

[asus86user]

Hi,

It seems answers presented themselves after having posted this question and spending quite some time yesterday.

So for anyone with a similar request:
1) find your WAN interface via ifconfig
2) verify traffic with "tcpdump -ni [your WAN interface] -p port 53 or port 853"
3) block regular DNS with
"iptables -I OUTPUT -o [your WAN interface] -p udp --dport 53 -j logdrop"
"iptables -I OUTPUT -o [your WAN interface] -p tcp --dport 53 -j logdrop"

My error was not using the WAN interface/IP.
Chris

 

[RMerlin]

Don`t do that. Your router needs access to regular DNS servers before it can get DoT up and running. As suggested earlier, DNSFilter is the proper way to handle this.

 

[asus86user]

Trying to understand:
- DNSFilter: Router > for all LAN devices : working as expected (DNS requests intercepted and answered by Router)
- Router itself needs DNS before starting DoT.

But how to avoid any DNS port 53 leakage on the Router (WAN interface) afterwards?

My config (see below) doesn't have a regular DNS server configured (only DoT) and is running quite well for the past months.


Config:
[WAN]
My DoT config contains IP addresses (and TLS hostnames) with ports 443 and 853.
Connect to DNS server automatically: No
DNS Server1 and Server2: Empty

So I thought DoT started without regular DNS...

 

[RMerlin]

You need to define WAN DNS, don`t leave them empty. For TLS to work, you need an accurate time clock. Routers have no battery-backed up clocks, therefore they need Internet access to connect to an NTP server to sync their clock before TLS can become usable. For this the WAN interface needs a working nameserver.

 

[sbsnb]

You need to define WAN DNS, don`t leave them empty. For TLS to work, you need an accurate time clock. Routers have no battery-backed up clocks, therefore they need Internet access to connect to an NTP server to sync their clock before TLS can become usable. For this the WAN interface needs a working nameserver.

My setup has no WAN DNS.

I run dnscrypt-proxy and have a "hack" in my /jffs/configs/dnsmasq.conf.add:

# Allow NTP to work before DNSCrypt-proxy is up and running
server=/us.pool.ntp.org/8.8.8.8

It's been working OK for several years. I think we had a discussion about this a while back. Not saying it's the "right" way, but it works.

 

[RMerlin]

and have a "hack" in my /jffs/configs/dnsmasq.conf.add:

That user most definitely does not have that "hack" in place however.

 

[sbsnb]

That user most definitely does not have that "hack" in place however.

Agreed. One of the great things about good software is there are usually multiple ways to go about something, each with its own set of trade-offs. I wanted to inform OP that there was another way, too. The reason I went about it in this way is that I didn't want the router to even "know" about any DNS servers for general queries other than dnscrypt-proxy. Queries can't even inadvertently go to the wrong DNS if there is no "wrong" DNS set up.

 

[Dan567]

I am using NextDNS installed in Merlin to handle the DNS. I assume from this conversation that I should set the LAN/DNS Filter mode to Router. Is that correct? I noticed that the settings for Custom DNS 1,2,3 are set to 8.8.8.8. Should I leave them set to that? I am not sure when they are used if I am using NextDNS.
Thanks

 

[gerardr]

Hi! Is it weird, though, that both stubby and dnsmasq have both supposedly opened port 53 on localhost under both UDP and TCP? Presumably stubby, since it runs later, wins, but normally, it would fail its open since dnsmasq already had it.

 

[asus86user]

Thanks to RMerlin for this great firmware and his appreciated advice to newcomers to this forum. And also thank you to sbsnb for pointing me in the right direction.

I tested some more (after business hours) and have been running this for the last week without issues. So in order to give back to the community:

1) DNS is required for ntp sync prior to being able to establish a TLS connection (for DoT to work). Trying IP addresses iso FQDN didn't really work. I still got some errors. Therefore added 'hack' suggested above. (server=/ntp.org/1.1.1.1 in /jffs/configs/dnsmasq.conf.add)

2) Prevented all traditional DNS traffic except for destination 1.1.1.1 by adding this to /jffs/scripts/firewall-start (ppp0 is my WAN interface):

iptables -I OUTPUT -o ppp0 ! -d 1.1.1.1/32 -p tcp -m tcp --dport 53 -j logdrop   
iptables -I OUTPUT -o ppp0 ! -d 1.1.1.1/32 -p udp -m udp --dport 53 -j logdrop

3) Make sure the DoT server list contains a TLS port (853/443) for every line. Some of my DoT servers also respond to queries on port 53. Though it should not make a difference as default for tls_port is 853. (Nevertheless I still got traffic on port 53 even with Strict profile prior to this config.)

[Tip: use external search engine because the searchbox on this site would not allow me to search for acronyms like DoT, DNS etc as too short. Otherwise I would have found the related DoT setup but still seeing traffic on port #53 ]