Pi-hole not blocking ads with Asus RT-AX88U

In my WAN settings, I have the following as in the screenshot. The reason is, I thought the router gets the DNS from the Pi Hole.
Should I select No and add the IP of Pi-Hole?

My LAN-DHCP Settings as seen in the screenshot. Is this set correctly?


EDIT
I changed the WAN DNS setting to manual mode and entered the Pi address 192.168.1.2 and created another debug log.
https://tricorder.pi-hole.net/5s44xf9gxk
Does this get rid of the public DNS you mentioned?
Additionally, I have the Pi's DNS set up as seen in the screenshot below. Is this OK?

Honestly, I can just guess what that WAN setting in your router means.
I cannot study your router's manual for you.

Since you are also distributing Pi-hole via DHCP already, it's probably best to not touch it, unless you want to risk creating a (partial) DNS loop.

Yes, that's correct, but I suspect your router to be the issue.
There are some misbehaving routers that will distribute their own IP as additional DNS, no matter what you configure.

I fear your router would fall into that category.
Again, your router's manual and/or support may reveal some additional tweaks on how to get rid of your router's IP as DNS server, but I wouldn't count on that.

An alternative would be to disable the DHCP server in your router and turn on Pi-hole's.
Before you do that, make sure that Pi-hole has a static IP assignment in place.
Take a look at /etc/dhcpcd.conf:

grep -v '^#\|^$' /etc/dhcpcd.conf

As far as I understand from what I read, it simply gets the DNS from my ISP.
If I set it to NO, then it opens two fields, DNS1 and DNS2 for me to enter manually.
The only reason it was set to YES (obtain from ISP) was that I thought it would pick up the Pi-Hole's DNS.

The confusion is what the hell is the DNS under LAN settings do?
Here's my assumption:
DNS under LAN settings tell all the clients in my LAN to use the local DNS if I chose to.
WAN DNS tell all the clients that request internet access which DNS to use.
If this is a correct assumption, then the LAN DNS should remain empty, because I don't care about local requests, and set the WAN DNS to use Pi-Hole instead of my ISP.

In your opinion, what is the best way to test that assumption?

This is quite a capable router with lots of custom configuration that are not for the average user. The RT-AX88U is a powerhouse. It uses Asus's own WRT firmware. I believe it doesn't fall into that category, but I'm not a network savvy as you are so I obviously learn from your comments quite a lot. I really appreciate your help so far!


Running netsh interface ipv4 show dnsservers
Ethernet 4 is the port I use for wiring my PC.
This is the critical path for using the right DNS.
After flushing the DNS and restarting the router and making sure the Ethernet 4 is obtaining DNS automatically, it is still showing 192.168.1.1, instead of 192.168.1.2.
How do I overcome this besides setting it manually?

As for the VPN ethernet port, I'll deal with that later. I mainly use the VPN for torrents.
ip4dns

Lastly, did I set the Pi's DNS correctly?

dhcp

Basically, there are two ways of configuring your router to filter DNS requests through Pi-hole:

  1. Distribute Pi-hole as local DNS server via DHCP.
    All your DHCP clients will talk to your Pi-hole for DNS, and Pi-hole will forward unfiltered requests to one of its configured upstream servers. If a router supports it, this would be the preferred way, as it doesn't come with the restrictions of option 2.).
    Your DNS resolution path looks like:
    client -> Pi-hole -> upstream DNS

  2. Use Pi-hole as your router's sole upstream DNS server.
    All your DHCP clients talk to your router for DNS, and your router will forward all DNS requests to Pi-hole.
    Hence your Pi-hole will see all DNS requests as originating from your router. You won't be able to attribute DNS traffic to individual client IPs, and you cannot use client-based filtering (i.e. group management) in any meaningful way, and no, Conditonal Forwarding won't do anything for you in that case.
    Your DNS resolution path looks like:
    client -> router -> Pi-hole -> upstream DNS

Your router does not allow for 1.), as your netsh for IPv4 DNS has proven that it distributes itself alongside Pi-hole, despite you having only defined Pi-hole as DNS via your router's DHCP settings.

To mitigate this, you can either have Pi-hole act as your DHCP server, or go for option 2.).

EDIT: Sorry, I'll be offline soon, so you will be by yourself with any changes you do now. Though probably some of our friendly users or other mods maybe able to jump in. :wink:

1 Like

Thank you very much for the help so far and enjoy your offline time.
When you are back online and if no answer is given by then, can you please confirm if the pi-hole's DNS settings are configured correctly?
In the meantime, I'll research about the router distributing it's DNS and not respecting my settings.

I would if you tell me which way you're heading: :wink:
Option 2.) or having Pi-hole as DHCP?

Your most recent change would support the former:

And since your latest netsh interface ipv4 show dnsservers shows only your router 192.168.1.1 as local DNS, it would seem that you already removed Pi-hole from your router's DHCP.

If you can live with the restrictions that go with that config, you can try whether this works for you. Just make sure Pi-hole is your router's only upstream DNS. If you're forced to enter a second IP, reenter Pi-hole's, and if that is rejected for being identical, choose 0.0.0.0.

You've configured Pi-hole to use some local upstream resolver on the same machine at 127.0.0.1#5053. Is that cloudflared?

Pi Hole as DHCP.
Seems that only Merlin-WRT, supported on Asus routers, reveals the option to not publish the router's DNS.
Example: image
I could install new firmware on my router, but it's too much effort for my limited time.

Unless I manually set 192.168.1.2 as the DNS of my PC on IPv4 settings.
But, I'm not sure if my other wireless clients will go though 192.168.1.2 or 192.168.1.1.
Is there a way to validate what DNS is used by my wireless clients?

Yes.
I followed the DNS over HTTPS guide here: Redirecting...
BUT, DoH while claiming it is secure still depends on normal DNS over port 53 to locate the DoH server so is not, secure. I might try Stubby DoT Implementing DNS-Over-TLS - #8 by bbunge

Thoughts?

Ok then:
If your dhcpcd.conf is still looking as posted by you above, and your Pi-hole machine is connected via Ethernet (eth0), then you can switch off your router's DHCP server and enable it on your Pi-hole via Settings | DHCP.

Note that your clients will only request a new DHCP lease from Pi-hole once their existing DHCP lease (as issued by your router) is about to expire.
You can wait this out or force a DHCP lease renewal for a client by dis- and reconnecting it to your network, e.g. by switching WLAN on and off or by power-cycling a device.

Once they acquire their lease through Pi-hole, they will use Pi-hole as their sole local DNS server, and they'll also show up under DHCP leases in Pi-hole.

Do not turn on Conditional Forwarding - you risk closing a DNS loop otherwise, as your router is still configured to use Pi-hole as upstream in its WAN settings, and you don't need it anyway, as Pi-hole knows your client names via DHCP now.

You can use the same diagnostic nslookups as used before:

nslookup pi.hole

That should return Pi-hole's IP.

nslookup flurry.com

That should return 0.0.0.0.

If you have a WiFi laptop, use that to verify.

If you are just using Smartphones via WLAN, you may not be able to extract that information on device. Some models may reveal the DNS servers somewhere in their WLAN or device info settings, some won't. Using a terminal app doesn't help: Even if they support nslookup, they often use a set of static DNS servers instead of the system provided ones.

Your choice of upstream DNS would depend on your personal preferences.

If you are worried about third-party eaves-dropping, you may opt for DoH or DoT.
While this is an area of concern for nomadic devices (e.g. a laptop in a public WLAN cafe), this is hardly an issue when at home, and you should also be aware that any DoH or DoT DNS service provider would still have your complete personal DNS history in any case.

If you are concerned about privacy, consider unbound instead:
DNS queries are resolved recursively starting with the root servers, so no single DNS server will ever have your full DNS history.

Did you finish establishing Pi-hole as DHCP server already?

Yes. It's up an running.
Here's a new debug log: https://tricorder.pi-hole.net/cfp9qqbcjw
I hope it shows it. I'm also still using cloudflared DoH.

Personal opinion:
You spend so much time on this forum writing long entries - it's a matter of minutes to flash this firmware. And you would gain much more control over your router.

Since Asuswrt-Merlin is mostly a variant of the original Asuswrt, it means that there is no special procedure to flash it. Just flash it the same way you would flash any regular Asus firmware.

From: Installation · RMerl/asuswrt-merlin.ng Wiki · GitHub

2 Likes

Thanks for the advice. While you are right, I opted to use Pi-hole's DHCP server as initially advised. It's a simpler approach in the meantime. I'm not ruling MerlinWRT out, but for now, this problem is settled.

TL;DR for this whole thread: SOLVED BY @Bucking_Horn
If using stock firmware on Asus RT-AX88U, the router will publish its DNS address alongside Pihole's DNS server regardless of the DNS settings under WAN or LAN are pointing to Pihole's IP address. Therefore, it is not known which DNS your clients will use.

  1. Either disable the stock firmware DHCP server and use Pihole's DHCP
  2. OR flash MerlinWRT which allows to stop publishing the router's DNS in an explicit manner.
    Thanks for everyone who helped to figure this out.
2 Likes

Thank you for taking the time to summarise your topic and describe the possible solutions. :heart:
This will help other users with a similar problem to
quickly zoom in to find your solution. :slight_smile:

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.