I'm wondering if my pi-hole installation is working correctly with IPv6 because i noticed some things. I had to reinstall my raspberry pi some time ago. Since then only a relative low number of IPv6 queries occur in comparison to my installation before.
If i try 'dig -6 google.com' on any windows machine i get timeouts:
dig -6 google.com
; <<>> DiG 9.16.13 <<>> -6 google.com
;; global options: +cmd
;; connection timed out; no servers could be reached
Is it possible that IPv6 requests are blocked via firewall or something. Do i have to add some iptable rules? The query from raspberry pi does show up in the pihole.log, query from windows machine doesn't.
Your debug log shows your Pi-hole to be fully operational for both IPv4 and IPv6 (click for log excerpt)
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] pe-east.intentiq.com is 0.0.0.0 via localhost (127.0.0.1)
[✓] pe-east.intentiq.com is 0.0.0.0 via Pi-hole (192.168.0.2)
[✓] doubleclick.com is 172.217.23.14 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] p279274.clksite.com is :: via localhost (::1)
[✓] p279274.clksite.com is :: via Pi-hole (fd00::70fc:7114:a1f6:9b24)
[✓] doubleclick.com is 2a00:1450:4016:806::200e via a remote, public DNS server (2001:4860:4860::8888)
Also, your IPv6 DNS server address from ipconfig correctly matches that currently in use by your Pi-hole host.
Note that dig -6 will force to use IPv6 for sending a DNS request for an A record to your default DNS server (i.e. Pi-hole). You'd have to use e.g. dig google.com AAAA to get an IPv6 resolution result.
Then again, neither of those options would affect the "Queries answered by" diagram, as that is showing how Pi-hole itself has retrieved a DNS answer, including which upstream DNS server it used. Pi-hole may decide to forward a query for a client's dig request to any of its upstreams, i.e. it may go to an IPv4 address now and to an IPv6 address with the next request, completely independent of how that request was received and what type of record was requested.
So there is no reason for concern at all with the diagram.
But the fact that your client's attempts to resolve DNS requests via IPv6 results in a timeout would suggest that something is blocking IPv6 from reaching Pi-hole.
This could well be your firewall on your Pi-hole host (likely) or on the affected client (unlikely).
By the above explanations, it should also be obvious that this wouldn't stop your clients from successfully requesting AAAA records and retrieving IPv6 addresses via Pi-hole.
This will work unhampered via IPv4.
Blocking IPv6 ports may indeed help to avoid seeing a diverse set of IPv6 addresses being listed in Pi-hole's Query Log, which could make client identification easier.
So as long as there is no other IPv6 DNS server available on your network, that would be a valid configuration.
However, to avoid risking a slow down in IP resolution (specifically for clients that prefer IPv6 over IPv4), you'd probably want to stop distributing an IPv6 DNS server address.in that case.
Thanks for your fast reply. It is a relief to hear that my installation is partially working properly.
Thanks. I'm aware of that. Out of all four possible query types (IPv4 A, IPv4 AAAA, IPv6 A, IPv6 AAAA) i would like to be able to use all of them. Interestingly if i define the pi-hole as host in the dig command it will work on a windows machine aswell:
I used a fresh install, added pi-hole, unbound, privoxy and some other software for smart home (homebridge, mosquitto, influx) but i never edited the iptables. Do you think i have to add some routes/rules on the raspberry? My router is an AVM FritzBox 7490, as far as i know i cannot edit the iptables there.
I would like to offer DNS via IPv6 for my clients aswell. Therefore blocking the ports is not really an option for me.
There aren't four query types. There's a query for an A record and a query for an AAAA record. IP versions don't have any relation or affect on the query type. A records return an IPv4 address and AAAA records return an IPv6 address but that's the limit of it. An IPv6 client can request an A record but it's not going to provide any useful response. An IPv4 client can request an AAAA record but that will not likely be of any use, unless they are dual-stack clients.
My ISP is providing me a dual stack, i activated IPv6 support in my router and do not restrict any IPv6 usage troughout my network. Therefore all clients should be dual stack and could use all mentioned types of queries or am i missing something?
If your clients are dual stack then they have IPv4 addresses and can communicate with Pi-hole over IPv4. IPv4 clients can request AAAA records over IPv4 and use the resulting IPv6 response when reaching the remote target domain over IPv6.
A pure IPv4 client can also ask for AAAA records but that would not help it. That actually happens in many OSes by default.
You don't need to have and IPv6 DNS resolver to get an AAAA records. There is not requirement for a record type to be answered by a specific protocol type.
That would suggest that DNS traffic is flowing freely from your client to Pi-hole via IPv6.
I realise just now that you are using dig in Windows. As dig isn't available in Windows natively, your observation may be related to the dig implementation you are using.
That's just a guess, I am not familiar with dig on Windows at all.
(I recall trying to install ISC BIND tools for Win7 at some time in the past, which wasn't successful then.)
I think i fully understand that. But wouldn't it be nice if a client could use every query type via every protocol it wishes to?
Two things are triggering me:
With my last installation the queries answered by both protocol types were more like 50:50. Which somehow makes sense if i assume the distribution between the usage of each protocol is the same. Maybe that distribution was random and does not indicate anything.
dig -6 does timeout on any windows 10 machine (IP via DHCP) in my network if i do not specify the server via @pi.hole for example.
My approach is to check if pi-hole is 100% working on all protocols with all query types. Therefore i try to understand what exactly my pi-hole is doing.
On the other hand i get a lot of ipv4only.arpa queries from my apple devices since some days. As far as i understand it right now that query is used for DNS64 (NAT64). Therefore i assume something could not work as it should because it tries to translate between these protocols. If i'm understanding NAT64 correctly a IPv6 host is trying to talk to a IPv4 server. That could mean all apple device would kind of prefer IPv6 on my network and they are using ipv4only.arpa to get the translation prefix.
Could anybody reproduce the dig-issue on a W10 machine aswell or does anyone have an idea how i could test A and AAAA queries via IPv4 and IPv6 reliably?
You are right, dig is not natively supported on windows 10. I had to download the BIND software from https://www.isc.org/bind/. Just unzip the archive and call dig via command line within the BIND folder.
I don't think so.
I already explained that your diagram does not offer any support for that assumption, as it has nothing to do with the way your clients have queried Pi-hole. You'd have to analyse your long term database for client IP address distribution to find out whether that assumption is justified.
In addition, you wouldn't lose any functionality if you'd remove ::1#5335 from your Pi-hole's upstream DNS servers: Even if all of your clients were IPv6 only, Pi-hole would be able to correctly provide DNS resolution by using just 127.0.0.1#5335 as its only upstream (or vice versa for IPv4).
And back on topic:
As it works on your Pi-hole host, as well as on your Windows clients if you explicitly provide a DNS server, I believe that to be a flaw of the Win10 dig implementation.
Forcing your dig through Pi-hole as DNS server is a reliable test, and that was successful in your case.
dig -6 failing when not specifying a DNS server would suggest that the default DNS server picked by your OS or by dig isn't reachable via IPv6.
Since you've cross-checked that all IPv6 addresses your Win10 client reports as DNS server are associated to your Pi-hole host machine, you've ruled out that Pi-hole would be by-passed.
Instead of using Pi-hole's hostname, you could try to provide each of your Pi-hole hostmachine's IPv6 addresses individually.
If they all would work, that would support my guess that dig itself may be at fault.
Out of all four possible query types (IPv4 A, IPv4 AAAA, IPv6 A, IPv6 AAAA) i would like to be able to use all of them. Interestingly if i define the pi-hole as host in the dig command it will work on a windows machine aswell: