Expected Behaviour:
No queries from client 'localhost' for domain 'enp2s0' in the given scenario.
Actual Behaviour:
Been running a pi-hole / dnscrypt-proxy combo in Linux (Pop OS) on a Linux / Windows 11 dual boot box for about a week now, and noticed the following behavior once the connection to the Internet is lost (router down for example).
In that scenario, DNS queries like the following are constantly taking place at an excessive rate (~ 9.500/hr), being logged as follows:
Time Type Domain Client Status Reply
2023-11-10 01:40:00 AAAA enp2s0 localhost OK (cache) INSECURE NXDOMAIN (0.1ms)
2023-11-10 01:40:00 A enp2s0 localhost OK (cache) INSECURE NXDOMAIN (0.1ms)
2023-11-10 01:40:00 AAAA enp2s0 localhost OK (cache) INSECURE NXDOMAIN (0.0ms)
2023-11-10 01:40:00 A enp2s0 localhost OK (cache) INSECURE NXDOMAIN (0.1ms)
2023-11-10 01:40:00 AAAA enp2s0 localhost OK (cache) INSECURE NXDOMAIN (0.1ms)
2023-11-10 01:40:00 A enp2s0 localhost OK (cache) INSECURE NXDOMAIN (0.1ms)
'enp2s0' being the primary (and only enabled) network interface.
In pihole.log it looks like this:
Nov 10 01:40:00 dnsmasq[12158]: query[AAAA] enp2s0 from 127.0.0.1
Nov 10 01:40:00 dnsmasq[12158]: config enp2s0 is NXDOMAIN
Nov 10 01:40:00 dnsmasq[12158]: query[A] enp2s0 from 127.0.0.1
Nov 10 01:40:00 dnsmasq[12158]: config enp2s0 is NXDOMAIN
Nov 10 01:40:00 dnsmasq[12158]: query[AAAA] enp2s0 from 127.0.0.1
Nov 10 01:40:00 dnsmasq[12158]: config enp2s0 is NXDOMAIN
Nov 10 01:40:00 dnsmasq[12158]: query[A] enp2s0 from 127.0.0.1
Nov 10 01:40:00 dnsmasq[12158]: config enp2s0 is NXDOMAIN
Nov 10 01:40:00 dnsmasq[12158]: query[AAAA] enp2s0 from 127.0.0.1
Nov 10 01:40:00 dnsmasq[12158]: config enp2s0 is NXDOMAIN
Nov 10 01:40:00 dnsmasq[12158]: query[A] enp2s0 from 127.0.0.1
Nov 10 01:40:00 dnsmasq[12158]: config enp2s0 is NXDOMAIN
So my questions are:
Why does it do that (trying to resolve the NIC's name as a domain?!), and how to prevent it?
The pi-hole is almost flooded by those queries, sporadically a diagnostic message is being recorded stating just that.
Remarks:
- Apart from this issue, the pi-hole is just running fine as far as I can tell - no problems at all.
- Once the Internet connection is back up again, the problem immediately goes away.
- I'm alternatively running another pi-hole / dnscrypt-proxy on the same machine in a Docker container under Windows 11 (utilizing the Windows Subsystem for Linux) with a very similar configuration, which doesn't exhibit this behavior at all.