Support wildcards in local DNS records

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.

http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

+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:

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 :slight_smile:

That are two different development source and I ask in the past to do this in one go.

Dnsmasq is still the beating heart of Pihole so not a legacy here.

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.

This was my feature request:

https://discourse.pi-hole.net/t/support-for-cname-next-to-host-record/25707

Wildcard host/domainname is not what I would endorse and this I can archieve in Unbound without a problem. This is always blocking and possible in Pihole so I prefer Pihole for that.

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.

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.

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?