DNSSEC validation fails for wildcard domains

[Ultimator14]

Versions

• Pi-hole: 6.3
• Web: 6.4
• FTL: 6.4.1

Platform

• OS and version: Gentoo Linux
• Platform: Docker on Raspberry Pi

Problem description

I have set up a wildcard DNS record *.b.c.pygos.space.
The DNSSEC validation for all subdomains works e.g. a.b.c.pygos.space gives a valid DNSSEC result.
The validation for the wildcard *.b.c.pygos.space itself fails however.
Pihole somehow expects an NSEC record for wildcards although there is no NSEC record required here because the wildcard is an exact match of the DNS record.

Expected behavior

DNSSEC validation should also succeed for the wildcard domain itself.
dig *.b.c.pygos.space should pass DNSSEC validation.

Actual behavior / bug

Validation of wildcard DNS records fails with SERVFAIL (NSEC Missing):

dig *.b.c.pygos.space @my-pihole-ip

; <<>> DiG 9.18.42 <<>> *.b.c.pygos.space
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43927
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 12 (NSEC Missing)
;; QUESTION SECTION:
;*.b.c.pygos.space.		IN	A

;; Query time: 178 msec
;; SERVER: 192.168.157.10#53(192.168.157.10) (UDP)
;; WHEN: Sun Dec 21 15:15:33 CET 2025
;; MSG SIZE  rcvd: 52

The query log shows BOGUS DNS (see screenshot below).
The same query using any other resolver (e.g. cloudflare or a local recursive resolver) will correctly pass DNSSEC validation and display the result.

Steps to reproduce

Steps to reproduce the behavior:

1. Enable DNSSEC in pihole settings
2. dig a.b.c.pygos.space @my-pihole-ip works
3. dig *.b.c.pygos.space @1.1.1.1 works
4. dig *.b.c.pygos.space @my-pihole-ip fails

Screenshots

Additional context

Compose file

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    network_mode: host
    environment:
      TZ: 'Europe/Berlin'
      WEBPASSWORD: 'redacted'
      ServerIP: 'redacted'
      ServerIPv6: 'redacted'
      IPv6: 'true'
      DNSMASQ_USER: root
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    cap_add:
      - NET_ADMIN
    restart: unless-stopped
    ulimits:
      nofile:
        soft: 1024
        hard: 4096
    shm_size: '2gb'

[DL6ER]

Pi-hole FTL is, in fact, a (fat) wrapper around dnsmasq which does all the heavy DNS lifting. You should point your report to the official dnsmasq mailing list at dnsmasq-discuss@lists.thekelleys.org.uk as this is the place where this issue needs to be fixed. As soon as there is an upstream fix, we will quickly incorporate it into FTL. Unfortunately, we don't have the resources right now to work on debugging things in (from our point of view) external dependencies, even when we use them. We also want to avoid doing (possibly incompatible) changes in our code that would prevent us (or make it at least a lot more complicated) to inherit future updates from the upstream project.

Sorry to have to say this but I hope you can follow my reasoning here.

[Ultimator14]

Sure, thanks. I will report a bug for dnsmasq then and report back here once this is fixed upstream.

[Bucking-Horn]

I have set up a wildcard DNS record *.b.c.pygos.space

On a side note - rather than configuring wildcard resolution for subdomains, it seems you've created a CNAME record for *.b.c.pygos.space verbatim:

$ dig *.b.c.pygos.space @192.168.27.53

; <<>> DiG 9.16.27-Debian <<>> *.b.c.pygos.space @192.168.27.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13242
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;*.b.c.pygos.space.		IN	A

;; ANSWER SECTION:
*.b.c.pygos.space.	300	IN	CNAME	pygos.space.
pygos.space.		60	IN	A	46.167.27.232

;; Query time: 260 msec
;; SERVER: 192.168.27.53#53(192.168.27.53)
;; WHEN: Wed Dec 31 08:10:01 CET 2025
;; MSG SIZE  rcvd: 76

What's the purpose of doing that?

[Ultimator14]

I have set up a wildcard DNS record *.b.c.pygos.space

On a side note - rather than configuring wildcard resolution for subdomains, it seems you've created a CNAME record for *.b.c.pygos.space verbatim:

$ dig *.b.c.pygos.space @192.168.27.53

; <<>> DiG 9.16.27-Debian <<>> *.b.c.pygos.space @192.168.27.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13242
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;*.b.c.pygos.space.		IN	A

;; ANSWER SECTION:
*.b.c.pygos.space.	300	IN	CNAME	pygos.space.
pygos.space.		60	IN	A	46.167.27.232

;; Query time: 260 msec
;; SERVER: 192.168.27.53#53(192.168.27.53)
;; WHEN: Wed Dec 31 08:10:01 CET 2025
;; MSG SIZE  rcvd: 76

What's the purpose of doing that?

I just created this record for testing purposes to reproduce the SERVFAIL, so no real purpose.
Originally, the issue appeared for the TLSA records *._tcp.pygos.space.