Pihole returning IPv6 addresses (I think) causing problems

I hate to ask this question because it’s so similar to others but they don’t seem to match my problem.

I upgraded from v5 to v6 a while ago and some local DNS entries now don’t work properly intermittently. I’m guessing because they’re returning IPv6 addresses which are sometimes used (although I don’t know a lot about IPv6). It had been working on v5 for ages.

My setup has a Cloudflare tunnel pointing ha.example.co to NGNIX Proxy Manager, which then sends it to 192.168.0.174:8123. This works fine externally. Internally I have a local DNS for ha.example.co also pointing to NGINX Proxy Manager. As shown below, IPv6 addresses are being returned despite (I think) IPv6 being disabled.

$ nslookup ha.example.co pihole-2.example.co
Server:         pihole-2.example.co
Address:        192.168.0.62#53

Name:   ha.example.co
Address: 192.168.0.198
Name:   ha.example.co
Address: 2606:4700:3031::1234:567
Name:   ha.example.co
Address: 2606:4700:3037::1234:5678
$ dig AAAA ha.example.co @pihole-2.example.co

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> AAAA ha.example.co @pihole-2.example.co
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24998
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;ha.example.co.                  IN      AAAA

;; ANSWER SECTION:
ha.example.co.           0       IN      AAAA    2606:4700:3031::1234:456
ha.example.co.           0       IN      AAAA    2606:4700:3037::1234:5678

;; Query time: 0 msec
;; SERVER: 192.168.0.62#53(pihole-2.example.co) (UDP)
;; WHEN: Sun Oct 05 04:23:15 UTC 2025
;; MSG SIZE  rcvd: 103

Given that ha.example.co has a local DNS, when I restart the resolver, why is Pihole sending it to 8.8.8.8?

[resolver]
  # Should FTL try to resolve IPv4 addresses to hostnames?
  resolveIPv4 = true

  # Should FTL try to resolve IPv6 addresses to hostnames?
  resolveIPv6 = false ### CHANGED, default = true

If it’s relevant, I also have two Pihole instances, where the config is mirrored (except DHCP active) using Nebula-sync. Pihole-2 is the master and has DHCP enabled, whereas Pihole-1 does not. The docker config is below. For a while I tried running on the main OS (Ubuntu VM) but that was also returning IPv6 addresses.

sudo docker run -it \
	--restart=always \
	--network=pihole-macvlan \
	--mac-address=0a:bb:bb:bb:bb:02 \
	--ip=192.168.0.62 \
	-p 53:53/tcp \
	-p 53:53/udp \
	-p 67:67/udp \
	-p 80:80/tcp \
	-p 443:443 \
	--cap-add NET_ADMIN \
	--cap-add CAP_CHOWN \
    --cap-add CAP_NET_BIND_SERVICE \
	-e TZ="Australia/Melbourne" \
	-e WEBPASSWORD=mypassword \
	-e DISABLE_IPV6=true \
	-v /etc/localtime:/etc/localtime \
	-v /data/docker/pihole/data:/etc/pihole \
	-v /data/docker/pihole/data/dnsmasq.d:/etc/dnsmasq.d \
	--name pihole-2 \
    --label 'wud.tag.include=^\d+\.\d+\.\d+$' \
	-h pihole-2 \
	pihole/pihole:2025.08.0

Within /etc/dnsmasq.d I only have the config for DHCP to return the two Pihole servers for DNS.

Every few days I google the problem again on the assumption that it should be a simple problem, but I’m struggling.

Debug Token:

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

You are shadowing a public domain, but you have defined only A records for it.
It's no surprise that Pi-hole (6 as well as 5) returns public AAAA records as defined in public DNS.

This has been answered before, see e.g. Resolve bad canonical DNS records - #11 by Bucking_Horn
or Local IPv4 DNS records also resolving WAN IPv6 addresses - is this by design? - #4 by Bucking_Horn.

Thanks - and thanks for the links. It seems I’m not alone in mistakenly thinking turning off IPv6 within Pihole will prevent those addresses being returned. Since I don’t understand how IPv6 works, I tried the option of specifying a wildcard filter to block them. My understanding is I should put the following into Group Management > Domains > RegEx filter and then click “Add to denied domains” (and then restart nebula-sync).

example.co;querytype=AAAA

However, it didn’t work. Doing nslookup returned “::” for IPv6, but after a while it wasn’t working again. I assumed the RegEx is doing a match, so “example.co” should match with “ha.example.co”. I’m running Home Assistant and the page initially works but if I leave the browser tab for 10 mins or so, it’s broken when I return and refreshing the page cannot reach Home Assistant. It sometimes briefly flashes “SSL name not recognized”. So I’m not sure why.

I instead changed it to block everything AAAA:

.*;querytype=AAAA

This seems to work. EDIT: Scratch that - Truenas couldn’t be accessed with “.*”, so I made it specific to HA instead.

This still isn’t working properly, but does seem to fail less often. I noticed on Windows an nslookup is returning “.lan” on the end of the name - not sure if this is relevant. Also, when it’s not working on Windows an nslookup returns no IP address, whereas Ubuntu is still returning the same result.

This is what I see on Ubuntu all the time:

$ nslookup ha.example.co pihole-2.example.co
Server:         pihole-2.example.co
Address:        192.168.0.62#53

Name:   ha.example.co
Address: 192.168.0.198
Name:   ha.example.co
Address: ::

When it’s working on Windows I see much the same as the above but the name is “ha.example.co.lan”. If I nslookup that name on Ubuntu it quite rightly gives me an error, but works on Windows and then gives me a name with “.lan.lan”.

This is what I see on Windows when it’s not working properly:

> nslookup ha.example.co pihole-2.example.co
Server:  pi.hole
Address:  192.168.0.62

Name:    ha.example.co.lan
Address:  ::

Despite no IP being returned it will still work in Windows most of the time, so not sure what is going on there.

When it’s not working if I go into Chrome Incognito and enter “ha.example.co” it will warn it’s not using SSL, and if I force “https:” it says “ERR_SSL_UNRECOGNIZED_NAME_ALERT”.

That expression would match example.co exactly.

That's overblocking.
If your network has public IPv6 connectivity, it could be of advantage if clients can talk to public IPv6 addresses.

Try (\.|^)example\.co$ instead.

Differences in nslookup results may be attributed to an OS version's implementation. An unspecific nslookup may issue different sets of queries on different OSs and versions.

If you don't specify a record type, you could expect to see DNS requests for A as well as AAAA records, with or without appending the local search domain(s).
E.g. Win10 would typically issue 4 DNS requests (A/AAAA for ha.example.co as well as ha.example.co.lan), where I've recently started to observe only 2 requests on Win11 machines (A/AAAA for ha.example.co.lan).

So if you want to compare nslookup results, you could issue requests for specific record types, e.g.

nslookup -type=AAAA ha.example.co

And to preclude nslookup from appending search domain(s), append a dot to the queried domain, e.g.

nslookup -type=AAAA ha.example.co.

Could you explain what you mean by 'not working'?

If it's this:

SSL negotiations can only start after successful DNS resolution, so DNS is not involved anymore.
However, when shadowing a public domain by Local DNS records, SSL can be expected to break if you don't own or control the domain

If you do, this would suggest an issue with your certificate, e.g. your certificate may not cover private range IPs.

Yeah it’s a bit nebulous isn’t it. Home Assistant updates data using a websocket (I assume) and this stops working. If you open it in a new page it shows an initial loading page (which I’m guessing is cached) and then spins saying it can’t connect to the server and will try again in 1 minute. There’s nothing obvious in the console log. And as I mentioned, opening in Incognito mode gives an unrecognised name error. Surely it’s not good that nslookup on my laptop at this time is returning no IP address (although putting an extra “.” on the end does return the correct address).

Regarding your comments about the certificate - I thought I was doing something pretty normal. I have configured NGINX Proxy Manager to use Cloudflare’s wildcard certificate (using Lets Encrypt) for the domain I own (which I’ve been referring to as example.co). I mean I just followed something online to set it up originally and it worked flawlessly for a few years until I upgraded to pihole V6, which seemed like a smoking gun. Googling “using cloudflare wildcard certificate on lan” now shows AI generated results of the same steps I took.

To check it’s not specific to Windows, I span up a PopOS VM and tried there - same thing, after a while Home Assistant isn’t responding properly, and a refresh of the screen results in “Unable to connect to Home Assistant”. The console just shows “Websocket connection to ha.example.co failed”. The network activity shows a bunch of successful 200 calls to the site (even with shift-refresh), so it looks like normal get requests are working, but websocket isn’t.

EDIT: I also noticed that if I leave it long enough it starts working all by itself.

I should add that I also have ha-int.example.co set up in exactly the same way, through Pihole and NGINX Proxy Manager, but it is not also defined at Cloudflare, so internal only. It works 100% of the time, which is why I assume it’s not certificate related.