To give some context, I'm hosting a few services locally that I don't want to expose outside my network but also want to have available through HTTPS. I've got a public domain with a
CNAME *.home -> home.proxy
In Pi-Hole, I've added a local DNS record through the web interface:
home.proxy -> local IP
Upon making a request for the first time, home.proxy doesn't get resolved and in pihole.log I can see the following:
query[A] service.home.domain.com from 192.168.50.85
forwarded service.home.domain.com to 127.0.0.1#5335 // <- resolved by unbound
reply service.home.domain.com is <CNAME>
reply home.proxy is NXDOMAIN
If I keep refreshing the page in my browser, eventually it resolves and I can see:
query[A] service.home.domain.com from 192.168.50.85
cached service.home.domain.com is <CNAME>
/etc/pihole/custom.list home.proxy is 192.168.50.126
However this seems to be cached because after a while, it goes back to not being able to resolve home.proxy with the same NXDOMAIN response.
I guess I could try adding the record in /etc/dnsmasq.d/ or /etc/hosts which are looked up before /etc/pihole/custom.list but I feel like this is either a bug or there's something I'm doing wrong? Appreciate any insight.
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:
This won't work reliably, as DNS resolution usually wouldn't stop with a CNAME, but would try to appropriate an IP, i.e. an upstream resolver is providing NXDOMAIN simply because it doesn't have an A record for home.proxy.
If it randomly works at all, then because Pi-hole would chance to have both CNAME and A records in its cache at the same time.
Mitigation should be simple:
Add a local DNS record for your public domain instead, pointing to the local IP.
EDIT:
If you'd want to instead cover all subdomains of your public domain, you could supply a line to a separate configuration file of Pi-hole's embedded dnsmasq (e.g. /etc/dnsmasq.d/42-shadow-public-cname.conf):
Thus --address=/#/1.2.3.4 will always return 1.2.3.4 for any query not answered from /etc/hosts or DHCP and not sent to an upstream nameserver by a more specific --server directive.
Substitute <local-IPv6> with a link-local or ULA IPv6 address, or omit that second line completely. In that latter case, local=/my.lan/ will ensure that AAAA requests will receive a NODATA response.
Run
pihole restartdns
to have pihole-FTL read and apply your configuration updates.
My DNS knowledge is limited but after further looking into this, I think I know what's happening, and you're right. These two queries, on their own, work fine:
$ host -t cname service.home.domain.com
service.home.domain.com is an alias for home.proxy
$ host -t a home.proxy
home.proxy has address 192.168.50.126
This made me assume that the recursive nature of DNS would automagically be able to connect the two and get to the A record. Obviously, this isn't the case:
$ host -t a service.home.domain.com
Host service.home.domain.com not found: 3(NXDOMAIN)
unbound (in my case) is the recursive DNS resolver and pi-hole is just the middle man between it and the clients making DNS queries. The result for home.proxy is coming from pi-hole but unbound is the thing trying to resolve it (using the NS of the initial query?) which is why it comes up empty-handed.
I couldn't find a way to use wildcards for local DNS records, would this require me to manually add all the different subdomains?
Also, I guess then my issue is resolved - it's not a problem with pi-hole.
Sorry, I've overlooked that aspect of your CNAME definition from your initial post.
Yes, you could add individual subdomains, or try the address optiion approach I've extended in my answer above.