DNS lookup speeds shouldn’t be greatly reduced when using the PiHole server as a VPN for only DNS resolution (not complete routing).
Actual Behaviour:
DNS when the VPN connected is extremely slow, but becomes closer to my normal speeds when refreshing or as more domains stored in cache. But cache seems to be cleared every time the VPN is disconnected.
I’m unsure where in the networking stack is causing extremely slow speeds for DNS resolution when using the VPN.
I do have a complete list of steps to fully reproduce the server setup if needed.
Guides I followed for the configurations encase there’s any ambiguity:
Some ping stats for the domain I use for the DDNS in the Wireguard configuration:
$ ping <redacted-server-domain>
PING <redacted-server-domain> (<redacted-server-public-ip>) 56(84) bytes of data.
64 bytes from <<redacted-dynamic-hostname> (<redacted-server-public-ip>)>: icmp_seq=1 ttl=64 time=1.87 ms
64 bytes from <redacted-dynamic-hostname> (<redacted-server-public-ip>): icmp_seq=2 ttl=64 time=1.31 ms
64 bytes from <redacted-dynamic-hostname> (<redacted-server-public-ip>): icmp_seq=3 ttl=64 time=2.13 ms
64 bytes from <redacted-dynamic-hostname> (<redacted-server-public-ip>): icmp_seq=4 ttl=64 time=2.10 ms
64 bytes from <redacted-dynamic-hostname> (<redacted-server-public-ip>): icmp_seq=5 ttl=64 time=1.05 ms
64 bytes from <redacted-dynamic-hostname> (<redacted-server-public-ip>): icmp_seq=6 ttl=64 time=3.62 ms
64 bytes from <redacted-dynamic-hostname> (<redacted-server-public-ip>): icmp_seq=7 ttl=64 time=2.18 ms
^C
--- <redacted-server-domain> ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6007ms
rtt min/avg/max/mdev = 1.052/2.038/3.619/0.762 ms
I know the slow DNS performance when using the VPN isn’t due to the DDNS provider or router.
When not connected to the VPN and using manual DNS pointing at the pihole server, I know it isn’t a DOH or UFW issue because performance isn’t negatively impacted.
I’ve since made the server use openresolv and still no changes
I've checked some logs.
$ sudo journalctl --no-pager | grep -E "(wg-quick@wg0|pihole-FTL)"
Mar 26 17:09:03 raspberrypi systemd[1]: Starting pihole-FTL.service - Pi-hole FTL...
Mar 26 17:09:03 raspberrypi systemd[1]: Started pihole-FTL.service - Pi-hole FTL.
Mar 26 17:09:03 raspberrypi systemd[1]: Starting wg-quick@wg0.server.service - WireGuard via wg-quick(8) for wg0.server...
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.438 GMT [1348M] INFO: ########## FTL started on raspberrypi! ##########
Mar 26 17:09:03 raspberrypi systemd[1]: Starting wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0...
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.438 GMT [1348M] INFO: FTL branch: master
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.438 GMT [1348M] INFO: FTL version: v6.5
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.438 GMT [1348M] INFO: FTL commit: f8883098
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.438 GMT [1348M] INFO: FTL date: 2026-02-17 20:20:12 +0000
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.438 GMT [1348M] INFO: FTL user: pihole
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.438 GMT [1348M] INFO: Compiled for linux/arm64/v8 (compiled on CI) using cc (Alpine 15.2.0) 15.2.0
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.440 GMT [1348M] INFO: Wrote config file:
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.440 GMT [1348M] INFO: - 166 total entries
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.440 GMT [1348M] INFO: - 154 entries are default
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.440 GMT [1348M] INFO: - 12 entries are modified
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.440 GMT [1348M] INFO: - 0 entries are forced through environment
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.462 GMT [1348M] INFO: Parsed config file /etc/pihole/pihole.toml successfully
Mar 26 17:09:03 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.462 GMT [1348M] INFO: PID file does not exist or not readable
Mar 26 17:09:03 raspberrypi systemd[1]: wg-quick@wg0.server.service: Main process exited, code=exited, status=1/FAILURE
Mar 26 17:09:03 raspberrypi systemd[1]: wg-quick@wg0.server.service: Failed with result 'exit-code'.
Mar 26 17:09:03 raspberrypi systemd[1]: Failed to start wg-quick@wg0.server.service - WireGuard via wg-quick(8) for wg0.server.
Mar 26 17:09:03 raspberrypi systemd[1]: Finished wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0.
Mar 26 17:09:08 raspberrypi pihole-FTL[1348]: 2026-03-26 17:09:03.462 GMT [1348M] INFO: No other running FTL process found.
$ systemctl status wg-quick@wg0.server.service
× wg-quick@wg0.server.service - WireGuard via wg-quick(8) for wg0.server
Loaded: loaded (/usr/lib/systemd/system/wg-quick@.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Thu 2026-03-26 17:09:03 GMT; 56s ago
Invocation: 6cd0396c0fe246658148e0c8f7f576e8
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
Process: 1350 ExecStart=/usr/bin/wg-quick up wg0.server (code=exited, status=1/FAILURE)
Main PID: 1350 (code=exited, status=1/FAILURE)
CPU: 10ms
Mar 26 17:09:03 raspberrypi systemd[1]: Starting wg-quick@wg0.server.service - WireGuard via wg-quick(8) for wg0.server...
Mar 26 17:09:03 raspberrypi wg-quick[1350]: wg-quick: `/etc/wireguard/wg0.server.conf' does not exist
Mar 26 17:09:03 raspberrypi systemd[1]: wg-quick@wg0.server.service: Main process exited, code=exited, status=1/FAILURE
Mar 26 17:09:03 raspberrypi systemd[1]: wg-quick@wg0.server.service: Failed with result 'exit-code'.
Mar 26 17:09:03 raspberrypi systemd[1]: Failed to start wg-quick@wg0.server.service - WireGuard via wg-quick(8) for wg0.server.
$ journalctl -xeu wg-quick@wg0.server.service
Mar 26 17:09:03 raspberrypi systemd[1]: Starting wg-quick@wg0.server.service - WireGuard via wg-quick(8) for wg0.server...
░░ Subject: A start job for unit wg-quick@wg0.server.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit wg-quick@wg0.server.service has begun execution.
░░
░░ The job identifier is 120.
Mar 26 17:09:03 raspberrypi wg-quick[1350]: wg-quick: `/etc/wireguard/wg0.server.conf' does not exist
Mar 26 17:09:03 raspberrypi systemd[1]: wg-quick@wg0.server.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit wg-quick@wg0.server.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Mar 26 17:09:03 raspberrypi systemd[1]: wg-quick@wg0.server.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit wg-quick@wg0.server.service has entered the 'failed' state with result 'exit-code'.
Mar 26 17:09:03 raspberrypi systemd[1]: Failed to start wg-quick@wg0.server.service - WireGuard via wg-quick(8) for wg0.server.
░░ Subject: A start job for unit wg-quick@wg0.server.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit wg-quick@wg0.server.service has finished with a failure.
░░
░░ The job identifier is 120 and the job result is failed.
I can't find anyone online about the missing file /etc/wireguard/wg0.server.conf. is it meant to be /etc/wireguard/wg0.conf instead?
wg-quick up wg0 on its own works, but a job for wg-quick@wg0 fails
Your description of slow DNS responses when connecting via Wireguard seems to indicate a Wireguard or routing issue.
However:
Above output indicates that Wireguard fails to start at all.
In that case, rather than being slow, there would be no DNS resolution at all for the machine connecting via Wireguard?
Could you provide a fresh debug log, please? Your previous one has expired.
;; communications error to <server public ip>#53: connection refused
;; communications error to <server public ip>#53: connection refused
;; communications error to <server public ip>#53: connection refused
; <<>> DiG 9.20.20 <<>> @mydomain.com google.com
; (1 server found)
;; global options: +cmd
;; no servers could be reached
The service wg-quick@wg0.server.service isnt actuall meant to exist, which explains the service failing. disabled it and rebooted. dig command still has same output.
maybe its a timing issue, even though i already modified pihole config to wait 5 seconds, instead of the default of 0? unsure if the timing is being obeyed correctly
on a client i use AllowedIPs = 0.0.0.0/0, ::/0 instead of AllowedIPs = 10.100.0.1, fd08:4711::1, all internet connections timeout. normally they take a long time to resolve when connected to the vpn. when not connected to the vpn, dns is done at normal speed.
on a client when connected
$ dig @10.100.0.1 google.com
;; communications error to 10.100.0.1#53: timed out
;; communications error to 10.100.0.1#53: timed out
;; communications error to 10.100.0.1#53: timed out
; <<>> DiG 9.20.20 <<>> @10.100.0.1 google.com
; (1 server found)
;; global options: +cmd
;; no servers could be reached
on the server
# dig @10.100.0.1 google.com
; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> @10.100.0.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42583
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 21 IN A 173.194.79.100
google.com. 21 IN A 173.194.79.139
google.com. 21 IN A 173.194.79.138
google.com. 21 IN A 173.194.79.113
google.com. 21 IN A 173.194.79.102
google.com. 21 IN A 173.194.79.101
;; Query time: 0 msec
;; SERVER: 10.100.0.1#53(10.100.0.1) (UDP)
;; WHEN: Fri Mar 27 00:41:08 GMT 2026
;; MSG SIZE rcvd: 135
This looks like a Wireguard issue, rather than a Pi-hole one.
When successfully connected to a Wireguard VPN, a machine would be expected to communicate with DNS servers from its Wireguard configuration (e.g. 10.100.0.1 in your case).
Since you see a public IP here, that would indicate your machine isn't routing DNS through its Wireguard connection.
You should yerify that the machine's Wireguard connection is up and running, and that nothing on that machine redirects DNS traffic.
There is no active Wireguard connection.
If that machine had a connection, you'd see information on latest handshake and transferred data volumes, as extracable e.g. by sudo wg | grep -B2 -A1 latest.
On your other peer, you have:
A transfer of 0 indicates that the machine has not received anything yet.
It is sending data to its configured Endpoint = mydomain.com:51820, but hasn't completed a handshake yet (no latest handshake information).
Verify that
a. nslookup mydomain.com returns a set of public IPs that actually belongs to your router (or perhaps to your Wireguard machine in case of IPv6)
b. your router allows inbound port 51820 on those IPs
c. your router forwards IPv4 port 51820 to your Wireguard machine (and perhaps also IPv6, in case your mydomain.com points to your router's instead of your Wireguard machine's IPv6)
d. your Wireguard machine allows inbound port 51820
At least d. doesn't seem to be the case at the moment:
Your ufw status output is missing port 51820.
As this isn't a Pi-hole issue, you may want to also consider consulting Wireguard's documentation and support for more knowledgable assistance.
