DNS Director only partially redirecting hardcoded DNS (Pi-hole setup) – mixed Google/Cloudflare results

[SocratesBackup]

I’m running into what looks like inconsistent DNS Director behavior on Merlin and I’m hoping someone can sanity-check my setup. Basically, I believe I have a set up DNS Director correctly, but for some reason, it seems to be sending DNS queries to both my Pihole and to the hardcoded DNS at the same time. Which basically means that ads still get shown, and that DNS director is not doing its job.

### Router Info

* Router: **GT-AX11000**
* Firmware: **3004.388.9_2_rog**
* IPv6: **Disabled (Connection Type: Disable)**
* Pi-hole upstream DNS: **1.1.1.1 (Cloudflare)**

Under WAN Settings:
* Prevent client auto DoH : **Yes**

Under Administration:
*Enable JFFS custom scripts and configs: **No**

Unique to my Setup:
*Home Assistant Integration: **Yes** (Works like a charm, but I honestly would not know if it has anything to do with this)
---

## Setup

### LAN → DHCP Server

* DNS Server 1 = Pi-hole IP 1 = 192.168.1.61
* DNS Server 2 = Pi-hole IP 2 = 192.168.1.8
* Advertise router’s IP in addition to user-specified DNS = **No**

### LAN → DNS Director

* DNS Director = Enabled
* User Defined 1 = Pi-hole IP
* Global Redirection = **User Defined 1**
* Pi-hole device 1 = **No Redirection**
* Pi-hole device 2 = **No Redirection**

---

## Testing Scenarios

### Scenario 1 – Windows using DHCP (gets Pi-hole DNS)

When Windows is set to automatic DNS:

DNS leak test shows only **Cloudflare**. And this makes sense:
Client → Pi-hole → Cloudflare

Ads are properly blocked and here is the output for What is My DNS Server: https://www.top10vpn.com/tools/what-is-my-dns-server.

```
Windows Settings And DNS web Result for DHCP:

```



---

### Scenario 2 – Windows manually set to 8.8.8.8

DNS Director = No Redirection

Leak test shows only **Google**.

Expected and correct. No ads are blocked because Pihole is not being assigned and DNS is not being redirected.

```
Windows Settings And DNS Leak Result for hardcoded DNS:

```


---

### Scenario 3 – Windows manually set to 8.8.8.8

DNS Director = Global Redirection → User Defined 1 (Pi-hole)

Now leak test shows a **mix of Google and Cloudflare**.

This is the confusing part.

If DNS Director is properly redirecting 8.8.8.8 → Pi-hole, I would expect results identical to Scenario 1 (all Cloudflare).

Instead, it appears some queries are still reaching Google. This explains why I continue to see ads. See the results below:


```
Windows Settings And DNS Result for hardcoded DNS with Redirection to Pihole

```



---

## Additional Testing

IPv6 is disabled on the router:

```
IPv6
Connection type: Disable
```

Windows test:

```
nslookup google.com 8.8.8.8
→ Works

nslookup google.com 2001:4860:4860::8888
→ No response
```

So IPv6 does not appear active on the client side.

DoH is disabled in Windows.

---

## What I’m Trying to Understand

1. Is DNS Director supposed to fully prevent hardcoded DNS usage?
2. Does DNS Director only redirect queries but not fully rewrite responses?
3. Is mixed DNS leak output expected behavior in this setup?
4. Is this a known limitation/bug in 3004.388.x?

If anyone running Merlin + Pi-hole + DNS Director can confirm expected behavior, I’d really appreciate it.

 

[bennor]

As a troubleshooting step, have you tried setting the DNS Director Global Redirection to User Defined DNS 2 (the Raspberry Pi-Hole) to see if the issue persists?

Does the Windows device used for the testing have more than one network adapter active?
Have you tried experimenting with a different or second device to see if the behavior is replicated on your network?

Not sure I've seen such behavior with the Asus-Merlin 3006.102.x firmware with DNS Director + Pi-Hole (on a Raspeberry Pi device) + Unbound. The Pi-Hole diagnostics log shows the requests from hard coded DNS entries on the client device as coming from the router (which it should per the DNS Director settings). But then again I do block Google's DNS's (8.8.8.8 and 8.8.4.4) using the LAN > Route page:


Generally how I have my Pi-Hole, RT-AX86U Pro router, Guest Network Pro, and DNS Director configured is detailed at the following post:

Guest Network Pro Pi Hole

Hey everyone, I have an issue with DNS resolution that I'm looking for help with. I have a RT-AX88U Pro using Guest Network Pro and a raspberry pi4 running Pi-Hole. The devices on my LAN can connect to the Pi-Hole without issue, however devices on my guest network (VLAN) cannot. In the guest...

www.snbforums.com

 

[dave14305]

It’s important to know which browser you’re testing with. Chrome will see that you have 8.8.8.8 as the DNS resolver and “upgrade” the browser to use DoH.

DNS over HTTPS (aka DoH)

Windows test:

```
nslookup google.com 8.8.8.8
→ Works

Does this query show up in the Pi-Hole logs?

 

[bennor]

Windows test:

```
nslookup google.com 8.8.8.8
→ Works

As @dave14305 indicated, does a nslookup google.com 8.8.8.8 request show up in your Pi-hole Query Log?
With my previously described Pi-Hole DNS Director (and Route) settings this is how my Raspberry Pi Pi-Hole (with Unbound) shows that nslookup request:

Edit to add:
A second example, this time with the LAN > Route disabled (that was used to route 8.8.8.8/8.8.4.4). Second query is highlighted in red.

Note: Using a Windows 11 PC connected via WiFi to main LAN WiFi on a RT-AX86U Pro 3006.102.6 with Pi-Hole + Unbound running on two Raspberry Pi clients (3B+ wired/Pi Zero WH WiFi).

 

[dave14305]

With my previously described Pi-Hole DNS Director (and Route) settings this is how my Raspberry Pi Pi-Hole (with Unbound) shows that nslookup request

Where is the actual google.com query?

 

[bennor]

Where is the actual google.com query?

Here are the two sets of time for the google.com that are similar to the previously posted 8.8.8.8 query. The 11:19:x time was with my LAN > Rules enabled and the 11:30:x time is with LAN > Rules disabled.


Edit to add: Bit more information in additional screen shots of the Pi-Hole Query Log.
11:19:x time:

11:30:x time:

 

[SocratesPrime]

EDIT: Included an incorrect screenshot for the pihole logs. Added the correct one.

Hello, This is OP. My original account got reinstated. The backup account has been deleted, so I would be addressing your responses here. I appreciate the help.

1.

As a troubleshooting step, have you tried setting the DNS Director Global Redirection to User Defined DNS 2 (the Raspberry Pi-Hole) to see if the issue persists?

@benner: The issue persists even when Global Redirection is set to User Defined 2: Pihole 2 . The windows device is a laptop that only has Wifi - No ethernet ports. Indeed, the pihole does show that the query is coming from the router. See my other responses below. My suspicion is that the query is being leaked somehow, and if that is the case, would pihole see the leak? In Scenario 2, pihole would not detect, if all queries are going directly to 8.8.8.8
2.

It’s important to know which browser you’re testing with. Chrome will see that you have 8.8.8.8 as the DNS resolver and “upgrade” the browser to use DoH.

I am testing using Chrome. I was of the understanding that once the "Prevent client auto DoH" under WAN Settings is set to "Yes", then no client would be able to make queries via DOH. I did do the due deligence of disabling DOH in the windows DNS settings. However, based on your claim, it is possible none of that would matter to chrome, unless of course merlin blocks those requests at the router level.

3.

Does this query show up in the Pi-Hole logs?

Yes, it does show up in pihole. See image below. The query is coming directly from my router, which means DNS Director is intercepting the queries from the windows laptop. I want to be cautious about saying "intercepting", as I can not rule out the fact that DNS Director may still be allowing the queries through, which could also explain my issue. Do note, however, that my pihole results show HTTPS queries, which makes me suspect DOH is being used. I am however, uncertain..


EDIT: Correct Logs:

Incorrect Log initially sent. Please see correct one above.

4.

As @dave14305 indicated, does a nslookup google.com 8.8.8.8 request show up in your Pi-hole Query Log?
With my previously described Pi-Hole DNS Director (and Route) settings this is how my Raspberry Pi Pi-Hole (with Unbound) shows that nslookup request:

Yes, please see above. Comparing my results to yours, there is clearly some differences, specificay, the fact that there is an HTTPS record. Could that be the issue?

 

[dave14305]

Yes, it does show up in pihole. See image below.

That’s not a log from nslookup google.com 8.8.8.8 however. We want to eliminate the browser from the test for now.

Chrome does not respect any canary domains like Mozilla or Apple or Microsoft when it comes to DoH.

 

[SocratesPrime]

That’s not a log from nslookup google.com 8.8.8.8 however. We want to eliminate the browser from the test for now.

Chrome does not respect any canary domains like Mozilla or Apple or Microsoft when it comes to DoH.

Thanks, added the correct one.

Are you saying that chrome as a broswer can bypass DNS Director and the setting on the router to prevent DOH?

Wouldn't that mean that DNS Director would be useless?

 

[dave14305]

Are you saying that chrome as a broswer can bypass DNS Director and the setting on the router to prevent DOH?

Yes, because Chrome offers no way for local network admins to disable its DoH.

Wouldn't that mean that DNS Director would be useless?

Maybe, but the main idea behind DoH is to enjoy privacy from meddling network admins, censors, oppressive governments, etc.

If you want to try to prove/disprove your leak theory, add this iptables rule over SSH and then run your leak test. Then check the system log. Make sure your wan is eth0 first.

iptables -t mangle -I POSTROUTING -o eth0 -d 8.8.0.0/16 -j LOG --log-prefix "[DNS Leak] " --log-tcp-options --log-ip-options

If it's leaking, you'll see those log entries and the DPT. If it's 443, you'll know it's DoH.
Delete the rule with:

iptables -t mangle -D POSTROUTING -o eth0 -d 8.8.0.0/16 -j LOG --log-prefix "[DNS Leak] " --log-tcp-options --log-ip-options