Please follow the below template, it will help us to help you!
Expected Behaviour:
PiHole only resolves IPv4 addresses because my ISP won't allow me to have an IPv6 address at all. IPv6 addresses aren't given out on my network. Everything uses IPv4 and doesn't complain.
(I blame my terrible ISP for this, too. They just won't allow IPv6 at all.)
Actual Behaviour:
PiHole is resolving mixed IPv4/IPv6 addresses and causing all clients to constantly fail to connect because IPv6 is unsupported. I have disabled every single PiHole IPv6 option I can find, the PiHole doesn't even have an IPv6 address and I've disabled IPv6 explicitly on my host to no avail.
PiHole is running on a Raspberry Pi & is being used as my DNS + DHCP server. My ISP-provided router does not support IPv6 at all. This has occurred before switching to the beta/dev branch, ever since installing PiHole. (Maybe a couple weeks ago now)
This is incredibly infuriating, and I would love some help. I don't know what I'm doing wrong.
I noticed this in my debug log, but PiHole is acting as my DHCP server. IPv6 is disabled in the PiHole DHCP settings and the PiHole itself is on a network that doesn't support IPv6 at all. Is this a flaw of Raspbian? However in my PiHole's System information, it doesn't show an IPv6 address for itself at all.
So after reading my own debug log, I found out that my Raspberry Pi on Raspbian decided to make a completely ghost IPv6 address for itself. I followed the instructions from this page.
I will mark my own issue as resolved after a day or so of use, if my issues have been resolved from this fix.
Either way, this might be an issue that PiHole can attempt to avoid - this was on a fresh installation of Raspbian Stretch and I have no clue why it made a ghost IPv6 address for itself on a network that only supports IPv4.
Maybe PiHole should actually make sure that IPv6 addresses are resolvable and Raspbian is not being a derp.
The IPv6 address assigned to eth0 in your log was not created by Pi-hole.
Even though your ISP does not support IPv6, chances are pretty much any computer running on your home system does. Not only raspbian, but most linux distros have shipped with IPv6 enabled out of the box for some time. Current android phones have it enabled also. Likewise on apple and microsoft systems.
The address from your log is a Link-local address. Which can only be used to communicate with other systems on your local network, and not with the wider internet. They are assigned automatically by the operating system, and can be disabled in the manner you described.
I've always called them local/external IP addresses. What's the difference between a local address and a link-local one?
Does IPv6 not require DHCP to assign local addresses? I'm guessing there are so many IPv6 addresses that it's easier for clients to just pick one and broadcast it using an ARP broadcast or something similar?
I'm still having issues, even with IPv6 on eth0 disabled.
Should I disable v6 link-local addresses on all clients on my network? That seems quite tedious.
The majority of my network are Linux machines, with one Windows dual-boot that's rarely ever used.
Link-local addresses are not able to be routed out of the network segment. Unlike IPv4, they are mandatory in IPv6. To complicate matters there is also an address class known as Unique local addresses. So calling an IPv6 address "local" is not specific as to which type.
IPv4 had private address ranges, eg 192.168.1.0/255 which many people referred to as local. But private address ranges as such don't exist in IPv6.
Addresses in IPv6 are typically (but not always) supplied using the Neighbour Discovery Protocol, rather than DHCP.
The AAAA queries, even though returning IPv6 information, are being generated in response to IPv4 requests. All of the operating systems discussed will still make these queries even if you disable IPv6 connectivity.
Ah, I see. I'm not experienced with IPv6, so my apologies. Do you have any idea why I keep getting DNS resolution errors on multiple clients, but it generally works after retrying 1-2 times?
I didn't have this issue before I started using a PiHole.
Forwarded requests are when Pi-hole is neither blocking them, nor has a copy of the data cached, so it hands it on to your upstream server (which then sends back the result).
I can't see anything in your debug data that would be causing it to time out (the upstream dns servers you have chosen are generally fast and reliable).
IPv6 really is a whole other world. With so many of the concepts and much of the terminology being so-close-but-not-quite what everyone is familiar with from IPv4, it can lead to confusion. (It did for me at first). One free resource that I heartily recommend to anyone wanting to learn more is the Hurricane Electric IPv6 Certification Project
They also offer a Free IPv6 Tunnel Broker service that you can use to get full IPv6 connectivity on your network even if your ISP doesn't want to play along.
Ah. I unchecked these to see if it would stop the resolution errors on my clients. This might've caused a separate issue. I've checked both of them again, since I use PiHole for DNS + DHCP.
The queries took a few seconds because the upstream DNS server took a few seconds to resolve the query (or your connection to the servers is bad).
Are you sure you are looking at the right queries? A URL (https://pi.hole/admin) is not a domain, and so of course it returns the NXDOMAIN response (no such domain found). Also, if you are trying to visit the web interface over HTTPS, that will not work because it is only available over HTTP. I haven't seen any indication from your logs that Pi-hole is resolving things incorrectly, only that it has a bad connection to upstream servers or is getting bad DNS requests.
The issue I'm trying to pin down is very hard to reproduce artificially. I'm getting occasional failures with curl or GitHub clones or even my package manager and I have to repeat the command for it to actually work. Browsing the web is usually perfect, but sometimes it hangs on "Looking up ..." for several seconds, sometimes timing out.
Just now it took ~15 seconds for DuckDuckGo's homepage to load and then it seemed perfectly fine afterwards. That's why I originally thought it could be an IPv6 issue or a caching issue, but I'm really not sure.
I recorded directly after this happened. I didn't get to capture my browser freezing on "Looking up DuckDuckGo.com..." in the corner for ~15 seconds. The PiHole doesn't seem to be having any sort of slow down in the query logs, but all the clients on my network keep getting these failures to connect and then it works perfectly afterwards.
[Edit]
Even trying to watch my own YouTube video caused this issue. YouTube took maybe 5 seconds or more to actually resolve correctly, which you can see in the timestamps on the left.
[Double Edit]
It's very odd and intermittent. Sometimes things are super snappy and load instantly and then other times they're so incredibly slow that it times out & fails to connect. I think it happens more often when a website hasn't been cached, but PiHole reports the Upstream DNS query taking relatively few milliseconds. It's as if PiHole is forgetting to respond to the original DNS request when it's not cached.
My internet connection is a really stable ~90 Mbps down and ~8 Mbps up.
Trying to do a speedtest for this even threw a similar error.
(Here's the associated full query log - https://pastebin.com/1B0Hx3y0)
This shouldn't be a hardware issue either. It's happening on several laptops using WiFi, my desktop using Ethernet and a couple of phones. I had no issues like this before I started using a PiHole.
The Raspberry Pi is also under minimal load (PiHole is the only thing running on it, not even an X display server) and it's plugged in directly to my router with an Ethernet cable.
In your tail of the pihole log, you have some interesting domains. You were searching for "DuckDuckGo.com" I assume, yet some of your A queries are for "DuckDuckGo.com.cave", all of which were returned as NXDOMAIN (i.e. that domain doesn't exist). I don't know if that is an artifact of your DHCP server on the PiHole (I note that your PiHole local domain name is "cave.") I don't run the DHCP feature on PiHole, so I'm not completely familiar with the behavior of the DHCP function.
Here is my tail of my pihole log for DNS lookup for DuckDuckGo for comparison. I use unbound as a local recursive resolver (127.0.0.1), so the PiHole is not going to third party DNS. Since DuckDuckGo wasn't in my cache, unbound had to go out on the internet to talk to authoritative servers to get the answer, thus the slow response for me (it was 220 msec). My PiHole is also not my DHCP server.
Jul 21 23:02:27 dnsmasq[29623]: 44673 192.168.0.135/63398 query[A] duckduckgo.com from 192.168.0.135
Jul 21 23:02:27 dnsmasq[29623]: 44673 192.168.0.135/63398 forwarded duckduckgo.com to 127.0.0.1
Jul 21 23:02:28 dnsmasq[29623]: * 192.168.0.135/63398 dnssec-query[DS] duckduckgo.com to 127.0.0.1
Jul 21 23:02:28 dnsmasq[29623]: * 192.168.0.135/63398 reply duckduckgo.com is no DS
Jul 21 23:02:28 dnsmasq[29623]: 44673 192.168.0.135/63398 validation result is INSECURE
Jul 21 23:02:28 dnsmasq[29623]: 44673 192.168.0.135/63398 reply duckduckgo.com is 184.72.104.138
Jul 21 23:02:28 dnsmasq[29623]: 44673 192.168.0.135/63398 reply duckduckgo.com is 23.21.193.169
Jul 21 23:02:28 dnsmasq[29623]: 44673 192.168.0.135/63398 reply duckduckgo.com is 107.20.240.232
You are clearly getting intermittent delays, so let's try to figure out if it's the Pihole or something else.
Run "dig duckduckgo.com @1.1.1.1" - this will directly go to the Cloudflare DNS and bypass your PiHole.
Run "dig duckduckgo.com" - this will query the DNS through your PiHole to Cloudflare since you have 1.1.1.1 and 1.0.0.1 as your upstream resolvers.
Repeat the above commands but substitute in a domain you have never searched for in the past (try motortrend.com if you aren't a gearhead).
Take one of your clients that is experiencing delays off the PiHole - put in a manual DNS address of 1.1.1.1, clear the DNS cache on that device, and see if browsing speeds up.
Where are you getting the time of 10 sec? What software or device is reporting this time? It looks like all your DNS replies are reasonably fast (< 30 msec). Nothing unusual there.
What hardware do you use for PiHole? SD card brand and size? Which OS? Was this a clean install of OS and PiHole on the Pi or was PiHole added onto an existing OS installation? Do you have any other ethernet devices connected to the router, and if so does their speed appear normal?
10 seconds is how long it took for the dig command to complete according to my terminal. All the other dig commands took <1 second and wasn’t displayed in my terminal’s prompt as a result.
Hardware: Raspberry Pi 1 Model B rev2.0 SD Card: 32 GB Sandisk Generic Blue SD Card. 18% full. OS: Raspbian Stretch 9.4 Latest updates. I fully update/upgrade roughly once a week. Running in headless mode without a GUI.
OS install is completely new with PiHole. Other than PiHole, all I’ve done is copy my sshd_config and install Zsh shell.
Network: ~4 laptops, 3 phones connected using WiFi experiencing the same issue.
Raspberry Pi and my desktop connected via Ethernet. Raspberry’s Pi’s network speed caps at about 45 Mbps (This is apparently normal) and desktop gets a stable 90 Mbps down and 8 Mbps upload.
Overall system load
Pretty low levels of network load at any given time (2-3 users max). Raspberry Pi also has very low CPU usage and memory usage in htop. The only thing my Raspberry Pi is running is PiHole.
Approx average CPU for Raspi is ~5%, memory usage is at 87.9MB/433MB.
