Question about DNS filtering

[ColinTaylor]

It could probably be implemented on my fork
- Would have to double check if the stubby config supports multiple listening ports to be able to support both router and DNSFilter queries
- Only for ARM routers (need to nat to localhost which isn't supported on the MIPS kernel, I had to patch the ARM kernel to support it and you need to activate it with a kernel write to /proc)
- Those clients would be like any DNSFilter client, and couldn't use things like Diversion

Hi John. This seems to work.

As you predicated it didn't work when I tried to DNAT the queries to 127.0.0.1. I didn't pursue this any further and instead just DNATed to 192.168.1.1:5453 instead. This required one extra line in stubby.yml:

listen_addresses:
  - 127.0.0.1@5453
  - 192.168.1.1@5453

# netstat -npa | grep stubb
tcp        0      0 192.168.1.1:5453        0.0.0.0:*               LISTEN      8282/stubby
tcp        0      0 127.0.0.1:5453          0.0.0.0:*               LISTEN      8282/stubby
udp        0      0 192.168.1.1:5453        0.0.0.0:*                           8282/stubby
udp        0      0 127.0.0.1:5453          0.0.0.0:*                           8282/stubby

DNSFilter's DNAT rule had to be duplicated for both tcp and udp as that is a syntax requirement when changing the port:

# iptables-save | grep DNSFILTER
:DNSFILTER - [0:0]
-A PREROUTING -s 192.168.1.0/24 -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -s 192.168.1.0/24 -p tcp -m tcp --dport 53 -j DNSFILTER
-A DNSFILTER -p udp -m udp -m mac --mac-source 94:DE:80:C5:79:52 -j DNAT --to-destination 192.168.1.1:5453
-A DNSFILTER -p tcp -m tcp -m mac --mac-source 94:DE:80:C5:79:52 -j DNAT --to-destination 192.168.1.1:5453

Other than that it worked fine. I checked it was working by looking in the log and using Cloudflare's website.

Considerations:
1. No changes were made to dnsmasq.conf.
2. Obviously for testing I was having to run Stubby manually.
3. This does depend on Stubby having previously been configured through the WAN settings at least once before which might not be the case if the user is only using it for DNSFilter.
4. The stubby.yml file does not normally exist if it hasn't been enabled on the WAN.
5. Stubby is now listening on the LAN interface as well as loopback. I don't see this as problem particularly as dnsmasq does the same.
6. The DNSFilter selection for "DoT" (or whatever it will be called) needs to take into account that it is redirecting to an IP/port instead of just an IP.
7. This assumes that there is only going to be one Stubby instance running on the router which has a shared configuration for the WAN and DNSFilter. Having a choice of different DoT servers similar to how DNSFilter currently works would be too complicated IMHO as it would require running multiple instances of Stubby.

 

[DroidST]

Perhaps for future proofing, add option under DNSFilter Global Filter Mode for DoT (and/or DoH) then select Provider/Server: Cloudflare/1.1.1.1, Quad9 and etc/others in the future.

Or just stick to having Cloudflare as an option to make it simple.

,

 

[ColinTaylor]

Perhaps for future proofing, add option under DNSFilter Global Filter Mode for DoT (and/or DoH) then select Provider/Server: Cloudflare/1.1.1.1, Quad9 and etc/others in the future.

Or just stick to having Cloudflare as an option to make it simple.

The problem with that is that you'd have to run a separate instance of Stubby for every DoT/DoH server that you might want to connect to, each on a different port. Even with the current Stubby implementation it's not as simple as "use this IP address" because it is typically configured to use multiple IP addresses (1.1.1.1/1.0.0.1) and/or multiple providers (Cloudflare/Quad 9) and they can be used in strict order or round-robin.

This is what I was referring to in point 7 above.

In my own experience I found it hard enough trying to find just one DoT server that was reliable enough to use in a real-world situation. Perhaps in the future if DoT becomes more established there will be a meaningful choice, but at the moment I think that's a long way away.

 

[john9527]

The problem with that is that you'd have to run a separate instance of Stubby for every DoT/DoH server that you might want to connect to, each on a different port.

And stubby as currently written does not allow multiple instances (I tested it).

 

[ColinTaylor]

And stubby as currently written does not allow multiple instances (I tested it).

Well, whilst it was an interesting academic exercise I think there's no point in really pursuing this. While it would be possible to have DNSFilter present "stubby" as an option, in reality this makes little sense. The kind of people that want their DNS traffic encrypted are going to want it applied to all devices by default, which is what the WAN option does. DNSFilter is there if a particular device needs to be an exception. Doing the reverse - not encrypting DNS by default and having just the odd device encrypted - is never likely to be a realistic scenario.

 

[dave14305]

Well, whilst it was an interesting academic exercise I think there's no point in really pursuing this. While it would be possible to have DNSFilter present "stubby" as an option, in reality this makes little sense. The kind of people that want their DNS traffic encrypted are going to want it applied to all devices by default, which is what the WAN option does. DNSFilter is there if a particular device needs to be an exception. Doing the reverse - not encrypting DNS by default and having just the odd device encrypted - is never likely to be a realistic scenario.

I agree. I feel this would have been a misuse of DNSFilter which is about enforcing a DNS resolver, not the transport method for the request (plaintext, TLS, HTTPS).

Or John could fork Stubby and rewrite it to assign a particular set of resolvers for each configured listening port.

 

[DroidST]

I just not familiar enough with Stubby, I assumed this could be done without that during the intercept, then encrypt and redirect and reverse on result returned.

I could go the WAN way with those options like john has is his fork's new build today and use DNSFilter to direct certain clients to OpenDNS Home, all others to Router in DNSFilter. The problem with this, if one of the person's I want to filter gets a new device and I'm not involved in its config, by default he would use the WAN DNS and not the filter until I caught it and could force that client in DNSFilter.

That would still work for me, wish Merlin's official would add those WAN DNS Settings for use on a 86U.

,