Can't create a wildcard for top level of a zone

[kaysond]

Context: I'm using pfsense with unbound configured as its recursive resolver. pfsense automatically adds static dhcp mappings as local-data and local-data-ptr to the unbound configuration. It also adds a local-zone for the system domain (type is configurable; defaults to transparent.

Suppose my system domain is homelab.tld. I'm trying to set up a configuration with unbound that satisfies all of the following:

1. Any *.homelab.tld, where * is not defined anywhere (whether local-data, forward-zone, or stub-zone) resolves to 10.0.0.2
2. Any <host>.homelab.tld where <host> is the hostname of a dhcp static mapping resolves to the host's assigned ip
3. Same as above but for PTR records
4. Any subdomain of .offsite.homelab.tld is forwarded to another recursive resolver at 10.1.0.2
5. but requests to public.offsite.homelab.tld, though are resolved via specific authoritative nameservers
6. Requests to _acme-challenge.homelab.tld are recursed transparently
7. All DNS requests not directed to unbound are blocked

2-5 are fairly easy. The local-zone, local-data, and local-data-ptr added by pfsense take care of local hosts with static dhcp mappings. 4 is set up with a forward-zone, 5. with a stub-zone (this is to avoid 10.1.0.2 recursing it locally). 6 is a local-zone: ... transparent.

Everything except for 1 plays nicely. 1 sucks. It's a huge pain because unbound doesn't support CNAME in local-data. The typical way you'd set this up is with a local-zone: ... redirect, but then you can't have any other local-data, breaking 2 and 3.

An auth-zone with a zone file seemed promising because you can do a * IN CNAME homelab.tld and @ IN A<ip>, but it breaks the zones for 4, 5, and 6. I tried various combinations of for-upstream and for-downstream, but it didn't help. I considered adding extra NS records instead, but that not only defeats the purpose of having a recursive resolver, it also violates 7.

I've scoured the documentation, github issues, and the internet, but after a couple of days, I can't find a solution short of setting up a second DNS server which I'd like to avoid.

Am I missing anything? TIA!

[wcawijngaards]

The idea to have everything that does not have a record answered with a wildcard, matches the wildcard use in authority zones. But then there is also a need to forward and stub zones. So the address records and the *.homelab.tld. A 10.0.0.2 wildcard, go into an authority zone. It is set for-upstream: yes, and for-downstream: no. This is so that this authority zone is consulted but after other matters are checked. It is then possible to have localzones, and they are checked first, with various filters and transparent pass, if additional filtering is needed. To have queries not match inside the authority zone lookup, adding NS records in it creates a zonecut, offsite.homelab.tld. NS ns.example.com., that causes the authority zone to not match for this contents. Then have the stub-zone and forward-zone clauses to direct lookups by unbound for the information. That seems to be something that could work.

But otherwise, it looks like this is two filter steps. And localzone processing does not perform it in one go. It could be solved with another unbound instance with a part of the filter settings, so to speak. Another option is to set all traffic to enter a view, and in that view make transparent zones with content, the view is set to go back to the global settings if there is no match, with view-first: yes. Then the global zone, that is the server settings without a view, can have localzones that act to modify the information further. With like the addresses in the view and the global content has the redirect localzone. That can perhaps work too. It would then need noview and transparent localzones for the domains that need a stub and forward lookup.

And an other option, can be the use of RPZ zones to modify answers. With an authority zone, for-upstream, and not set for-downstream, with the wildcard in it. And then the addresses in an RPZ zone that overrides the authority zone information. But that seems to overdo it, since the addresses can be in the authority zone itself.