s4: dns: Add customizable dns port option

Add customizable dns port option

Help needed

This is my first contribution to Samba. It's mostly done the cargo-cult way, and I may have missed something important.

I noticed that if I set dns port 54 in smb.conf, doing testparm -v -s | 'grep dns port' gives me dns port 54 as expected, but when I don't set any port and let the configuration being default, I get dns port 0 which is wrong, I expect dns port 53.

I don't know what I may have missed, so help would be greatly appreciated. That's also why I flagged this MR as Draft.

Help was provided and it now works as expected.

Motivation for this change

An AD DC usually provides many services like, Kerberos, LDAP, NTP, DNS, DHCP, etc. but Samba does not provide all those services (it's really fine). I usually install an AD DC using those softwares:

• Samba: Kerberos, LDAP, DNS, etc.
• NTPsec: NTP
• Dnsmasq: DHCP, DNS

There is an overlap with DNS service. Samba builtin DNS is enough to provide the default DNS configuration an AD DC requires without manual configuration by the sysadmin (this is very convenient), it can also populate entries on net join. This is why the DNS service is kept enabled.

But this builtin DNS service may not fulfill all needs a sysadmin may have. Also, it is not very friendly with version controlled configuration.

The Dnsmasq service is very handy as it allows to provide all the DHCP features an AD DC needs, and allows to very easily manage the entries: one single line contains the hostname, the mac address, and the ip address. It also makes easy to add some specific DNS entries Samba forget to add (It reminds me I should look if there are already reported issues about that). Also because Dnsmasq provides both DHCP and DNS services, it is able to properly resolve with DNS the DHCP client-supplied hostname (not all systems may rely on AD DC services or expect an AD DC to be present).

There are multiple ways to extend Samba DNS:

1. Use Samba DNS as front, and set another DNS as upstream in Samba. The problem with that approach is that it's only good to use the DNS upstream for domains that are not part of the local domain. Typically you would expect to resolve local domains with Samba and Internet domains with the upstream DNS. I never succedeed to extend the local domain this way.
2. Use the Bind Samba backed. This is an option that is ruled out in the described scenario since it replaces and then prevents Dnsmasq to be used. For DHCP client supplied hostname there may be ways to also configure ISC DHCP Server to also use the Bind backend but this is just adding complexity where Dnsmasq does the things very well. Also it adds one more service to administrate, and some conveniences are lost like the quoted ability to store hostname, mac and ip address on the same line of a configuration file. The current Samba recommendation is to use the Bind backend for “for complex DNS setups”, as stated in the documentation, but it was always ruled out on all AD DC I installed because of the large increase of complexity, not only extending the amount of services to manage (going from {Samba, NTPsec, Dnsmasq} with simple Samba and Dnsmasq configuration to {Samba, NTPSec, ISC DHCP Server, Bind} with complex Samba, ISC DHCP Server configuration. Also this may adds some weakeness when using named configuration, since the DHCP server requires DNS server to be up and running to resolve names used in its own configuration (even when not using Bind backend).
3. Use Dnsmasq as a front, resolve all the non-local domain names with some non-local upstreams, resolve all the Dnsmasq-defined local domain names and other entries, use Samba as upstream for any local domain name or entry that is not defined by Dnsmasq itself. It even allows to easily set-up multiple DNS caches as DNS alternate servers for clients even if there is only one AD DC.

The problem of using Dnsmasq as a front is that both Dnsmasq and Samba will attempt to use the same DNS port, while only the front requires to use the standard port. As far as I know Dnsmasq can use an upstream DNS server with non-standard port, but Samba can't host the DNS server on a non-standard port. To workaround the issue, setting-up an AD DC this way requires to:

• Set two IP addresses on the same Ethernet interface, which means:
• Turning Ethernet IP configuration to manual usually by manually configuring things like NetworkManager or netplan or other Networking solution (and then, the interface name has to be known in advance, it also consumes two IP addresses instead of one for each primary or secondary AD DC), instead of letting just the server with zero configuration and let Dnsmasq provide the IP to the AD DC Ethernet itself like any other system (which only requires to know the mac in advance, which is more deterministic than Ethernet interface name, and usually generated on virtual machines, and only needs to edit the Dnsmasq DHCP configuration like any other host instead of splitting the config between two services); This brings also some complex issues when configuring over the network since you need to modify the network configuration you're connected to, and other problems like: you have to boot and connect to the system to know the interface name, but you need to setup network before being able to connect to.
• Uselessly over-complexify firewall configuration;
• Define one more domain name for the secondary address for proper named configuration;
• Modify default Samba configuration to bind on a specific IP address (the first one);
• Modify default Dnsmasq configuration to bind on a specific IP address (the second one) instead of just relying on its default configuration that listens on anything that's available;
• Modify Dnsmasq service unit to not run before Ethernet interfaces are up and configured (since we have to bind on the secondary IP addresses);
• Configure Dnsmasq to provides client via DHCP the primary IP address for all services but DNS instead of having an nice unified configuration;
• and maybe other things I forget.

On the other hand, if Samba becomes able to bind its builtin DNS server on an arbitrary port (for example, 54), it is expected for the Dnsmasq configuration to just add this line:

server=/local-domain.example.com/127.0.0.1#54

and for the Samba configuration to just add this line:

dns port 54

And it is expected to be only that, no more, keeping some other service configuration as default if not nonexistent, keeping other configuration simple, and forget about any other very complex solutions.

I'm using the “Dnsmasq as a front” layout in production since 6 years without any issue and deployed it many time without any issue. While it is super strong while set up, the inability for Samba to bind on a custom DNS port and the very complex network configuration required to workaround this just makes my configuration scripts overly complex and hardly reliable and I would like to reduce the cost of setting up AD DC servers. That's why I submit this PR.

Checklist

• Commits have Signed-off-by: with name/author being identical to the commit author
• (optional) This MR is just one part towards a larger feature.
• (optional, if backport required) Bugzilla bug filed and BUG: tag added
• Test suite updated with functionality tests
• Test suite updated with negative tests
• Documentation updated
• CI timeout is 3h or higher (see Settings/CICD/General pipelines/ Timeout)

Reviewer's checklist:

• There is a test suite reasonably covering new functionality or modifications
• Function naming, parameters, return values, types, etc., are consistent and according to README.Coding.md
• This feature/change has adequate documentation added
• No obvious mistakes in the code