CName wildcard not resolving when target is a local DNS record

Hey, I’m trying to setup my pihole to resolve a whole domain to point to my RP. I have setup a local DNS record for the main domain (ie xxxx.com) that points towards the RP and this works just fine. Now I’d like for all the subdomains to also point towards this RP so I did a CNAME record that has *.xxxx.com as a domain, and xxxx.com as a target. Now nslookup to test.xxxx.com resolves on the public IP for my RP (the cloudflared tunnel IP that essentially points towards the RP).
I don’t understand why the CNAME is not catching this and resolving to my local RP ip adress :confused:

There is a limitation on cname records, I think the web interface explains it but basically the target of a cname must be a domain that Pi-hole is authoritative for. You can't cname mygoogl.com for google.com because Pi-hole is not in charge of google.com as the domain.

Yes, that’s something I am aware of but in my case, the main domain is already a local dns record, it works fine and redirects to my local RP ip adress. However when CNAME’ing the wildcard subdomain, no subdomain works. I’m not trying to CNAME a domain I don’t own since I do register it locally on the pihole

Okay, try tailing the Pi-hole log (either through the CLI or via the web interface live tail) and then do a dig for the CNAME domain to see what the process is. Do the CNAME first to make sure the target domain hasn't been loaded with an A record query and already in the cache.

2025-11-23 18:13:46.848 query[CNAME] xxxx.com from 192.168.1.1

2025-11-23 18:13:46.848 forwarded xxxx.com to 127.0.0.1#5335

2025-11-23 18:13:46.872 query[CNAME] xxxx.com from 192.168.1.1

2025-11-23 18:13:46.898 reply xxxx.com is NODATA


Note that the domain is NOT xxxx.com but a domain I do own

Okay, so the query is being sent upstream instead of being answered from the local database.

It's going to be really hard to help or debug without more information. Can you please run pihole -d and then provide the token URL so that the support folks can get an idea of how everything is configured?

Sure : https://tricorder.pi-hole.net/eQLOoo8e/

Thanks, I haven't seen wildcards used in CNAMEs but I don't think anything prevents it. Pi-hole uses dnsmasq as the core of FTL and I don't see anything in the dnsmasq documentation about wildcard for CNAME.

You have the local domain (dns.domain) as lan, set to local. I wonder if you change that to your internal domain to declare the domain as local. I assume you don't want to have anything in your personal domain to be resolved on the global internet? No need for something like a split brain DNS?

You can also enable some extra debugging information to see if you/we can trace down what is going where:

and

They've been allowed by dnsmasq since 2.77

Allow wildcard CNAME records in authoritative zones.
For example --cname=*.example.com,default.example.com

I suspect the problem here may be that pi-hole is not being set as the authoritative server (rather than just a local recoad) for the domain:

--auth-server=<domain>,[<interface>|<ip-address>...]

Enable DNS authoritative mode for queries arriving at an interface or address. Note that the interface or address need not be mentioned in --interface or --listen-address configuration, indeed --auth-server will override these and provide a different DNS service on the specified interface. The <domain> is the "glue record". It should resolve in the global DNS to an A and/or AAAA record which points to the address dnsmasq is listening on. When an interface is specified, it may be qualified with "/4" or "/6" to specify only the IPv4 or IPv6 addresses associated with the interface. Since any defined authoritative zones are also available as part of the normal recusive DNS service supplied by dnsmasq, it can make sense to have an --auth-server declaration with no interfaces or address, but simply specifying the primary external nameserver.

Ah, thanks for the link!

And yes, I agree that there's an issue with who is authoritative. That was my suggestion for making the domain as a local but it might need the auth-server configuration.

Or the wildcard code might be buggy. Things work when it's an A or a single CNAME, it's the wildcard that muddies the water.

Thanks for the answers in this topic.

I'll try more things when I get home :

No wildcard CNAME but rather a single test subdomain to see if the issue lies in the wildcard or in the non authority of the pihole on my domain. The thing I was confused was that my pihole only needs to be authoritative on the domain in my LAN (obviously) but as I'm new to pihole, I didn't know if that was possible :innocent: