os-bind: dns64 with ability to set ip ranges to exclude

[BPplays]

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/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
i want to use bind to do dns64 with an option to exclude ip ranges

Describe the solution you'd like
i would like the option in /ui/bind/general/index to turn on dns64 and to have the option to disable it for specific ip ranges. this abridged named.conf appears to disable dns64 for specified acls in the version that comes with debian 12:

acl rfc1918 {
   10.0.0.0/8;
   172.16.0.0/12;
   192.168.0.0/16;
};

options {
   directory "/var/cache/bind";
   forwarders {
   	2620:fe::fe;
   };
   forward first;
   dnssec-validation auto;
   listen-on-v6 { any; };
   allow-query { any; };

   dns64 64:ff9b::/96 {
       exclude { rfc1918; };
       clients { any; };
       mapped { !rfc1918; any; };
   };
};

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

[jfieber]

@BPplays, I have a draft implementation of this, but am not quite settled on some UI issues.  As I was working on help text, I realized that with a fairly simple UI it is pretty easy to get the data in place, but also pretty easy to make a syntactically valid, but functionally nonsensical configuration.  So I'm not quite happy with the UI as it stands.  This is also my first venture into the UI side of opnsense, so I'm climbing a learning curve.

Currently it adds a DNS64 tab, allowing for multiple dns64 statements, allowing different clients to be routed through different NAT64 paths.  That part is straightforward.  Below are points I'm not fully settled on.  First, the Bind dns64 syntax for reference:

      dns64 <netprefix> {
              break-dnssec <boolean>;
              clients { <address_match_element>; ... };
              exclude { <address_match_element>; ... };
              mapped { <address_match_element>; ... };
              recursive-only <boolean>;
              suffix <ipv6_address>;
      };
      dns64-contact <string>;
      dns64-server <string>;

Questions:

• Use ACLs, address literals, or a mix for <address_match_element>?
  • Only IPv6 addresses are relevant in clients and excluded.
  • Only IPv4 addresses are relevant in mapped.
  • Indirecting through aliases makes it difficult to sanity-check this and issue a useful warning about syntactically valid but functionally nonsensical configuration. Using literals makes this easy.
  • Allowing a mix of aliases and literals would tend to make the UI more complex for the user, at least without resorting to a lot of custom UI code.
  • Though I started with an alias-based implementation, I'm leaning strongly toward address literals only at this point. Is there a compelling use case where aliases would be a big win and worth the extra complexity?
• UI for include/exclude? A single address list field doesn't provide an out-of-the-box way to mark some address as exclusions (with a leading !), but probably the most common use of mapped would be exclusion of RFC1918 addresses.
  • Alternative A: work out custom validation to allow a !  prefix on addresses.  (I think this would be the best user experience)
  • Alternative B: for each of clients, mapped, and excluded, provide two address list fields, one for inclusion and one for exclusion.
  • Alternative C: for each of clients, mapped, and excluded, provide an "invert" checkbox to specify whether the field corresponding addresses should be included or excluded.  This may cover common use cases, but make some configurations awkward to construct.
• Include a dedicated "Exclude RFC1918" checkbox option?
  • This may be the most common use of the mapped statement in practice.  Make it clear that unless you control the NAT64 service and know for certain it should handle RFC1918 addresses in a sensible way, they should probably be excluded.  Having a dedicated UI option for this could help in emphasizing this point.
  • I think this makes sense but want to nail down the previous two items before adding it.
• Terminology
  • Using the terms "include" and "exclude" in the UI to describe things put in the clients or mapping fields may be confusing when the Bind configuration also has an exclude statement that is used with a more specific meaning.
• Configuration order
  • With multiple dns64 configurations, if a client matches more than one, does Bind use the first one in the order of the configuration file?  If so, it would be desirable to have the configuration list re-orderable, though I'm not sure (yet) how to do this.

[Leseratte10]

<address_match_element>

As for address_match_element, I assume that with "aliases" you mean the ACLs that can be created in the UI under the ACLs tab? Or is an alias something else?

I would prefer if the ACL-based input would be used (just like it's currently the case for "Recursion", "Allow Transfer" and "Allow query") and not like the current implementation for "ACL for filter-aaaa" which is just a text input.

UI for include/exclude? A single address list field doesn't provide an out-of-the-box way to mark some address as exclusions (with a leading !), but probably the most common use of mapped would be exclusion of RFC1918 addresses.

* Alternative A: work out custom validation to allow a `!`  prefix on addresses.  (I think this would be the best user experience)

* Alternative B: for each of `clients`, `mapped`, and `excluded`, provide two address list fields, one for inclusion and one for exclusion.

* Alternative C: for each of `clients`, `mapped`, and `excluded`, provide an "invert" checkbox to specify whether the field corresponding addresses should be included or excluded.  This may cover common use cases, but make some configurations awkward to construct.

I would prefer alternative A. This new validation could then also be applied in other places to fix #4435. It's going to get fairly ugly if every single place where one can add networks would need a 2nd field for exclusions.

[jfieber]

Because of the ubiquity of the { <address_match_element>; ... }; in the Bind config, I've resolved that a custom field type and validator is the best path for this feature, the improving the current ACL definition UI, and future features. I have a rough cut at one that behaves like the standard NetworkField/NetworkValidator duo, but allows for the negation (!) and the builtin ACLs of any, none, localhost and localnets.

(Note: I've corrected my comment above, fixing the use of "aliases" when I meant "ACLs". Brains fail in strange ways sometimes! Thanks for catching that.)