unbound: Add support for native IPv6 prefix tracking in host overrides

[n-thumann]

This PR add support for native tracking of dynamic IPv6 prefixes in Unbound host overrides.
It allows one to be using SLAAC provide the clients with a network prefix, let them auto-configure on their own and only add the client's IID and the interface to track to Unbound.

It is similar to Unbounds DHCP Static Mapping, but without requiring DHCPv6. Personally, I don't run DHCPv6 in my network and hence cannot use the static mappings and would also like to avoid cross-dependencies between DHCPv6 and Unbound.

With this patch applied you can optionally add an interface to track to an AAAA record:

The table also shows the interface, LAN in this example, because it's configured as a Track Interface of WAN.

The host overrides as seen above result in the following host_entries.conf (see last two lines):

root@OPNsense:~ # cat /var/unbound/host_entries.conf
[... snip ...]
local-data-ptr: "2003:[redacted]:5076:9bff:fe04:e801 OPNsense.localdomain"
local-data: "OPNsense.localdomain AAAA 2003:[redacted]:5076:9bff:fe04:e801"
local-data: "OPNsense AAAA 2003:[redacted]:5076:9bff:fe04:e801"
local-data: "OPNsense.localdomain AAAA fe80::5076:9bff:fe04:e801"
local-data: "OPNsense AAAA fe80::5076:9bff:fe04:e801"
local-data-ptr: "1.1.1.1 some-a-host.domain"
local-data: "some-a-host.domain IN A 1.1.1.1"
local-data-ptr: "2606:4700:4700::1111 some-aaaa-host.domain"
local-data: "some-aaaa-host.domain IN AAAA 2606:4700:4700::1111"
local-data-ptr: "2003:[redacted]::1337 tracked-prefix-host.domain"
local-data: "tracked-prefix-host.domain IN AAAA 2003:[redacted]::1337"

[AdSchellevis]

To be honest, I'm not really a fan of trying to glue more interface address dependancies in the unbound code as it's usually quite flaky and prone to errors.

If we have an option to cleanly feed this to unbound without the need of a restart (loosely coupled), it might be different, but at the moment I don't think we should try to merge this. @swhite2 is doing some more work around Unbound, parking this with him for now to see if we can come up with a design change at some point for these dynamic types.

[fichtner]

Just from the looks of it the interface selection feels really odd here. It's not even the prefix merge that trips me off. I agree this needs some sort of scope to work but I would not favour Unbound integration to be the one to pioneer it.

[swhite2]

If we have an option to cleanly feed this to unbound without the need of a restart (loosely coupled), it might be different, but at the moment I don't think we should try to merge this. @swhite2 is doing some more work around Unbound, parking this with him for now to see if we can come up with a design change at some point for these dynamic types.

Agreed. This especially pertains to a requirement for dynamic types in the mvc model.

[n-thumann]

Thanks for your feedback!

To be honest, I'm not really a fan of trying to glue more interface address dependancies in the unbound code as it's usually quite flaky and prone to errors.

For that reason I used the same logic as in

core/src/etc/inc/plugins.inc.d/unbound.inc

Line 474 in 0b453ea

list ($laddr6) = interfaces_primary_address6($interface, $ifconfig_details);

, because if it works at that point, we can probably assume that it works in this patch as well.

If we have an option to cleanly feed this to unbound without the need of a restart (loosely coupled), it might be different [...]

I definitely agree that this should be the ultimate goal! But given the fact that the problem in general has been around for quite some time (e.g. #2544 (comment) or #3657 (comment)), this may be a good solution in the meantime.
Also, it doesn't require any additional restarts of Unbound, because it's already being restarted when the upstream prefix changes to update its own DNS record.

[AdSchellevis]

The problem with adding more similar problems that are already in there makes it eventually harder to fix the real problem (which is the entanglement of the service). I do agree that similar constructs do exist within the same module, but that doesn't mean we should increase the maintenance problem which someone will have to fix at some point in time.

As @fichtner already noted, it's also not certain we are trying to fix the right thing here. (I only looked at the technical implications so far)

[froogl]

BTW: If you need prefix-aware DNS-hosts you could just use dnsmasq. It has native support for this (see --dynamic-host feature). It's just lacking a GUI option in OPNsense right now so maybe it would be wiser to put more energy into the dnsmasq UI for this particular use-case.

[TheOfficialMrBlah]

Hi,

what is a good and easy workaround, as a replacement for this PR?
So how do I create a host override with a Dynamic Prefix in Unbound?

I face the same problem that I have a new prefix every day.

[AdSchellevis]

closing, currently not a core priority and doesn't fit unbound's architecture very well.