What's new

Does DNSFilter Support DoT?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

HarryMuscle

Senior Member
Does the DNSFilter functionality support using DoT to connect to the DNS server? If it does, do I simply enter the DoT URL instead of the IP in the IPv4 field? Or is using IP the only option?

Thanks,
Harry
 
No. If the router is set to use DoT just let the clients use the router for DNS.
 
Does the DNSFilter functionality support using DoT to connect to the DNS server? If it does, do I simply enter the DoT URL instead of the IP in the IPv4 field? Or is using IP the only option?
Not technically possible, since DNS Director merely redirects port 53 queries to another regular DNS server. Redirecting to a DoT server would fail since part of the idea behind DoT is to prevent such DNS hijackings from occurring, through the TLS authentication.
 
@RMerlin, but what happens then when DNS Director is set to router and the router is using DoT?

1673305107567.png


1673305022399.png
 
@RMerlin, but what happens then when DNS Director is set to router and the router is using DoT?

View attachment 47019

View attachment 47018
That's where I got confused also. Based on Merlin's answer though it seems that the DNSFilter functionality doesn't actually use the router as the DNS server which then queries the DNSFilter DNS server but instead simply passes the query along to the DNSFilter DNS server. Too bad, I was hoping the DNSFilter functionality actually worked like the regular router DNS functionality but simply used a different DNS server.
 
Not technically possible, since DNS Director merely redirects port 53 queries to another regular DNS server. Redirecting to a DoT server would fail since part of the idea behind DoT is to prevent such DNS hijackings from occurring, through the TLS authentication.
Any chance of ever changing the DNSFilter functionality to work like the regular router DNS functionality where a local DNS server runs on the router which then queries the specified DNS server on the internet?
 
Any chance of ever changing the DNSFilter functionality to work like the regular router DNS functionality where a local DNS server runs on the router which then queries the specified DNS server on the internet?
Well, it does that now.DNS Filter is the old name. It is now DNS Director.

If a client tries to use a DNS resolver other than the one(s) assigned by your DHCP, and DNS Director is enabled to Router, DNS Director intercepts the query and send it to Dnsmasq on the router. Dnsmasq then forwards it to an upstream DNS resolver. If DoT is enabled on the router, Dnsmasq send the query to Stubbyagain on the router, which encrypts the query and forwards it to an upstream resolver. The reverse route is done for returning queries.

DNS Director can send to custom resolvers but the queries are not encrypted. using custom resolvers may not be a good idea as only one can be assigned per client and if that resolver goes down the internet query will fail. Much safer to use at least to resolvers in the router WAN or two or more in DoT.
 
Thanks, @bbunge, It clarified my previous question. I have another one though: are the following settings to force clients use router's DNS redundant or complementary?

1673312473128.png


1673312519099.png
 
Thanks, @bbunge, It clarified my previous question. I have another one though: are the following settings to force clients use router's DNS redundant or complementary?

View attachment 47021

View attachment 47022
Each does something different. DNS Director has been explained. Prevent client auto DoH is supposed to stop browsers, Firefox for one, from enabling DoH when the browser is set up for the first time, as I understand it. My experience with that is less than successful so I check the browser after I start using it. It does not stop someone from turning DoH on in the browser settings.
 
Well, it does that now.DNS Filter is the old name. It is now DNS Director.

If a client tries to use a DNS resolver other than the one(s) assigned by your DHCP, and DNS Director is enabled to Router, DNS Director intercepts the query and send it to Dnsmasq on the router. Dnsmasq then forwards it to an upstream DNS resolver. If DoT is enabled on the router, Dnsmasq send the query to Stubbyagain on the router, which encrypts the query and forwards it to an upstream resolver. The reverse route is done for returning queries.

DNS Director can send to custom resolvers but the queries are not encrypted. using custom resolvers may not be a good idea as only one can be assigned per client and if that resolver goes down the internet query will fail. Much safer to use at least to resolvers in the router WAN or two or more in DoT.
Just to clarify, are you saying that with DNS Director I can do the following:

- router configured with ISP DNS over DoT which majority of clients use
- DNS Director configured to send one client to AdGuard DNS servers over DoT

(that's just an example, I'm not actually sure if AdGuard even supports DoT)

Or can DNS Director only send clients to non DoT DNS servers, which would mean it basically does exactly what DNSFilter does which is forward the DNS request and not intercept it like the main DNS functionality on the router does.

Thanks,
Harry
 
Or can DNS Director only send clients to non DoT DNS servers, which would mean it basically does exactly what DNSFilter does which is forward the DNS request and not intercept it like the main DNS functionality on the router does.
DNS Director is the same as DNSFilter. Only the name was changed, nothing else.

DNS Director only works for "normal" port 53 DNS requests. It will however block DoT (port 853) client requests in an attempt to force them to fall back to using port 53. DNS Director cannot prevent DoH.
 
DNS Director is the same as DNSFilter. Only the name was changed, nothing else.

DNS Director only works for "normal" port 53 DNS requests. It will however block DoT (port 853) client requests in an attempt to force them to fall back to using port 53. DNS Director cannot prevent DoH.
Thanks for clarifying. What I meant by this comment:


was if there was any chance that DNS Filter / Director will be changed to intercept DNS queries just like the main DNS functionality does with DNSMasq and then send the optionally encrypted query to different DNS upstream servers depending on the rules set by DNS Filter / Director ... in other words, work like the main DNS router functionality instead of just forwarding requests.
 
... to intercept DNS queries just like the main DNS functionality does with DNSMasq ...
Apart for DNS Director, the router/dnsmasq doesn't intercept anything. Clients choose to send (or not) their requests to the router.

... and then send the optionally encrypted query to different DNS upstream servers depending on the rules set by DNS Filter / Director ... in other words, work like the main DNS router functionality instead of just forwarding requests.
If you're asking whether the router can forward individual client requests to other upstream DoT servers, rather than just that which is set on the WAN page, based on DNS Director rules the answer is no. This was discussed when DoT was first being implemented on the router. It would require a separate instance of Stubby to be running for each upstream DoT server. That is not practical given the limited capabilities of the router.
 
Last edited:
Apart for DNS Director, the router/dnsmasq doesn't intercept anything. Clients choose to send (or not) their requests to the router.


If you're asking whether the router can forward individual client requests to other upstream DoT servers, rather than just that which is set on the WAN page, based DNS Director rules the answer is no. This was discussed when DoT was first being implemented on the router. It would require a separate instance of Stubby to be running for each upstream DoT server. That is not practical given the limited capabilities of the router.
Thanks, that's exactly what I was trying to ask. BTW, there's a new tool from the Windscribe/ControlD people that would be a great replacement and enhancement to DNSFilter/Director. Here's the link: https://github.com/Control-D-Inc/ctrld

It's basically a command line version of DNSFilter/Director (plus a bit more) but with full support for DoT/DoH.
 
Thanks, that's exactly what I was trying to ask. BTW, there's a new tool from the Windscribe/ControlD people that would be a great replacement and enhancement to DNSFilter/Director. Here's the link: https://github.com/Control-D-Inc/ctrld

It's basically a command line version of DNSFilter/Director (plus a bit more) but with full support for DoT/DoH.

Doubt that is going to get added to merlin unless Asus changes to it.

To clarify a bit what has been said already:

Set DNS Director to on and mode to "router". That will force any client doing a DNS lookup on port 53 to use the router's DNS, no matter what IP they try to lookup to. It can be confusing as an nslookup to 8.8.8.8 will still say it is coming from google, but really it is coming from the router. It just replaces the payload of the response. You can consider DNS director a totally independent feature from whatever you're doing on your WAN page, but when used in conjunction (by setting it to router) they two work together to accomplish what you want.

On your WAN DNS set up whatever you want to be used for DNS, including the servers, DNSSEC, DOT, etc. Optionally you can enable "prevent auto DOH" but that is only for a few scenarios. A client can still set up their own DOH or DOT and bypass your router, no way around that other than installing a blacklist of those servers (and that won't be 100% either).

The two steps above will force all client requests for port 53/dns to use whatever is set on the WAN page for DNS (even though they won't know it).

Make sure your DHCP server settings have no DNS server specified and have the "advertise router's IP" set to "yes".

Then optionally you can set exceptions on the DNS director page. If you set a client to "no filtering", it will use whatever is configured on the client (whether learned from DHCP or statically set). In my case I leave my own PCs set to "no filtering". They still get the router IP from DHCP and use the settings on the WAN page normally, but if I ever want to lookup against another DNS server for testing, I can. Or you can set kids PCs to use an adult filtering service instead of the regular WAN DNS, etc. But those PCs will NOT get DOT or other security filters from the WAN page, they will bypass those settings on the WAN completely when you specify anything other than "router" on the DNS director page.

My router seems to slow down a lot with DNSSEC and/or DOT enabled (older AC1900 router) so I don't even have those on.

Personally I don't think they're all that useful anyway

DNSSEC just re-validates what your DNS service is already doing (most of them do DNSSEC already). It is somewhat pointless to a recursive DNS server. It doesn't stop that server from getting hacked and returning you invalid replies, so really just extra latency and load on your router for no reason. If you really want to do DNSSEC you need to set up a DNS server on your network that looks up directly to the root DNS and resolves directly.

DOT is for hiding your lookups from your ISP, but not like they can't see what site you go to right after doing that lookup. In some countries where sites are filtered using DNS, DOT/DOH is useful, but not really an issue in the US, and those countries probably block the IPs of those sites anyway. Plus so many other things are tracking you, what's one more? If I truly want what I'm doing hidden I use a VPN. But I'm not doing anything that is going to get me flagged on any watch lists anyway.

Mainly I just wanted an extra line of protection for friends and neighbors that I let use my wifi that aren't as careful as I am (and also IOT devices as I don't fully trust them), and just in case I'm not paying attention and click a phishing or malicious link (or those times when an ad on a website turns out to be malicious and redirects to a bad site even if you don't click it). Nothing is going to block it all but between browser protection, antivirus, AiProtection, and DNS filter, hopefully will catch most.
 
Last edited:
All you want is to use a different encrypted DNS server for some clients.

It's possible, but that's outside the scope of what DNS Filter/Director does, it just redirects regular DNS requests at the iptables level.

This is how DNS Director works:
Code:
Client 1 DNS requests --> Router --> dnsmasq --> stubby --> Encrypted 8.8.8.8
Client 2 DNS requests --> Router --> iptables --> Unencrypted 9.9.9.9

The first line is how encrypted DNS works in router, and the second is the special changes made by DNS Director for client 2.


But you need to implement it like this:

Run a new encrypted DNS client, such as stubby, and have the new stubby process listen on the new address.

Code:
Client 1 DNS requests --> Router --> dnsmasq --> stubby1 --> Encrypted 8.8.8.8
Client 2 DNS requests --> Router --> dnsmasq --> stubby2 --> Encrypted 9.9.9.9

dnsmasq can specify different upstream DNS servers for different clients, we only need to specify the loopback addresses of different stubby listeners.

PS: I haven't tried multiple processes running stubby so I don't know if it works, but you can always install other encrypted DNS clients via entware.
 
Last edited:
How does it do that?
dnsmasq allows you to group and serve different DNS servers to different DHCP clients.

Here is an example:

But that's not the point, if dnsmasq can't do the job, you can simply use iptables to forward the client's regular DNS requests to the local loopback address that stubby2 listens on, or even easier, use it directly in DNS Director to forward to the listening address of stubby2 (I'm not sure if the GUI will allow you to use addresses like 127.0.1.1).


The most important thing to achieve what the OP wants is to run multiple encrypted DNS clients, (whether stubby supports running multiple instances and loading multiple different configurations, I'm not sure, I haven't tested it).
 
Last edited:
dnsmasq allows you to group and serve different DNS servers to different DHCP clients.
Ok, I understood that as a function of DHCP. I thought you were suggesting there was a new way in dnsmasq 2.88 to specify upstream servers based on incoming client IP within the DNS function.
 
PS: I haven't tried multiple processes running stubby
whether stubby supports running multiple instances and loading multiple different configurations, I'm not sure

Whether stubby can run multiple instances has been discussed in the OpenWRT community.

In short, this is hard to do on Merlin.

you can use
DNSMASQ+STUBBY and DNSMASQ+UNBOUND are implemented to use different encrypted DNS for different clients.

The above DNSMASQ can be replaced by IPTABLES or DNS DIRECTOR ,and UNBOUND can be replaced by DNSCRYPT or ADGUARD.


Code:
Client 1 DNS requests --> Router --> dnsmasq --> stubby --> Encrypted 8.8.8.8
Client 2 DNS requests --> Router --> dnsmasq/iptables/dnsdirector --> unbound/dnscrypt/adguard --> Encrypted 9.9.9.9


specify upstream servers based on incoming client IP within the DNS function
No, this is the first time I've heard of this feature, and it sounds like it will also implement the need for different clients to forward to different upstream DNS servers.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top