Entries added to misc.dnsmasq_lines are not being applied

Help Community Help
1

The issue I am facing:

I have a VPN configured on my router which forwards traffic from certain domains through a VPN.

I am trying to use pihole to forward queries for this domain to my router.

I have added the domain to (settings/miscellaneous) misc.dnsmasq_lines:

server=/example.com/192.168.1.1

to forward DNS lookups for this domain to the router (which runs a DNS server). The router will then apply domain based policy routing to forward the traffic through my work VPN.

The intent is to avoid needing to have the VPN on each local machine, bringing it up and down on demand, while still benefitting from pihole’s adblocking and local DNS for all other LAN traffic.

When I then run dig @my_pihole_ip example.com

I am returned:

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5818
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 17 ("..")
;; QUESTION SECTION:
;example.com.			IN	A

;; Query time: 36 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Sun Aug 17 11:05:20 BST 2025
;; MSG SIZE  rcvd: 44

Tailing the pihole log provides the same: Refused, with nothing else. It is important to note that even domains NOT configured in policy routing return the same error, which has me thinking this is a misconfiguration (on my part) on my pihole.

Details about my system:

I have a Unifi gateway which runs a VPN client to connect to my offices.

I’ve a pihole configured locally which contains DNS records for my local network.

I am using Cloudflare 1.0.0.1/1.1.1.1 (DNSSEC) for upstream DNS servers.

I have 3 simple VLANs which DO NOT block traffic to one another (I honestly don’t need the headache). They’re for simple segmentation. The VLANs are on 192.168.1.x, 2.x and 3.x.

My pihole is configured to ‘Respond only on interface eth0’.

I’ve tried to not fiddle with anything as much as possible because, bluntly, I’m probably too dim. I could use the router as my DNS server and save myself a headache but I like Pihole (the blocklist that removes that stupid ‘sign in with Google’ is worth it’s weight alone) and I want to understand what I am doing wrong.

What I have changed since installing Pi-hole:

I have added the entry referenced above to Settings / Miscellaneous/ misc.dnsmasq_lines

2

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

sudo pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

3

Hello Chris, many thanks for your interest:

https://tricorder.pi-hole.net/Mi8e21U6/

That’s a really elegant system. I hope I’ve done the right thing. Please let me know what I’ve broken.

4

Commonly, REFUSED would indicate that the upstream DNS server Pi-hole was forwarding a request to was either inaccessible or unresponsive.

Your debug log shows that your custom option correctly was added to Pi-hole's configuration:

*** [ DIAGNOSING ]: contents of /etc/pihole

-rw-r--r-- 1 pihole pihole 6.1K Aug 17 11:43 /etc/pihole/dnsmasq.conf
   (…)
   server=/example.com/192.168.1.1

Let's see how Pi-hole handled that query.
Run from your Pi-hole machine, please share the output of:

sudo grep example.com /var/log/pihole/pihole.log

And let's see how 192.168.1.1 responds when queried directly.
Please share the output of:

nslookup example.com 192.168.1.1
5

Hullo, thank you for replying:

The output of the grep (after attempting to visit example.com):

pi(a)raspberrypi:~ $ sudo grep example.com /var/log/pihole/pihole.log
Aug 18 14:35:52 dnsmasq[705]: query[A] example.com from 192.168.1.41
Aug 18 14:35:52 dnsmasq[705]: forwarded example.com to 192.168.1.1
Aug 18 14:35:52 dnsmasq[705]: query[HTTPS] example.com from 192.168.1.41
Aug 18 14:35:52 dnsmasq[705]: forwarded example.com to 192.168.1.1
Aug 18 14:35:52 dnsmasq[705]: query[A] example.com from 192.168.1.41
Aug 18 14:35:52 dnsmasq[705]: query[HTTPS] example.com from 192.168.1.41
Aug 18 14:35:52 dnsmasq[705]: reply example.com is 96.7.128.198
Aug 18 14:35:52 dnsmasq[705]: reply example.com is 96.7.128.175
Aug 18 14:35:52 dnsmasq[705]: reply example.com is 23.215.0.136
Aug 18 14:35:52 dnsmasq[705]: reply example.com is 23.192.228.84
Aug 18 14:35:52 dnsmasq[705]: reply example.com is 23.215.0.138
Aug 18 14:35:52 dnsmasq[705]: reply example.com is 23.192.228.80
Aug 18 14:35:52 dnsmasq[705]: reply example.com is NODATA

And (I reversed your command as the example (a)… returned : nslookup: couldn't get address (a)192.168.1.1: not found

pi(a)raspberrypi(a)192.168.1.1**~ $** nslookup (a)192.168.1.1 example.com

;; connection timed out; no servers could be reached

A far more knowledgeable chum suggested my config might be back to front. As mentioned, I had defined my pihole as the DNS server for my WAN interface, with clients pointing to the router itself for DNS.

I have since changed this to set the WAN DNS to be 1.1.1.1/9.9.9.9 and defined the pihole as DNS for the LAN interface.

In addition, under Settings / DNS / Custom DNS servers I’ve defined the router in there. That’s allowed the traffic to my work websites to pass over the VPN.

Note: the results from the commands are with the pihole defined as the DNS for the LAN interface - i.e, as described above.

Apologies if I have muddied the waters.

The (a) is an attempt to disguise the usual at symbol.

6

Those log lines demonstrate that Pi-hole has correctly forwarded the requests for example.com to 192.168.1.1 as configured, and it also shows the reply as provided by 192.168.1.1.

Why do you think it's not working?

Apologies - the command must be run in the exact order as provided, but without the @ I'd initially and mistakenly included in my post.

7

Hullo, I was going to say that while the domain resolves the data wasn't returned - on my first tests after the re-arranging it didn't - but now it does, without issue.

Therefore, thank you to everyone for your input and advice. Problem solved!

8

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