It would be great if wildcard domains were supported in custom DNS, so that a bunch of local services that are reverse proxied can be assigned as subdomains of a single domain.
The Local DNS record function is a direct domain name to IP map, like the /etc/hosts file.
cat /etc/pihole/custom.list
0.0.0.0 test.com
192.168.0.162 New-nanopi
192.168.0.200 Office-printer
For the functionality you seek, dnsmasq configurations in /etc/dnsmasq.d would likely be required.
+1 on this. Pihole 5 supports the ability to add local dns, but it can't support wildcard dns records. Here's a screenshot for an example:
2 Likes
Is there a concrete reason to use a hosts list instead of dnsmasq config?
I think you need to restart DNS anyways, and as far as I can tell it should be trivial to just add a little bit of formatting to turn the pair map into a dnsmasq address-line.
I will try to prepare a pull request with this change, hoping there were no further reasoning beside hosts being a little bit easier.
CNAME-Support is implemented via dnsmasq, so I really think this is some "legacy" (despite being a new feature) decision 
Yeah the "legacy" is more tongue in cheek that the implementation using lists is not really the ideal decision for this use case (or there is a reasoning for using hosts, see below).
But I just noticed that wildcards in dnsmasq actually aren't wildcards, but this means a change in behaviour, see this SO-answer.
So right now, with this hosts:
example.com 10.0.0.1
Resolves example.com, and returns NXDOMAIN for x.example.com
The (what I would have guessed "same representation") in dnsmasq:
address=/example.com/10.0.0.1
Resolves example.com AND any subdomain, never returning NXDOMAIN for this address.
It is debatable if this is really a breaking change, but there is a change in behaviour of running applications, and maybe the fact that dnsmasq always resolves any subdomains was the reason to use a hosts list over it.
This is not unfixable, we could just decide to write everything with * in dnsmasq, and everything without in the hosts. This would resolv the hosts first, and then dnsmasq for subdomains.
But this is a bit of logic that goes on top of it and would further complicate this whole thing
No, for rereading the HOSTS lists (including this one) we do not have to restart but only reload pihole-FTL. This can be done quickly and on-the-fly. If we were to reread config lines, there is no other way that doing a true (hard) restart. So there is a difference in efficiency here. Also, the former does not stop DNS resolution. The hard restart will interrupt DNS for maybe a few seconds on very low-end devices like a Raspberry Pi Zero. This used to be a lot worse (up to 30 seconds when you have millions of domains on your blocking lists), but Pi-hole v5.0 improved massively on this.
However, I should also not forget to mention this that the current way of doing it with HOSTS files is actually caused by this feature being an external contribution adding it in exactly the way we have it right now. So it was less a specific decision of the Pi-hole developers themselves but rather a decision of the author:
As the workload is pretty high on the "core" developers, we are very thankful for any submission and, as it did what it should do according to the intention of the original submitter, we accepted it in this way instead of heavily changing and tweaking things.
They should definetly not be default behaviour, but I think they should still be a feature.
Maybe I'll look into it in the future. I don't think it makes sense to add wildcards next to the current hosts list, if they were implemented they should replace the current system to not let everything drift apart too much.
What would need to be done IMO:
AdminLTE:
- Keep the Local DNS Records-View as is, but expand the regex for valid domains to allow a domain starting with a * to act as a wildcard.
- Maybe add an information that you can find and edit the file on disk if you need larger changes, but this might encourage users to add "malformed" or not supported entries.
Pi-Hole-CLI:
- Keep the single addcustomdns
- Check if the domain starts with *, if yes add it as an address to the dnsmasq config
- If the domain does not start with *, add it as a host-record to prevent subdomains from being resolved
This may be require the ability to reorder the entries, but I would say this is out of scope and should be done on file level (if needed) or by deleting/readding entries.
1 Like
Hi, just to clarify, there was no specific intention by making this contribution use the host file rather than anything else.
Being a new user of PiHole i wanted to add custom DNS entries and found out that using a custom.list worked great, so i decided to share my dev because it already seemd usefull in its current state
The last Joniator post seems like the best way to go for me
What would also be great for Custom DNS (wildcard or otherwise), rather than specifying an IP address, be able to specify the name of a host, validated against the current DHCP leases. So a level of indirection then. I guess there would probably need to be a process where it is periodically updated, if the host that the Custom DNS was targeting does not have a static DHCP lease... or maybe require the host to have a static lease.
As your request correlates the terms wildcard domains and DNS, let me just mention that using wildcards with DNS records is problematic.
(In case you are interested why, click for details).
On a conceptual level, allowing definition of wildcard records has the potential to compromise DNS as a delegated system (e.g. a zone that does wildcarding and delegates to a subzone could mess with lookup of DNS records for that delegated zone), potentially breaking DNSSEC.
On a more practical level, use of wildcards has long been standardised in RFC 1034, sec 4.3.3.
It is important to note that wildcards as defined in there differ significantly from what you'd normally expect. Specifically, it would match only for such domains where a DNS record does not already exist, e.g. nextcloud.my.net would not match *.my.net if a DNS record had already been defined for the former.
Ambiguity in RFC 1034 4.3.3 left room for interpretation which in turn led to different DNS servers implementing inconsistent different behaviour for wildcard records. Much later RFC 4592 (still a proposed standard) tried to address this, and today, quite a few DNS servers will allow you to ignore wildcard DNS records from external sources as configured.
But putting terminology aside:
As jfb mentioned, you may be able to achieve what you want by supplying a line to a separate configuration file of Pi-hole's embedded dnsmasq (e.g. /etc/dnsmasq.d/42-reverse-proxied-subdomains.conf):
address=/revproxy.my.lan/192.168.0.42
Note that this isn't exactly wildcarding, as it doesn't involve using wildcard characters at all, and perhaps more importantly, it does not allow a distinction between a domain and its subdomains, e.g. both dig nextcloud.revproxy.my.lan and dig revproxy.my.lan(!) will resolve to 192.168.0.42.
When considering to expose this feature via Pi-hole's UI, you'd have to make sure a user understands this, as providing this at the wrong level may mess up your entire network with one click, resolving all hostnames to a single IP, potentially even cutting a user from accessing Pi-hole's UI to fix this.
To prevent this, Pi-hole could also reject requests for a known local tld, but it may not be accurately aware of that in all circumstances.
Also, DL6ER's remark on longer restarting behaviour and brief DNS outages fully applies here.
2 Likes
When pihole v5.0 was released the feature was renamed from "Custom DNS" to "Local DNS Records". Would you mind to change the title of this FR accordingly to make it easier for other users to find it?
Hello, Is there any plans to implement this?
4 Likes
Just adding support for this - I currently use pihole at home but also Lancache. I've manually added the required DNS entries for Lancache to the config files, but it would be a lot easier if Wildcards were an option in pihole's web GUI.
5 Likes
I'm also voting for this feature. It would make my life easier 
4 Likes
Any changes to this or features in PiHole v6?
@Bucking_Horn's reply from above has covered this already. Local DNS records are intentionally designed as simple HOSTS-like records and wildcards just aren't supported by this format.
Typically, it is best to not use wildcards but define every legit domain individually, however, I do see that this puts additional maintenance burden on the DNS admin.
You can either resort to address=/.../... syntax in additional dnsmasq lines or you can also use regex with forced replies like
(^|\.)mydomain\.com$;reply=192.168.2.1
to always reply with said IP to mydomain.com and all its subdomains. This gives you the entire power of regex e.g.,
\.mydomain\.com$;reply=192.168.2.1
would only match subdomains but not the domain itself. This may be useful if you have some website on mydomain.com but want to have everything else, like printer.mydomain.com pointing to your local IP address.
3 Likes
can you please share how to use the regex? Where should I enter that?
See the earlier reply a few posts up.
I have but I still don't get it. Should I add to a file inside /etc/dnsmasq.d/ this address=(^|\.)mydomain\.com$;reply=192.168.2.1 or just (^|\.)mydomain\.com$;reply=192.168.2.1 or what the correct way is? Because he said that we can use that in addition to address=/.../... so I'm assuming the regex doesn't use address=? I'm confused.
It's either...or.
You'd need a custom config file to apply address=... options, whereas regex can be entered via Pi-hole's UI, as a RegEx filter under Domains.
2 Likes