Pi-hole DNS Resolver timing out intermittently

[Highside1100]

Hi,

I recently migrated my pihole config from a dedicated physical machine running ZorinOS (ubuntu based) to a VM. I keep getting DNS_PROBE_FINISHED_BAD responses network wide every 30 minutes on average. It is like services are hanging or the vNIC stops transferring traffic and DNS becomes unavailable for 10-15 seconds.

Pihole is now running within Ubuntu Server 22.04LTS, With the ubuntu desktop environment installed. The VM is hosted by a Mac Mini M1 2020 running VMware Fusion. Pihole is running as a DNS resolver and DHCP server, with DHCP disabled on my gateway router.

I first want to verify if there is any issues with the pi-hole configuration or anything as such in its logs. My token is m6znyzQD

Can someone please help ?

[Bucking_Horn]

@Highside1100

DNS_PROBE_FINISHED_BAD

If that would read DNS_PROBE_FINISHED_BAD_CONFIG, then that would likely be an error message produced by a Chromium based browser.
If that would be the case, then this may also indicate an issue with DNS configuration of the machine that runs that browser.

Your debug log shows that your time is jumping a lot in your VM:

*** [ DIAGNOSING ]: contents of /var/log/lighttpd

-rw-r--r-- 1 www-data www-data 12K Oct 13 18:13 /var/log/lighttpd/error-pihole.log
(...)
    -----tail of error-pihole.log------
   2023-10-12 23:17:16: (server.c.2057) server stopped by UID = 33 PID = 6160
   2023-10-12 23:17:16: (server.c.1551) server started (lighttpd/1.4.63)
   2023-10-12 23:31:28: (server.c.256) warning: clock jumped 411 secs
   2023-10-13 03:20:25: (server.c.256) warning: clock jumped 911 secs
   2023-10-13 03:54:25: (server.c.256) warning: clock jumped 865 secs
   2023-10-13 04:16:50: (server.c.256) warning: clock jumped 585 secs
   2023-10-13 04:34:35: (server.c.256) warning: clock jumped 765 secs
   2023-10-13 04:51:04: (server.c.256) warning: clock jumped 867 secs
   2023-10-13 05:22:02: (server.c.256) warning: clock jumped 1459 secs
   2023-10-13 06:02:54: (server.c.256) warning: clock jumped 810 secs
   2023-10-13 06:32:56: (server.c.256) warning: clock jumped 825 secs
   2023-10-13 06:54:40: (server.c.256) warning: clock jumped 907 secs
   2023-10-13 07:13:32: (server.c.256) warning: clock jumped 900 secs
   2023-10-13 07:36:32: (server.c.256) warning: clock jumped 767 secs
   2023-10-13 07:56:20: (server.c.256) warning: clock jumped 577 secs
   2023-10-13 08:22:29: (server.c.256) warning: clock jumped 888 secs
   2023-10-13 08:57:02: (server.c.256) warning: clock jumped 869 secs
   2023-10-13 09:20:02: (server.c.256) warning: clock jumped 690 secs
   2023-10-13 09:51:18: (server.c.256) warning: clock jumped 328 secs
   2023-10-13 10:00:34: (server.c.256) warning: clock jumped 874 secs
   2023-10-13 10:23:40: (server.c.256) warning: clock jumped 863 secs
   2023-10-13 11:07:23: (server.c.256) warning: clock jumped 959 secs
   2023-10-13 15:56:18: (server.c.256) warning: clock jumped 1209 secs
   2023-10-13 17:29:33: (server.c.256) warning: clock jumped 1307 secs
   2023-10-13 17:59:20: (server.c.256) warning: clock jumped 831 secs

Correct timing information is absolutely critical for DNSSEC validation.
If time is off by too much, all DNSSEC validations will fail, and DNS resolution won't be possible until time is re-synced or manually corrected.

As your debug log shows you've enabled DNSSEC in Pi-hole, that could well explain your observed outages, particularly if you could successfully correlate your observations with the times from the log.

This seems like some misbehaviour of the VM, either not getting correct timing information from the host OS, or ticking away its own system clock too fast.

And likely unrelated to your issue, but I noticed that you once had enabled Pi-hole's Conditional Forwarding using local as the domain name.
If that would still be relevant, you should be aware that .local is reserved for use by the mDNS protocol and should NOT be used with DNS.

[Highside1100]

Hi,

Thank you so much for highlighting that issue. I didn't notice that the times were out of sync. You're correct , the hypervisor was not syncing the host OS's time correctly. I've turned off the sync between the hypervisor/OS and the VM guest OS and I am now relying on ubuntu's default time servers within the guest OS.

Also, noted regarding the .local reservation - good to know.

Cheers