Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Add ability to override hosts per interface.

This has mentioned before, eg here:

#6789

I'm going to suggest an approach that (hopefully) does not change the existing code/UI
too much.

Describe the solution you like

Current behaviour:

In unbound->Overrides->Host Overrides
you can currently

1. override individual hosts

for example:

foo.example.com -> 10.0.0.1

2. wildcard overrides

for example:

*.example.com -> 10.0.0.2
(this means anything.example.com gets resolved to 10.0.0.2)

These end up as the following unbound config:

1. foo.example.com ->10.0.0.1

local-data: "example.com A 192.168.1.100"

2. *.example.com -> 10.0.0.2

local-zone: "example.com" redirect
local-data: "example.com A 10.0.0.2"

The proposal would add the following

3. bar.example.com -> 10.0.0.3 interface LAN

In the UI, an additional drop down box would list current interfaces
when creating a host override. Here the user has selected LAN from
the drop down (default would be "all interfaces", existing behaviour).

the generated unbound config would be (approximately):

# "eth0" deduced from LAN, not entered by user
interface-tag: eth0 "LAN"
interface-tag-data:  eth0 "LAN" "bar.example.com A 10.0.0.3"

4. *.example.com -> 10.0.0.4 interface OPT

Here the user has selected OPT and entered * into the host field.

The generated unbound config would be (approximately):

local-zone: "example.com" redirect
interface-tag: eth1 "OPT"
interface-tag-data: eth1 "OPT" "example.com A 10.0.0.4"

Describe alternatives you considered

unbound 'views' - hard to isolate more general purpose 'view' configuration.
Feels like adding it to existing host overrides would not be the way to go.

Additional context

I think most people currently do this with views, but tags seem a potentially
easier way to extend the current host overrides without changing too much.

Note: I have not yet tested the tag based configuration - I've just read the unbound man pages.

Would need to gracefully handle the cases where an interface is deleted or
changed. (Presumably there is some prior art.)

I have had a quick look at the code and adding an UnboundInterfaceField to the Unbound.xml model
seems doable. The functionality to handle the case where an interface
has been selected could be kept fairly separate from the current host override loop
ie add a new "if" statement that calls a new function then
continues the loop, leaving what's there relatively untouched.

Re-reading #6789 :
There is a mention of using python modules for large lists.

That argument could apply for the existing host overrides implementation.
If, in the future, the existing host overrides were ported to a python module the
new per-interface overrides could be ported at the same time.

With the current behaviour we would just be creating a record like this when a new host
override on an interface is created:

interface-tag-data: eth1 "OPT" "example.com A 10.0.0.4"

as opposed to a record like this where no interface is selected:

local-data: "example.com A 10.0.0.2"

which seems ok.