IPv6 DNS Resolution Not Working After Upgrading to Pi-hole v6

I was using Pi-hole v5 with the following Docker Compose configuration (version: "3"# More info at https://github.com/pi-hole/docker-pi-hole/ and ht - Pastebin.com), and both IPv4 and IPv6 resolution worked correctly. After upgrading to Pi-hole v6 and adjusting the environment variables, DNS resolution over IPv6 no longer works - only IPv4 does.

The IPv6 resolver is responding on the container’s internal IPv6 address, which is, of course, not accessible externally. Even when I force the reply address, I do not receive any DNS responses via IPv6 when querying the public IPv6 address of the Docker host.

My current docker-compose.yml (version: "3"# More info at https://github.com/pi-hole/docker-pi-hole/ and ht - Pastebin.com).

Logs: WARN[0000] /opt/containers/pi-hole/docker-compose.yml: the attribute `version` i - Pastebin.com

Any suggestions on how to resolve this?

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

As requested: https://tricorder.pi-hole.net/72L4k962/

Your Pi-hole container is fully operational on IPv6:

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.leonbergery.com.pl is NOERROR on lo (::1)
[✓] No IPv6 address available on eth0
[✓] www.leonbergery.com.pl is NOERROR on eth1 (fd65:99c3:b27:1::2)
[✓] www.leonbergery.com.pl is NOERROR on eth1 (fe80::<redacted>73%eth1)
[✓] No IPv6 address available on eth2
[✓] doubleclick.com is 2a00:1450:4016:809::200e via a remote, public DNS server (2001:4860:4860::8888)

But only your eth1 interface carries IPv6 addresses, your eth0 and eth2 don't:

*** [ DIAGNOSING ]: Network interfaces and addresses
   2: eth0@if134: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
       inet 172.19.0.4/16 brd 172.19.255.255 scope global eth0
          valid_lft forever preferred_lft forever
   3: eth1@if146: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
       inet 172.24.0.2/16 brd 172.24.255.255 scope global eth1
          valid_lft forever preferred_lft forever
       inet6 fd65:99c3:b27:1::2/64 scope global flags 02 
          valid_lft forever preferred_lft forever
       inet6 fe80::<redacted>73/64 scope link 
          valid_lft forever preferred_lft forever
   4: eth2@if157: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
       inet 172.30.9.3/29 brd 172.30.9.7 scope global eth2
          valid_lft forever preferred_lft forever

The network section of your docker compose differs between v5 and v6:
networks:

  # Create the internal network
  internal:
    ipam:
      config:
        - subnet: 172.30.9.0/29
  ipv6net:
    enable_ipv6: true
    ipam:
      config:
        - subnet: fd00:cafe:face:feee::/64
  proxy:
    external: true
networks:
  # Create the internal network
  internal:
    ipam:
      config:
        - subnet: 172.30.9.0/29
  ipv6net:
    driver: bridge  # Uses the bridge driver (default for Docker networks)
    enable_ipv6: true  # Enables IPv6 support for this network
    ipam:  # IP Address Management (IPAM) configuration
      driver: default  # Uses Docker's default IPAM driver
  proxy:
    external: true

You'll notice that your container's matching 172.30.9.3 is tied to eth2, which is one of the interfaces without IPv6.

Why would you require your Pi-hole container to be accessible via IPv6 anyway?

If you don't, configuring your router to not advertise an IPv6 address as local DNS server would allow you to drop IPv6 container configuration.
Clients requesting AAAA records would still get the correct IPv6 address answers, regardless of whether they ask via IPv4.