Persistent issues with Pi-hole 6: DNS fails every 3-6 hours

I encountered a problem with my Pi-hole (version 6), which regularly hangs every 10-20 seconds. During these interruptions, no DNS queries are resolved, significantly disrupting my network and affecting internet availability. Although a similar issue in Pi-hole version 6 had been resolved before, the current solution seems ineffective. I have already tried a full reinstallation of Unbound along with Pi-hole, but the problem persists. Moreover, the issue with Unbound occurs even when I use other DNS servers, such as 1.1.1.1 or 8.8.8.8

I would also like to inquire about the possibility of disabling IPv6 in the Pi-hole DHCP settings. When DHCP assigns IPv6 addresses to devices in the network, DNS queries are not routed through Pi-hole, resulting in no pages being blocked. I have tested this multiple times. My router does not offer the option to disable IPv6. The DHCP functionality in the latest version seems to be underdeveloped. When I correctly configured DHCP in Pi-hole (of course with disabling DHCP on my router), and restarted the server running Pi-hole, the server lost internet connection. It could not recognize the router gateway. I resolved the problem by changing the configuration in netplan - I set dhcp4 to false and assigned the appropriate gateway addresses and name servers. In this case, every time the server restarted, it always had an internet connection.

I would be grateful for any observations or suggestions on how to resolve these issues.

  • Core vDev (development-v6, 5d77c2b3)
  • FTL vDev (development-v6, 1b71a440)
  • Web interface vDev (development-v6, 9162f39c)

image

Server:

Without a proper Debug Log, we only have your screenshots information.

Your screenshot shows Pi-hole forwarded the query to Unbound: image

But Unbound never answered: image

You need to find out why unbound is not answering.

1 Like

Adding to what has been said before:

Simply disable this check box:


Do you see similar issues as the ones pointed out by @rdwebdesign ? Queries being forwarded but no replies ever arriving? It may point to an interface or routing issue on your device that we can try to debug together.

No, this is a simple misunderstanding: The DHCP server cannot serve itself with an address. The DHCP server itself always needs a static address - which is what you have done and it immediately started working as expected.

1 Like

This checkbox is unchecked. Despite this, Pi-hole still serves IPv6 to every device on the network. If any DNS query goes through IPv6, Pi-hole completely ignores it.

please see this video

As for Unbound, I have now changed the DNS settings to 1.1.1.1 & 1.0.0.1 in pihole for tests
Thanks for your reply

UPDATE: I have the same issue with 1.1.1.1 & 1.0.0.1.



some error

debug log

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

screenshots


image

If the box is uncheched, Pi-hole won't do anything concerning IPv6 addresses. It is likely your Internet router that is still managing IPv6 and - not knowing anything about Pi-hole - it serves IPv6 configuration that is problematic in your case.


Your debug log reveals a few strange issues:

  • You are receiving DHCP data from three servers:

    • 169.254.248.190 (your Pi-hole) <---- this address shouldn't be there
    • 192.168.2.112 (your Pi-hole)
    • 192.168.2.186 (something else)
  • There is also a warning about address conflicts in your Pihole diagnosis messages:

    Not using configured address 192.168.2.112 because it is in use by the server or relay

    (you have seen this already)

  • Your query log (/var/log/pihole.log) shows a number of successful lookups, e.g. screenshots.sefinek.net so it is not all queries that are failing.

  1. I'd next start trying to debug why there is the extra 169.254.x.y address - likely it comes from a faulty state of the DHCP server in your router.
  2. Then, we need to find out who is 192.168.2.186 and why they are sending DHCP packets around your network.
  3. And finally, I'd like you to tripple-check your Pi-hole really has a statically defined IP address. Maybe it is some completely Pi-hole-unrelated issue going on with the interface itself that is causing the issues with packets being sent but never received.
    During the generation of your debug log, we have seen many queries that worked (actually, not a single one that did not work) and also all other connectivity tests (despite IPv6 into the Internet, which is not important here) were okay.
1 Like

unfortunately, I don't have the option to disable IPv6 in my router. Iam using Huawei B818-263

I really don't know who 192.168.2.186 is. None of my devices have such an IP address assigned

Usually, the DNS fails regularly every 3-6 hours

I am 100% sure that Pi-hole has a static address assigned, as I connect daily to this server on the local network via SSH using the same IP address (192.168.2.112)

sefinek@hp-terminal1:~$ cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
      link-local: ['ipv4']
      addresses: [192.168.2.112/24]
      gateway4: 192.168.2.1
      nameservers:
        addresses: [127.0.0.1]
  version: 2

Generating the debug log took less than a minute, but the DNS fails every 3-6 hours in my case

Thanks for help

So this is a problem. Have you tried disabling IPv6 on the system-level of one of your network devices just to rule out that the intermittent DNS failure is down to this client flipping over to IPv6 for name resolution? The most obvious candidate would be your Pi-hole to see if the intermittent issues that no upstream DNS provider replies gets resolved like this.

Just to be clear: I'm not proposing this as the final solution here but rater something we can use to confirm/rule out a whole lot of issues that have a lot in common.

DHCP is not the problem, nor is my router. I had the same issue on my previous Huawei B525 router, even when I wasn't using DHCP from Pi-hole. Just now, the DNS got clogged up again, and I lost a potential client because my server couldn't establish a connection with Stripe and threw a 500 error on the site. Really thanks :smile:

12:06:59.260 30.04.2024: [Subscription]: StripeConnectionError: An error occurred with our connection to Stripe. Request was retried 1 times.
12:06:59.261 30.04.2024:     at XXXX/node_modules/stripe/cjs/RequestSender.js:326:37
12:06:59.261 30.04.2024:     at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
12:06:59.261 30.04.2024:   type: 'StripeConnectionError',
12:06:59.261 30.04.2024:   raw: {
12:06:59.261 30.04.2024:     message: 'An error occurred with our connection to Stripe. Request was retried 1 times.',
12:06:59.261 30.04.2024:     detail: Error: getaddrinfo EAI_AGAIN api.stripe.com
12:06:59.261 30.04.2024:         at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:118:26) {
12:06:59.261 30.04.2024:       errno: -3001,
12:06:59.261 30.04.2024:       code: 'EAI_AGAIN',
12:06:59.261 30.04.2024:       syscall: 'getaddrinfo',
12:06:59.261 30.04.2024:       hostname: 'api.stripe.com'
12:06:59.261 30.04.2024:     }
12:06:59.261 30.04.2024:   },
12:06:59.261 30.04.2024:   rawType: undefined,
12:06:59.261 30.04.2024:   code: undefined,
12:06:59.261 30.04.2024:   doc_url: undefined,
12:06:59.261 30.04.2024:   param: undefined,
12:06:59.261 30.04.2024:   detail: Error: getaddrinfo EAI_AGAIN api.stripe.com
12:06:59.262 30.04.2024:       at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:118:26) {
12:06:59.262 30.04.2024:     errno: -3001,
12:06:59.262 30.04.2024:     code: 'EAI_AGAIN',
12:06:59.262 30.04.2024:     syscall: 'getaddrinfo',
12:06:59.262 30.04.2024:     hostname: 'api.stripe.com'
12:06:59.262 30.04.2024:   },
12:06:59.262 30.04.2024:   headers: undefined,
12:06:59.262 30.04.2024:   requestId: undefined,
12:06:59.262 30.04.2024:   statusCode: undefined,
12:06:59.262 30.04.2024:   charge: undefined,
12:06:59.262 30.04.2024:   decline_code: undefined,
12:06:59.262 30.04.2024:   payment_intent: undefined,
12:06:59.262 30.04.2024:   payment_method: undefined,
12:06:59.262 30.04.2024:   payment_method_type: undefined,
12:06:59.262 30.04.2024:   setup_intent: undefined,
12:06:59.262 30.04.2024:   source: undefined
12:06:59.262 30.04.2024: }```

Okay, so what is the problem?

My current point of view is: You cannot disable IPv6 on the router, IPv6 can configure nameserver details so let's try disabling IPv6 for a moment. I did not mention anything about DHCP, we have sorted this before (you have a static address configuration).

Bruh, You are the Pi-hole developer, not me (:
Something is simply wrong with Pi-hole. Regarding my earlier statement that you quoted, I was referring to DHCP in the context that it is not the cause of DNS fails.

IPv6 is also disabled on all my devices because Pi-hole stops blocking sites that are on the blacklist when it is enabled.
Regarding the static address, it needs to be enforced on my server because, for some reason, after restarting, I have to manually assign both the gateway and the IP address of the server myself. This is because the Pi-hole DHCP cannot assign these automatically, even though it runs on the same device.

The best solution, I think, would be to downgrade to an older version of Pi-hole until you fix this. I don't have such problems with Pi-hole 5.


DNS failures occur even on the same server that has Pi-hole installed, despite the server having a static IP address configured in Netplan.

DNS failures also happen when I use DHCP from the router. Even when the router assigns IPv6 to devices, Pi-hole ignores DNS queries - resolves them, but fails to block domains that are on the blacklist.

video:


:joy:

This is expected, network configuration happens before the DHCP server is up. All DHCP server hosts always need to be configured manually.


Don't get me wrong. I know that this is a problem that needs to be sorted but so far we have not been able to identify the cause. Looking at the feedback we got so far we can safely assume to have somewhere between 100 and 500 beta testers and - yet - you are the only one with this problem. We are still here investing all resources to try to find the cause and fix it for you as fast as possible.

The next thing wo look at will be:

  • Please provide some log lines from /var/log/pihole/FTL.log and /var/log/pihole/pihole.log once the outage happens
  • Please check if auxiliary tools on the same server can still resolve names at the time it stops working in Pi-hole, e.g. using something like
     dig google.com @8.8.8.8
    
1 Like

It's good to know, thank you

I appreciate it, thanks

A DNS failure just occurred with Pi-hole. I executed the command dig api.sefinek.net @127.0.0.1 and my site's IP was not resolved at all. When I executed dig api.sefinek.net @8.8.8.8, I received the result immediately.

It appears the fault lies with Pi-hole. Please fix it.

sefinek@hp-terminal1:~$ sudo cat /var/log/pihole/FTL.log
2024-05-02 02:44:21.096 [83121/T149324] INFO: Optimized database in 0.035 seconds

/var/log/pihole/pihole.log

May  2 21:42:44 dnsmasq[83121]: query[A] api.sefinek.net from 127.0.0.1
May  2 21:42:44 dnsmasq[83121]: forwarded api.sefinek.net to 127.0.0.1#5335
May  2 21:42:49 dnsmasq[83121]: query[A] api.sefinek.net from 127.0.0.1
May  2 21:42:49 dnsmasq[83121]: forwarded api.sefinek.net to 127.0.0.1#5335
May  2 21:42:59 dnsmasq[83121]: query[A] api.sefinek.net from 127.0.0.1
May  2 21:42:59 dnsmasq[83121]: forwarded api.sefinek.net to 127.0.0.1#5335
May  2 21:43:03 dnsmasq[83121]: reply api.sefinek.net is 188.114.97.4
May  2 21:43:03 dnsmasq[83121]: reply api.sefinek.net is 188.114.96.4

This log you posted shows that the error is within your local unbound not replying for some time. Please enable logging in unbound and also show its logs as we will need to fix the error here.

I already wrote to you that the same issue occurs when I set DNS 1.1.1.1 & 1.0.0.1 in Pi-hole. I feel like you're not reading my messages carefully. Please don't waste my time

SEE THIS SCREENSHOT AGAIN

We're trying to help you. You latest logs show that your Pi-hole is asking your unbound. If doesn't reply. Hence, it was the next logical step to check unbound.

In the end, it is likely that your machine loses Internet connection for a brief period of time and it was back up once you tested manually so you didn't notice it.

I'm sorry you had the feeling we are wasting your time. We won't continue this. Please stop using the beta.

2 Likes