Added support for client-side DNS over TLS/HTTPS/QUIC

[linuxrrze]

Added client-side support for DNS over TLS/HTTPS/QUIC:

This is my first major PR and I'm still struggling with some parts of the OPNsense UI stack, so there will certainly be some rough edges (or things that should be done another way).

For now I was only able to test DNS over TLS, but as the other options came "for free" I also added them.

The former "DNS over TLS" is now available under the "To remote DNS servers" tab.

If something needs to be done differently / fixed, just let me know.

[AdSchellevis]

This looks like a variation of #6558, which hasn't been a priority on our end so far. The comments contain some of our concerns, not sure if/when we will introduce these options at the moment, partly because of the documentation burden it will bring when doing so.

[linuxrrze]

This looks like a variation of #6558, which hasn't been a priority on our end so far. The comments contain some of our concerns, not sure if/when we will introduce these options at the moment, partly because of the documentation burden it will bring when doing so.

Thanks for your fast reply.
Should have taken a look into the existing PRs first... well at least I learned about how OPNsense UI works :-)

And a little off-topic:
Another project I was thinking of was adding support for multiple PXE bootfiles (depending on target architecture (BIOS/UEFI, ARM, ...)) options for KEA DHCP backend. Those were available with the ISC DHCP backend but are missing for KEA at the moment.
Is that something of interest?

[AdSchellevis]

And a little off-topic:
Another project I was thinking of was adding support for multiple PXE bootfiles (depending on target architecture (BIOS/UEFI, ARM, ...)) options for KEA DHCP backend. Those were available with the ISC DHCP backend but are missing for KEA at the moment.
Is that something of interest?

We looked into these earlier, but given the complexity of the kea code it's not likely to mature quickly, see also #7361 for some background. Personally I'm not a big fan of kea and for a lot of use-cases recommend using dnsmasq which already offers these features on our end.

If you do plan to work on kea, it's probably best to start with a ticket describing goal and required (kea) configuration as this also helps placing the changes into context. (very large PR's are time consuming to review, which doesn't always fit our time schedule)