Create a folder named etc-dnsmasq.d alongside Pi-hole’s docker-compose.yml file.
Inside the etc-dnsmasq.d folder, create a file named wildcards.conf with the following content:
# wildcards.conf
#
# Support wildcards in local DNS records
# address=/.mydomain.com/192.168.31.22
address=/.yourdomain.com/your-IP-address
In Pi-hole’s docker-compose.yml, make sure you have:
environment:
# Instructs Pi-hole’s FTL service to use the custom dnsmasq.d directory
FTLCONF_misc_etc_dnsmasq_d: 'true'
volumes:
# Uncomment this if you want to persist custom dnsmasq config files.
# Not needed for most new Pi-hole v6 setups. If you’re upgrading from v5
# and have used this directory before, keep it enabled during the first
# v6 container start to allow for a complete migration, then you can remove it.
# Requires FTLCONF_misc_etc_dnsmasq_d: 'true'.
- './etc-dnsmasq.d:/etc/dnsmasq.d'
4.Finally, run: docker compose down && docker compose up -d
Just going came in to say, I've recently moved from dnsmasq to pihole, only to find that now none of my named docker applications (that had nicename.sub.domain.com but were on the same IP) resolve.
I don't understand why wildcards in local DNS records wouldn't be desired by the average user. Certainly I want it.
ok, well, I had already created a wildcard.conf in /etc/dnsmasq.d
Perhaps if using this folder is default behaviour in dnsmasq but not in pi-hole it would be a considerate idea to add a warning in the UI stating that there are files being ignored.
I did find the setting on /admin/settings/all , and it now works, so thanks for that.
Ignoring these files by default tries to circumvent conflicts which might prevent Pi-hole to start. Various operating system provided packages, like LXC, create files in this directory changing the listening behavior, limiting it to only certain interfaces or excluding other interfaces. Why we see these files on many many user systems, having them by default is undesirable. And just because we see them in a lot of systems, where users don't actually need or asked for them, I have the feeling that prominent warning made trigger a lot more question signs then not mentioning anything about it.
But it surely up and open for discussion @moderators if there should be a warning on the web interface when there are files in /etc/dnsmasq.d but misc.etc_dnsmasq_d = false .
I think adding a warning if there are files in this directory is a bad idea. Most users don't need these files and using them is considered an advanced configuration. A warning like this will create confusion for most of the users.
I think we can add a better text or warning to the documentation making clear misc.etc_dnsmasq_d needs to be enabled to load additional files.
I don't know if the web UI is the place for that sort of warning, but it seems to me that a short note during the install process if the files are detected would probably be appropriate. Just something simple that an existing configuration was noted and the files are being left in place but unused. It would be more suited to advanced users who setup those configurations themselves, without causing undue concern to those who have had files added from another source.
Well, okay, but mine was a replacement installation not an upgrade - I'd had dnsmasq on an LXC and decided that I'd run pihole on a standalone pi instead. DNSmasq had the wildcard for Traefic.
I had 2 manual rules and the wildcard. I moved them after I did the install but the wildcard didn't work.
reply=... does only make sense in a blocking context. Everything that is allowed is not tampered with any further and ... well ... just allowed. Any answer it will receive inevitably comes from upstream in the allowed case.
I really like pihole as how it is today but I feel constant wrestling with it when it comes to wildcarded DNS entry. I updated pihole (from a very old one) and spent a handful amount of time to discover that now my all time used dnsmasq configs needs special enabling before use.
What is the reason not to implement wildcard function into custom DNS entry? (I reverse proxy 30 docker container with nginx and subdomain resolving, surely not I am the only person who does this or similar).
Would be more convenient to use the otherwise very good frontend to setup something which seems rather easy and useful.
Another bump for this - I have have a bunch of self-hosted dockers using wildcard SSL and I can’t really understand why basic wildcard isn’t supported here, it’s really frustrating.
This misc.dnsmasq_lines setting can be found on the webGUI expert settings page.
FYI:
$ man dnsmasq
[..]
-A, --address=/<domain>[/<domain>...]/[<ipaddr>]
Specify an IP address to return for any host in the given
domains. A (or AAAA) queries in the domains are never for‐
warded and always replied to with the specified IP address
which may be IPv4 or IPv6. To give multiple addresses or
both IPv4 and IPv6 addresses for a domain, use repeated
--address flags. Note that /etc/hosts and DHCP leases over‐
ride this for individual names. A common use of this is to
redirect the entire doubleclick.net domain to some friendly
local web server to avoid banner ads. The domain specifica‐
tion works in the same way as for --server, with the addi‐
tional facility that /#/ matches any domain. Thus --ad‐
dress=/#/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 up‐
stream nameserver by a more specific --server directive. As
for --server, one or more domains with no address returns a
no-such-domain answer, so --address=/example.com/ is equiva‐
lent to --server=/example.com/ and returns NXDOMAIN for ex‐
ample.com and all its subdomains. An address specified as
'#' translates to the NULL address of 0.0.0.0 and its IPv6
equivalent of :: so --address=/example.com/# will return
NULL addresses for example.com and its subdomains. This is
partly syntactic sugar for --address=/example.com/0.0.0.0
and --address=/example.com/:: but is also more efficient
than including both as separate configuration lines. Note
that NULL addresses normally work in the same way as local‐
host, so beware that clients looking up these names are
likely to end up talking to themselves.
Note that the behaviour for queries which don't match the
specified address literal changed in version 2.86. Previous
versions, configured with (eg) --address=/exam‐
ple.com/1.2.3.4 and then queried for a RR type other than A
would return a NoData answer. From 2.86, the query is sent
upstream. To restore the pre-2.86 behaviour, use the config‐
uration --address=/example.com/1.2.3.4 --local=/example.com/
