[FR] allow disabling of built-in empty zones with a single boolean

[pemensik]

Current behavior

Is there a current behavior that the feature relates to?
If yes, would you wish the current behavior to change?

unbound-control list_local_zones can list empty zones, which are created to prevent forwarding AS112 addresses and some other well-known stuff. That works great when unbound is used as a network resolver on a gateway, where it knows public IP address forwarder does not know any private addresses names. In version 1.20 we have 102 of such names. Because they are authoritative zones, they override possible forward definitions. Including default forwarder for root zone.

But the same does not work well if unbound would be used as a caching daemon on workstation or laptop, forwarding all queries via encrypted DNS to local network resolver. That might be unbound with default configuration too.

Instead of having to redefine local-zone for every such domain to nodefault or transparent value, it would be great if just single boolean could toggle domains with possible definitions to off. Ideally if it could be changed also via unbound-control. Simply by setting boolean forward-as112-networks yes, it might disable selected private ranges. If set to no again, when the forwarder is reconfigured to use dns.google server instead, it could activate them again. Also usable from unbound-host tool.

That might allow to disable AS112 built-in zones as soon as private IP address forwarder is used. Then we can be almost certain it might know more than local resolver knows. But even if it has public IP, it can still know reverse entries for local enterprise network or its part.

For example in bind9 it is much easier to disable everything unwanted, just single statement is enough: https://bind9.readthedocs.io/en/v9.18.30/reference.html#built-in-empty-zones

Describe the desired feature

A clear and concise description of what the feature should be.

I would like single boolean, which would disable most of such built in zones. All AS112 reverse network definitions. Which would change default when configured from unbound-host tool. I seen configured forwarder over TLS and used ipa.test zone. That was part of automated test. But that failed even when unbound-host -C tls-client.conf were used.

If I am testing TLS forwarder with unbound-host tool or unbound running only on localhost, this gives me weird result. While we can prepare configuration snippet listing all private networks with something like local-zone: "10.in-addr.arpa." nodefault, this seems to be unnecessary complicated for a relatively common case. If the resolver I use as forwarder is still in private network, it will know better than my host, what to forward and what can be answered from empty zone. Especially in more complex enterprise networks it might not be obvious, how many private addresses ranges are actually used.

Potential use-case

Describe how you see this feature being useful to other Unbound users.

It would be easier to configure unbound to use and cache even private network reverse definitions on workstation, which is used in non-public IPv4 or IPv6 networks. Meaning when it is not on the DNS border between private and public network, but just possible part of private network. In case we are not sure, it is safer to forward even insecure route.

It should allow networks like 10.in-addr.arpa., 16.172.in-addr.arpa. to 31.172.in-addr.arpa. and 168.192.in-addr.arpa. to be forwarded. More simple way. Likewise it should forward test or home.arpa networks. All domains, which might have (useful) local content on network provided resolver, should be passed to it. I think it should not require current effort to make them forwarded too.

At the same time, it should still create some common zones, which will not be likely to be replaced with more useful content. localhost., 255.255.255.255.in-addr.arpa., 0.in-addr.arpa., 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. or 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. are not likely to provide anything more useful, than there already is. Even on local network resolver, they will be very likely the same.

[pemensik]

Current logic will work fine if they those special zones have forwarder defined in configuration file. It does not work so well if unbound-control forward 192.0.2.53 is used to configure the zone later.