Issue with DNSFilter with 386.7_2

[solehad]

Hi,

Sorry if this is in the wrong forum. I've got an issue with DNSFilter on my RT-AC68u running merlin 386.7_2 (but this issue also affected previous versions). I'm not sure if this is a bug or if I don't understand something about DNSFilter (quite possibly the latter).

My router is at 10.0.0.1/24 and a pihole is at 10.0.0.3. The router's DHCP server is configured to provide 10.0.0.3 and 10.0.0.1 as DNS servers (in that order). DNSFilter is enabled, with the global filter mode set to Router and the device at 10.0.0.3 configured to allow no filtering.

When 10.0.0.3 is up and running everything works perfectly. From DHCP clients on the network I can resolve names against 10.0.0.3, and if I resolve against 10.0.0.1 I can see in the pihole logs that the router is forwarding the resolution request to pihole.

The problem starts if pihole goes offline. When this happens, DNS resolution breaks entirely. I can't resolve addresses against 10.0.0.1 because, I assume, the router is trying to forward requests to pihole at 10.0.0.3 which is offline.

However, if I configure the router as the first DNS entry under DHCP server settings, DNS resolution works when the pihole is offline.

Based on my configuration and the description of how DNSFilter works, I would not expect any issues with my configuration, and I would expect the router to be able to resolve DNS using an upstream forwarder when the pihole is offline. Or, to put another way, I would not expect DNSFilter to redirect the resolution requests for something (in this case itself) which is configured as the second DNS server in DHCP server settings.

Any thoughts? Thanks!

 

[eibgrad]

Having a global filter for the Router at the same time as configuring the DHCP server w/ custom DNS servers makes no sense, since those are mutually exclusive settings. In fact, the router will *ignore* the global filter and only implement the DNS filter for the first custom server you defined for the DHCP server.

IOW, you're telling your clients to use 10.0.0.3 and 10.0.0.1 w/ DHCP, then forcing them back to 10.0.0.1 w/ the global filter anyway. 10.0.0.3 is thus starved of any traffic.

The problem w/ any DNS filter is that by definition, it limits you to that one DNS server. So providing multiple DNS servers via DHCP is again pointless. The better option is to either have your clients use 10.0.0.3 exclusively in DHCP (thereby bypassing DNSMasq), and a global custom DNS filter to enforce it, OR, configure DNSMasq w/ 10.0.0.3 using a dnsmasq.conf.add file and allow your clients to continue using DNSMasq (10.0.0.1) as their normal, local proxy (and a global DNS filter for Router to enforce it). At least then you'd have local name resolution, while anything else gets passed to 10.0.0.3.

# add to DNSMasq
no-resolv
server=10.0.0.3

 

[solehad]

Having a global filter for the Router at the same time as configuring the DHCP server w/ custom DNS servers makes no sense, since those are mutually exclusive settings. In fact, the router will *ignore* the global filter and only implement the DNS filter for the first custom server you defined for the DHCP server.

According to the description of the router option in DNSFilter, they aren't mutually exclusive settings: ""Router" will force clients to use the DNS provided by the router's DHCP server"

IOW, you're telling your clients to use 10.0.0.3 and 10.0.0.1 w/ DHCP, then forcing them back to 10.0.0.1 w/ the global filter anyway. 10.0.0.3 is thus starved of any traffic.

What's actually happening is that 10.0.0.3 is serving all DNS requests, even when they're sent to 10.0.0.1 (because 10.0.0.1 just forwards onto 10.0.0.3).

The problem w/ any DNS filter is that by definition, it limits you to that one DNS server.

This does seem to be the problem, but this is what I am trying to clarify. If this is how DNSFilter is intended to work, then the description of the router mode should probably be something like ""Router" will force clients to use the first DNS provided by the router's DHCP server".

So providing multiple DNS servers via DHCP is again pointless. The better option is to either have your clients use 10.0.0.3 exclusively in DHCP (thereby bypassing DNSMasq), and a global custom DNS filter to enforce it, OR, configure DNSMasq w/ 10.0.0.3 using a dnsmasq.conf.add file and allow your clients to continue using DNSMasq (10.0.0.1) as their normal, local proxy (and a global DNS filter for Router to enforce it). At least then you'd have local name resolution, while anything else gets passed to 10.0.0.3.

The configuration I am trying to achieve is to use pihole as the primary DNS with the router as a fallback if the pihole goes offline for some reason. Unless I misunderstand your second suggested approach, both of those will break DNS resolution if 10.0.0.3 goes offline?

 

[eibgrad]

This is why DNS configuration on the router is so confusing. Users don't understand the default configuration, and how various options change it.

By default, the DHCP server is configured w/ the DNS servers defined through the WAN, i.e., those of the ISP. The client is then configured by DHCP to use the router's DNS server/proxy (DNSMasq) (in your case, 10.0.0.1) as their DNS server. IOW, the client never sees the actual public DNS servers in use. All they ever see is the router's IP for a DNS server.

The purpose of the global Router DNS filter is to make sure that any attempt by the clients to use anything other than the router's DNS server (10.0.0.1) is redirected back to it.

But you made additional changes that are creating confusion. You decided to *override* the ISP's DNS servers in the DHCP server w/ your own (10.0.0.3 and 10.0.0.1). And to make matters worse, made it self referencing by including the router's DNS server (10.0.0.1). By doing so, you are NOW sending 10.0.0.3 and 10.0.0.1 to the clients as their DNS servers, NOT just 10.0.0.1, which as I said, would be the default.

So now if the client uses 10.0.0.3, it's redirected to 10.0.0.1 due to the global Router DNS filter. IOW, now matter the choice of the client between 10.0.0.3 and 10.0.0.1, it always ends up being 10.0.0.1! It's a circular configuration.

As I said before, the better option is to NOT mess w/ the DHCP server, but configure DNSMasq w/ 10.0.0.3 as your only DNS server via the dnsmasq.conf.add file, and let your clients continue to use DNSMasq (10.0.0.1) as their local proxy. Then the global Router DNS filter will ensure those clients only use 10.0.0.1. And now local name resolution will be provided by DNSMasq, and all other resolution passed on to 10.0.0.3 (because that's the only other DNS server configured in DNSMasq).

But if you insist on altering the DHCP server itself, you're liking going to create a mess.

One more thing. In this scenario, there really is no "backup" DNS server. All you have is 10.0.0.3, w/ DNSMasq serving as a proxy for local name resolution. Any backup DNS server(s) should be defined within 10.0.0.3. If you attempt to define a backup in DNSMasq instead, then there's no way to make 10.0.0.3 the primary DNS server. ALL DNS servers in DNSMasq are considered equally valid! So if you added say 8.8.8.8 and 8.8.4.4, all three of the DNS servers (10.0.0.3, 8.8.8.8, and 8.8.4.4) would be just as likely to be used, which is NOT what you want. You want 10.0.0.3 to be used exclusively, and have 10.0.0.3 make the decision whether to use backup DNS servers.

As I said, it's all very confusing. There are just too many options and variables, and they become very difficult to understand in terms of their consequences, esp. if you don't understand the default configuration upon which any changes are based.

 

[bennor]

The configuration I am trying to achieve is to use pihole as the primary DNS with the router as a fallback if the pihole goes offline for some reason. Unless I misunderstand your second suggested approach, both of those will break DNS resolution if 10.0.0.3 goes offline?

One issue you are potentially facing using both the Pi-Hole and router (or other non Pi-Hole DNS) as the LAN DHCP DNS entries is network clients can bypass the Pi-Hole and instead use the router or other non Pi-Hole DNS; effectively negating the entire reason for using the Pi-Hole. Better option would be using two Pi-Holes which is what some of us do. Example at end of the DNSFilter configured to use two Pi-Holes.

Generally (in layman's terms), the whole point of using DNSFilter with Pi-Hole is to force all network clients that try to bypass the DHCP DNS servers with their own hard coded DNS servers to use those DHCP DNS servers (i.e. the Pi-Hole). The entries in the DNSFilter Client List are the devices that are not routed back to use the router's LAN DHCP DNS servers. What you apparently are seeing with your configuration is a loop being created by using the router as a LAN DHCP DNS server entry but not (if I understand your setup correctly) including the router in the DNSFilter Client List.

Generally the way to setup Pi-Hole on Asus-Merlin is to input the Pi-Hole IP address in the LAN DHCP DNS Server field(s) and to uncheck "Advertise router's IP in addition to user-specified DNS". It is not recommended by Pi-Hole to use the Pi-Hole in the Asus WAN DNS fields. If you need a second non Pi-Hole DNS server as a fall back, then try inputting a public DNS server into the LAN DHCP DNS Server #2 field.

As eibgrad indicated DNSFilter confusing and easy to misconfigure.

DNSFilter with two Pi-Hole's:

 

[solehad]

This is why DNS configuration on the router is so confusing. Users don't understand the default configuration, and how various options change it.

I do understand how DNS works and how to configure DNS on a basic home network. I also understand how to design configure and maintain DNS for large enterprise networks, which is one of the things I do professionally. My confusion was centred around the DNSFilter configuration the Asus router, and the confusion stems from the fact that the only documentation for DNSFilter is what's printed in the UI, and that is missing one important detail: DNSFilter in router mode will force clients to use the DNS provided by the router's DHCP server, but only the first one. I appreciate that you've taken the time to respond to my posts but we have been talking at cross purposes because you have assumed I don't understand how DNS works whereas all I was trying to understand was whether DNSFilter is supposed to work this way or not, and if it is, then perhaps the UI descriptions should be updated to more accurately reflect how router mode works with DNS servers configured in the DHCP server.

By default, the DHCP server is configured w/ the DNS servers defined through the WAN, i.e., those of the ISP. The client is then configured by DHCP to use the router's DNS server/proxy (DNSMasq) (in your case, 10.0.0.1) as their DNS server. IOW, the client never sees the actual public DNS servers in use. All they ever see is the router's IP for a DNS server.

By default the DHCP server is configured to provide its own address to clients, not the upstream addresses defined thorugh the WAN interface and/or learned from the ISP.

The purpose of the global Router DNS filter is to make sure that any attempt by the clients to use anything other than the router's DNS server (10.0.0.1) is redirected back to it.

Yes, that is why I wanted to use DNSFilter - to block devices (e.g. smart TVs, etc) on the network from trying to use a hardcoded DNS and bypassing pihole's DNS blocklists.

But you made additional changes that are creating confusion. You decided to *override* the ISP's DNS servers in the DHCP server w/ your own (10.0.0.3 and 10.0.0.1). And to make matters worse, made it self referencing by including the router's DNS server (10.0.0.1). By doing so, you are NOW sending 10.0.0.3 and 10.0.0.1 to the clients as their DNS servers, NOT just 10.0.0.1, which as I said, would be the default.

Nothing here is creating confusion. I want DHCP clients on my network to use the pihole (10.0.0.3) as their primary DNS server which is why I configured it that way. The router's address is also being handed out in case the pihole goes down for some reason, because making the pihole the first DNS server with DNSFilter enabled was creating a single point of failure for the basic functionality of my network (DNS resolution) and if the pihole running in a container on a NAS goes down nobody else in the household can fix it. The configuration I applied was intentional.

So now if the client uses 10.0.0.3, it's redirected to 10.0.0.1 due to the global Router DNS filter. IOW, now matter the choice of the client between 10.0.0.3 and 10.0.0.1, it always ends up being 10.0.0.1! It's a circular configuration.

No, this is not correct as I have said in my original post. If clients use 10.0.0.3 it isn't redirected to 10.0.0.1. Pihole can forward upstream with no problems. This is because 10.0.0.3 is the first address listed in my DHCP server configuration (and I have configured a DNSFilter exclusion for the pihole). However, if clients try to send a request to 10.0.0.1 then it will be redirected to 10.0.0.3 by DNSFilter, which is not circular, but which does break DNS resolution entirely if 10.0.0.3 is offline.

As I said before, the better option is to NOT mess w/ the DHCP server, but configure DNSMasq w/ 10.0.0.3 as your only DNS server via the dnsmasq.conf.add file, and let your clients continue to use DNSMasq (10.0.0.1) as their local proxy. Then the global Router DNS filter will ensure those clients only use 10.0.0.1. And now local name resolution will be provided by DNSMasq, and all other resolution passed on to 10.0.0.3 (because that's the only other DNS server configured in DNSMasq).

Sure, this will work, but it will also break DNS if 10.0.0.3 goes down. The other option is to leave 10.0.0.3 and 10.0.0.1 and disable DNSFilter.

One more thing. In this scenario, there really is no "backup" DNS server. All you have is 10.0.0.3, w/ DNSMasq serving as a proxy for local name resolution. Any backup DNS server(s) should be defined within 10.0.0.3. If you attempt to define a backup in DNSMasq instead, then there's no way to make 10.0.0.3 the primary DNS server. ALL DNS servers in DNSMasq are considered equally valid! So if you added say 8.8.8.8 and 8.8.4.4, all three of the DNS servers (10.0.0.3, 8.8.8.8, and 8.8.4.4) would be just as likely to be used, which is NOT what you want. You want 10.0.0.3 to be used exclusively, and have 10.0.0.3 make the decision whether to use backup DNS servers.

A few things. Firstly, there is no point defining a backup DNS server within 10.0.0.3 because if 10.0.0.3 goes offline then....what? Secondly, 10.0.0.3, being a pihole, will by default forward any non-cached requests to an upstream public DNS. Thirdly, some DNS clients (such as Windows 10 and newer) will indeed send DNS resolution requests to all available DNS servers simultaneously or via round robin, but some DNS clients will preferentially use the first DNS server unless that server does not respond. I made the decision to configure my router the way I did because I preferred to have some DHCP clients potentially use the router and not the pihole for DNS resolution and not have a single point of failure (the pihole), versus making pihole the only DNS server provided by DHCP and creating that single point of failure that nobody else in the household can fix.

 

[solehad]

One issue you are potentially facing using both the Pi-Hole and router (or other non Pi-Hole DNS) as the LAN DHCP DNS entries is network clients can bypass the Pi-Hole and instead use the router or other non Pi-Hole DNS; effectively negating the entire reason for using the Pi-Hole. Better option would be using two Pi-Holes which is what some of us do.

Thanks for taking the time to respond, appreciate it. Unfortunately I don't have a second device to run a pihole on, otherwise I would indeed have two piholes running.

Generally (in layman's terms), the whole point of using DNSFilter with Pi-Hole is to force all network clients that try to bypass the DHCP DNS servers with their own hard coded DNS servers to use those DHCP DNS servers (i.e. the Pi-Hole).

Yep, that's exactly why I am using DNSFilter.

The entries in the DNSFilter Client List are the devices that are not routed back to use the router's LAN DHCP DNS servers. What you apparently are seeing with your configuration is a loop being created by using the router as a LAN DHCP DNS server entry but not (if I understand your setup correctly) including the router in the DNSFilter Client List.

And this seems to be the crux of the problem: because you cannot add a DNSFilter exclusion for the router itself, and because DNSFilter in router mode only seems to use the first DNS server configured in the DHCP server settings, it will forward any requests it receives to the pihole even when the pihole is offline.

It seems to me the solutions should be either a) for DNSFilter to force clients to use either of the DNS servers configured in the DHCP server (not just the first one), or b) update the UI description for the router mode to make clear that it forces clients to use only the first DNS server configured in the DHCP server.

If you need a second non Pi-Hole DNS server as a fall back, then try inputting a public DNS server into the LAN DHCP DNS Server #2 field.

That will not work because of the aforementioned problem, and I have just verified by testing to make sure I'm not missing something. With 10.0.0.3 and 1.1.1.1 configured (in that order) as the DHCP DNS servers and DNSFilter configured to router mode, when pihole is online resolving against both servers works (but requests to 1.1.1.1 are in fact intercepted by the router and redirected to 10.0.0.3). When the pihole is offline then requests to 1.1.1.1 are still redirected by the router and forwarded to the pihole which is offline.

If the second DNS server was a pihole then this configuration would work so long as the second pihole had an exclusion configured as per your screenshot, but you cannot configure an exclusion for something that doesn't have a MAC on the LAN.

If that configuration (e.g. using a public upstream DNS as secondary in the DHCP server settings) works on your side I would be happy if you let me know, as it does seem a bit like a bug to me that DNSFilter works in this way (at odds with the UI description).

 

[solehad]

I have figured out a workaround to the problem. With the following config:

• 10.0.0.3 (my pihole) and 10.0.0.1 (the router's LAN address) configured as DNS servers in the DHCP server
• DNSFilter enabled with a "no filtering" exclusion for pihole's MAC
• Setting DNSFilter's global filter mode to "Custom 1" instead of "Router"
• Providing the address of the router itself (in my case 10.0.0.1) as the Custom 1 entry

Then DNS queries made directly to the router will not be redirected back to the pihole by DNSFilter and will instead be forwarded upstream (to the DNS servers configured on the WAN interface). Hope that helps anyone who has the same problem in future and finds this thread.

EDIT: Actually it's not a perfect workaround because any device trying to use hardcoded DNS servers for resolution will be picked up by the dnsfilter and resolved by the router, bypassing the pihole.

 

[dave14305]

If you want the intercepted queries to also go to Pi-Hole, there are some additional configuration options in this post:

Merlin, dnsmasq, Pi-hole Accurate Device Names How-To?

I have an RT-AX86U running 386.1 beta 2 and while it is working well, I find that many ads are being served to devices, especially mobile phones. I have tried various suggestions for solving this and the DNSFilter option to force all DNS traffic to my Pi-hole works the best. Unfortunately, it...

www.snbforums.com

 

[bennor]

That will not work because of the aforementioned problem, and I have just verified by testing to make sure I'm not missing something. With 10.0.0.3 and 1.1.1.1 configured (in that order) as the DHCP DNS servers and DNSFilter configured to router mode, when pihole is online resolving against both servers works (but requests to 1.1.1.1 are in fact intercepted by the router and redirected to 10.0.0.3). When the pihole is offline then requests to 1.1.1.1 are still redirected by the router and forwarded to the pihole which is offline.

If the second DNS server was a pihole then this configuration would work so long as the second pihole had an exclusion configured as per your screenshot, but you cannot configure an exclusion for something that doesn't have a MAC on the LAN.

If that configuration (e.g. using a public upstream DNS as secondary in the DHCP server settings) works on your side I would be happy if you let me know, as it does seem a bit like a bug to me that DNSFilter works in this way (at odds with the UI description).

In a quick and dirty test on a RT-AC68U with the DNSFilter set as indicated in the screen capture previously posted. With both Pi-Hole's disconnected from the local network (Ethernet cable pulled), and the LAN DHCP Server #2 set to 1.1.1.1 network clients appear to still have no issues accessing websites and DNS requests appear to be resolved as they should. As always with these things its a YMMV.

Note: DNS Server 1 below is the Pi-Hole #1 IP address.

 

[bennor]

EDIT: Actually it's not a perfect workaround because any device trying to use hardcoded DNS servers for resolution will be picked up by the dnsfilter and resolved by the router, bypassing the pihole.

Exactly. As indicated previously; by using a second non Pi-Hole DNS server as a LAN DHCP Server, DNS requests (hard coded or otherwise) can potentially bypass the Pi-Hole. This is the trade off if one doesn't want to use a second Pi-Hole (or other similar ad block/filtering method) as the second LAN DHCP DNS server. Ideally if you want a fall back DNS server, setup a second Pi-Hole. If you don't have a second Raspberry Pi then see if you have a local network device running Linux (NAS, PC, etc.) or that is capable of running docker. If so install install Pi-Hole to that Linux OS or install the docker version of Pi-Hole: https://github.com/pi-hole/docker-pi-hole (Obviously more configuration may be needed depending on the alternate device one installs Pi-Hole to.)

Edit to add: Another option, if you know certain devices have hard coded DNS IP addresses is to block those DNS IP addresses by using the Asus-Merlin LAN > Route page. Doing so however may potentially affect that device's operation. See this link for generic directions. Example of blocking Google DNS servers:

 

[solehad]

If you want the intercepted queries to also go to Pi-Hole, there are some additional configuration options in this post:

Merlin, dnsmasq, Pi-hole Accurate Device Names How-To?

I have an RT-AX86U running 386.1 beta 2 and while it is working well, I find that many ads are being served to devices, especially mobile phones. I have tried various suggestions for solving this and the DNSFilter option to force all DNS traffic to my Pi-hole works the best. Unfortunately, it...

www.snbforums.com

Hey, thanks for linking that config, I will try that later. One question: I'm not very familiar with dnsmasq configuration, but it sounds like strict-order make dnsmasq use the addresses in resolv.conf in-order (not inverse order), which means WAN DNS 1 first and WAN DNS 2 (the pihole) second? So why would the router forward requests to WAN DNS 2 first?

 

[solehad]

In a quick and dirty test on a RT-AC68U with the DNSFilter set as indicated in the screen capture previously posted. With both Pi-Hole's disconnected from the local network (Ethernet cable pulled), and the LAN DHCP Server #2 set to 1.1.1.1 network clients appear to still have no issues accessing websites and DNS requests appear to be resolved as they should. As always with these things its a YMMV.

View attachment 43524

Note: DNS Server 1 below is the Pi-Hole #1 IP address.
View attachment 43525

Hi,

Thanks for testing that, the behaviour you are seeing is what I expected when I configured the DNSFilter to begin with, but for whatever reason that's not what happens for me - as I've said in my case DNSFilter does not allow requests to pass to whatever is configured in LAN DNS 2.

 

[dave14305]

it sounds like strict-order make dnsmasq use the addresses in resolv.conf in-order (not inverse order), which means WAN DNS 1 first and WAN DNS 2 (the pihole) second? So why would the router forward requests to WAN DNS 2 first?

dnsmasq is funny that way. Through trial and error, we came to that order.