What's new

Multiple DNS over TLS (DoT) per device or network?

  • 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!

RT-N66U

New Around Here
I currently have a DoT server configured on my RT-AC68U (Merlin) router's WAN, and all clients on my network are using it without any issues. However, I now need certain clients to use a different DoT server. As configuring DoT directly on these devices is not possible, I need help setting up a script or some method to configure a different DoT server on the router, and assign certain clients to use this server.

My desired outcome is to have:
  • DoT Server 1 (already configured on WAN and used by many clients)
  • DoT Server 2 (assigned to specific devices, MAC addresses, Wi-Fi networks, etc.)
I would appreciate any help or guidance on how to achieve this.
 
Are you really running DoT on your WAN interface? That doesn't sound like a good idea if your WAN is connected to the internet.

To run another DoT server you would need to run another instance of Stubby. This is not supported by the router. The possibility was discussed recently but IIRC the built-in version of Stubby doesn't allow multiple instances of itself.
 
This is possible, I provided a way to do it a few days ago, and I tested it this past weekend. the good news is that the stubby built into the router supports multi-instance, which means that multiple DoT instances can be run simultaneously to provide different upstream DoT servers for different devices. the only problem to solve is that dnsmasq assigns different upstream servers to different devices, I haven't had time to do this yet, but, I'd love to try it out when I have time, as it could significantly enhance the DoT and DNS Filter/Director functionality in current routers, once I have time I will try.




Are you really running DoT on your WAN interface?
I don't think the OP meant to expose it to the internet.
 
To run another DoT server you would need to run another instance of Stubby. This is not supported by the router. The possibility was discussed recently but IIRC the built-in version of Stubby doesn't allow multiple instances of itself.
When a router is running multiple instances of stubby, the second instance of stubby must be tricked into thinking there are no other instances, in short, delete the stubby pid file under /var/run/.
But considering the importance of this file to restart stubby1, I am preparing to write a script to automatically replace the pid file.

But all this I can only wait until the weekend to try, the only thing I can do right now is provide a direction for anyone who wants to do this.
 
I did exactly what you are looking for using this utility from ControlD
and a script that rewrites the iptable rules in the DNSFILTER chain to reroute clients to this utility. My setup basically adds DoT support to the DNS Filter/Director functionality which is one way of accomplishing what you are after. Since there was some confusion as to whether multiple versions of stubby can be run to do this and because I was already familiar with ControlD that utility seemed like the perfect choice. Plus one instance supports as many resolvers and servers as you want.

I'll try to post my actual script later today when I'm at a computer.
 
I did exactly what you are looking for using this utility from ControlD
and a script that rewrites the iptable rules in the DNSFILTER chain to reroute clients to this utility. My setup basically adds DoT support to the DNS Filter/Director functionality which is one way of accomplishing what you are after. Since there was some confusion as to whether multiple versions of stubby can be run to do this and because I was already familiar with ControlD that utility seemed like the perfect choice. Plus one instance supports as many resolvers and servers as you want.

I'll try to post my actual script later today when I'm at a computer.
In my previous tests, I found that a fatal flaw of DNS Filter/Director is that it cannot forward to local addresses, such as 127.0.0.1, DNS Filter/Director will only create rules in NAT, and then forward the rules to the modem of the upstream ISP rather than a service running locally.


Maybe @RMerlin can take a look, because filling in the local address in DNS Filter/Director will lead to wrong forwarding.
 
In my previous tests, I found that a fatal flaw of DNS Filter/Director is that it cannot forward to local addresses, such as 127.0.0.1, DNS Filter/Director will only create rules in NAT, and then forward the rules to the modem of the upstream ISP rather than a service running locally.


Maybe @RMerlin can take a look, because filling in the local address in DNS Filter/Director will lead to wrong forwarding.
Wrong forwarding in what way? I manually change the iptable rules to point to the router's LAN IP address and a certain port that's running the ctrld utility and everything seems to be working but now you got me curious. Any details you can share about the wrong forwarding you're referring to would be much appreciated.
 
Wrong forwarding in what way? I manually change the iptable rules to point to the router's LAN IP address and a certain port that's running the ctrld utility and everything seems to be working but now you got me curious. Any details you can share about the wrong forwarding you're referring to would be much appreciated.
You can do a test like this:

Fill in DNS Filter/Director with 127.0.1.1 (the stubby listening address on the router, which will reply to DNS requests), and then specify a device use this address, and then the device will not get any DNS returns.

That's because DNS Filter/Director adds local address to NAT.
Code:
iptables -v -t nat -L -n --line-numbers
 
You cannot DNAT to 127.0.0.0/8 (well you can but it won't work) because that is the loopback block and is therefore never routed***. You would have to use an address like 192.168.1.1.

*** Technically you could enable it for LAN clients by issuing this command but it's not recommended from a security perspective.
Code:
echo 1 > /proc/sys/net/ipv4/conf/br0/route_localnet
 
Last edited:
You cannot DNAT to 127.0.0.0/8 (well you can but it won't work) because that is the loopback block and is therefore never routed. You would have to use an address like 192.168.1.1.
My problem was the opposite, it was routed instead of loopback to the router itself.

But 192.168.50/1.1 is correctly answered by the local service instead of being routed to the ISP's modem.


You can do a test if you want, just look in iptables to see what's going on.
 
My problem was the opposite, it was routed instead of loopback to the router itself.

But 192.168.50/1.1 is correctly answered by the local service instead of being routed to the ISP's modem.


You can do a test if you want, just look in iptables to see what's going on.
Sorry, I can't follow what you're describing. You'll have to give an example of your iptables rule that doesn't work.

P.S. See the edit I made to my previous post in case that's relevant.
 
Here's the solution I came up with that would allow the OP to do what they are looking for (assign specific DoT DNS servers to certain MAC addresses):

 
Sorry, I can't follow what you're describing. You'll have to give an example of your iptables rule that doesn't work.
In fact it works so well that it shouldn't be routing 127.0.0.0/8 to my modem.


Above I wrote the example (#8), when 127.0.1.1 is filled in, the router stupidly asks the modem on the WAN for a DNS response for that IP.

And that IP has a local service listening and replying on the router, if the router isn't routing it, why isn't the local service replying?
 
In fact it works so well that it shouldn't be routing 127.0.0.0/8 to my modem.


Above I wrote the example (#8), when 127.0.1.1 is filled in, the router stupidly asks the modem on the WAN for a DNS response for that IP.

And that IP has a local service listening and replying on the router, if the router isn't routing it, why isn't the local service replying?
I've just tried this and it's behaving as expected. As explained in post #9 you won't get a reply. That's not because its routing the traffic out the WAN interface, it's because the traffic is being ignored because it's regarded as martian.

Code:
route_localnet - BOOLEAN
    Do not consider loopback addresses as martian source or destination
    while routing. This enables the use of 127/8 for local routing purposes.
    default FALSE
 
I've just tried this and it's behaving as expected. As explained in post #9 you won't get a reply. That's not because its routing the traffic out the WAN interface, it's because the traffic is being ignored because it's regarded as martian.

Code:
route_localnet - BOOLEAN
    Do not consider loopback addresses as martian source or destination
    while routing. This enables the use of 127/8 for local routing purposes.
    default FALSE
You're right, I just didn't think the router dropped it.

Because I think when there is a service in the router listening to that address, there will be a reply there.

Thanks for the help, do you have a way to get the router's stubby to reply to that request? Or what should I do to redirect DNS traffic to stubby?

Specifically, the second stubby instance, since I'm having stubby2 listening on 127.0.2.1. so I need to create a rule using DNS Filter/Director to redirect DNS traffic to 127.0.2.1, but when doing so, it gets dropped. In router's SSH nslookup www.google.com 127.0.2.1 works fine.
Any suggestions?
 
You're right, I just didn't think the router dropped it.

Because I think when there is a service in the router listening to that address, there will be a reply there.

Thanks for the help, do you have a way to get the router's stubby to reply to that request? Or what should I do to redirect DNS traffic to stubby?

Specifically, the second stubby instance, since I'm having stubby2 listening on 127.0.2.1. so I need to create a rule using DNS Filter/Director to redirect DNS traffic to 127.0.2.1, but when doing so, it gets dropped. In router's SSH nslookup www.google.com 127.0.2.1 works fine.
Any suggestions?
Can you not have stubby listen on the br0 interface, but on a different port?
 
Can you not have stubby listen on the br0 interface, but on a different port?
Thanks for the reply, but I don't know how to do it, because there is only listening address in stubby's config file.

Code:
# cat /etc/stubby/stubby.yml
...
listen_addresses:
- 127.0.1.1@53
...

I just create the second stubby.yml, and then modify the listening address inside.


For queries made using SSH, it works fine, but when forwarded through the DNS Filter/Director, the request is dropped. I guess because that forward should not exist in the NAT rules.
 
Code:
listen_addresses:
  - 192.168.1.1@5300
Seems to work for me:
Code:
# netstat -nlp | grep stu
tcp        0      0 192.168.1.1:5300        0.0.0.0:*               LISTEN      7814/stubby
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      7123/stubby
udp        0      0 127.0.1.1:53            0.0.0.0:*                           7123/stubby
udp        0      0 192.168.1.1:5300        0.0.0.0:*                           7814/stubby
 
...
Seems to work for me:
...
Very bright idea!

I don't know if I put 192.168.1.1 in the DNS Filter/Director, it will correctly forward to the local service instead of the modem. I'll look into this tonight, looks promising, thank you.


EDIT:
Wait a minute, but there's a problem with this, it means the port will be open to the LAN, no? What if I don't want to do this? I just want the router to handle it internally.
 
I don't know if I put 192.168.1.1 in the DNS Filter/Director, it will correctly forward to the local service instead of the modem.
Probably not without some further modification. I'd guess DNS Filter/Director is hard-coded to use port 53.

EDIT:
Wait a minute, but there's a problem with this, it means the port will be open to the LAN, no? What if I don't want to do this? I just want the router to handle it internally.
Surely that's the whole point of doing this. You said you want LAN clients to be able to access it. Otherwise you run into the problem Dave mentioned where you have to run a second instance of dnsmasq or some other DNS forwarder on the router.
 

Similar threads

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