I have tested Pi-hole yesterday on my new server since my old one died previously I had it setup under docker but I decided to switch to Adguard for ease of wildcard rewrites.
I have a totally local only setup with wireguard as how I access my services. However I am setting up lets encrypt certs for all my services by cert or caddy etc.
I would really like to return to Pi hole as the better experience and product overall. However I could get Pihole to run and function as a LAN adblocker and DNS server but when I tried to setup wildcard entries in dnsmasq here is where the issues started.
My system is Fedora CoreOS 43, I tried podman rootless and rootful using this basic Quadlet file ( I did allow lower port numbers for rootless so port 53 would work)
When I added a file for wildcards to dnsmasq.d with the option misq.etc_dnsmasq_d set to enabled in miscellaneous settings (I also tried the UI entry for misc.dnsmasq_lines as well instead of a file)
the format I used was
address=/.mydomain.com/192.168.1.250
I even tried adding
server=/mydomain.com/#
as some guides recommended.
But after saving the setting and after flushing DNS from my workstation, it would temporarily resolve to IP 192.168.1.250 for nslookup and dig and then a minute later resolve to the IP of my home network.
I suspect this is a networking issues in podman, but then again I didn't test wildcards when I was using docker, I'd switched to Adguard before getting the chance.
Has anyone who uses podman for pihole had this issue before ?
This would configure pihole-FTL / dnsmasq to send queries for mydomain.com and its subdomains to the standard upstreams - not what you intend, as you want Pi-hole to answer those queries.
That may indicate that those DNS requests weren't handled by Pi-hole.
Please share the full results of such a successful and a failing nslookup each.
so I'll explain what I've just done, I removed the adguard container quadlet ( so it wont start ),
changed my router setting so it doesn't advertise pihole for dns ( only for now as it stops gravity creating a database for some reason, I suspect its trying to fetch something but can't as there is no DNS server ... yet ).
Restart the server and start pihole Quadlet
enable misc.etc_dnsmasq_d in settings and add line
address=/.mydomain.dedyn.io/192.168.1.250 to misc.dnsmasq_lines
The machine you ran that nslookup from is not using Pi-hole for DNS, but a local stub resolver on 127.0.0.53.
It would depend on that stub resolver's configuration whether that would use Pi-hole as its sole upstream or switch among several DNS servers.
Did those requests register in Pi-hole's Query Log?
If so, could you share the respective log lines from /var/log/pihole/pihole.log or Tools | Tail log files | pihole.log for all those requests?
Note that nslookup would issue more than one DNS request for a given domain, typically up to four (A as well as AAAA records for a given domain as well as domain extended by your local search domain).
The machine you ran that nslookup from is not using Pi-hole for DNS, but a local stub resolver on 127.0.0.53.
It would depend on that stub resolver's configuration whether that would use Pi-hole as its sole upstream or switch among several DNS servers.
yeah I have it set in network manager UI so it usually resolves when I test with adguard
it seems the requests are showing in the log but not resolving to the correct IP.
Could I send you the log privately as it contains domain names?
I can't recreate your observation on my end, even when mimicking all the different types that show up in your log excerpt.
I don't see a reason why your installation behaves differently, unless perhaps you'd have some extra configuration details not shared yet.
Nevertheless, you should probably be aware that you are shadowing public DNS records, but have supplied only A record definitions pointing to 192.168.1.250 - so pihole-FTL / dnsmasq will still forward all other requested types to its upstreams, and your log shows requests for AAAA, HTTPS, SRV and CNAME types.
(That latter is somewhat strange, as clients typcially don't request CNAMEs directly, but rather ask for another type, where the resolver receives a CNAME reply and then instead requests the original type for the CNAME target.)
If you want your Pi-hole to handle ALL types for a domain internally, you'd have to add the equivalent of local=/.mydomain.dedyn.io/ for your specific domain to your custom configuration.
Of course, if you'd do that and you'd have to rely on certain types returning specific answers, you'd have to also add the respective definitions for those types (e.g. CNAME would return NODATA then, where public DNS may have answered with mydomain.dedyn.io).
Please give adding that local line a try and report back if that would help fixing your issue.
If it doesn't, we'd need a debug log for further analysis.
You can share the token after uploading one by
does this mean that when I request a new cert or renewal it will also resolve to 192.168.1.250? if so can I add _acme-challenge.mydomain.dedyn.io to resolve to _acme-challenge.mydomain.dedyn.io like in the adguard config above?
could this be the configuration I have setup with my domain provider?
as a quick overview , I have one A record pointing to my home IP ( although it will never be used as its entirely local) and 4 CNAME records ( probably why it makes requests to CNAME directly) pointing to the target domain that's the one listed in the A record
is this because I am using a second level subdomain for my domain name, provided by https://desec.io ?
I'm more than happy to send a screenshot of my domain provider config if its possible privately?
I don't think that's likely, as its the certificate authority that will publically access a DNS record to check whether you have indeed control over the domain you try to get a cert for (unless you'd be exposing your Pi-hole as a public DNS server, in which case you'd run an open resolver which we don't provide support for).
No, as that's a public DNS configuration. While that would ultimately supply public answers retrieved by Pi-hole, it won't affect the way how Pi-hole resolves domains.
Again, unlikely, as a client doesn't need to be aware of whether the record it is about to request is served directly by the requested domain itself or by some CNAME target domain, e.g. it would request an A record, and the resolver would get a CNAME reply, which it then uses to request an A record from.
Typically, the client looks for specific information from a specific type, e.g. an IPv6 address from an AAAA record.
It is quite unusual that a client would request a CNAME directly, as the answer for this would always be just the target domain (and never another record type's result).
Did you perhaps request those lookups manually?
Not quite.
It doesn't depend on where in the DNS hierarchy you are shadowing records - it's because you are creating exclusively locally held DNS records for a public domain, as opposed to creating just records for domains intended for private network use (e.g. *.internal or *.home.arpa).
The only clients that are expected to see those local DNS records are your local clients, while the rest of the world would see the public DNS entries.
Thank you so much for all your help I'm marking the local=/.mydomain.dedyn.io/ as the solution as it seems to fix my issue, time will tell if I find any edge cases that this has broken.
Also thank you for taking the time to explain with very detailed answers, questions not entirely related to my original query, this has helped my very poor understanding of how this all works.
previously I had it setup under docker but I decided to switch to Adguard for ease of wildcard rewrites.