wizard: auto configure DHCP/DNS registration query forwarding

[Monviech]

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

Is your feature request related to a problem? Please describe.

Up for discussion.

To improve the out of box experience, it would be great if dnsmasq and unbound could have the following initial configuration added:

• Dnsmasq: Listening on port 53053 for DNS queries
• Unbound: A query forwarding for the domain entered in the configuration wizard (e.g. host.internal.example.com would result in a query forwarding of "internal.example.com -> 127.0.0.1:53053" in Unbound)
• Unbound (Optional): An additional PTR record forwarding the chosen network, e.g. 1.168.192.in-addr.arpa

No other configuration is necessary, dnsmasq automatically sets the domain as local in the template to avoid query loops.

Dnsmasq automatically tracks the current system domain, and DHCP FQDN is enabled by default:

core/src/opnsense/mvc/app/controllers/OPNsense/Dnsmasq/Api/SettingsController.php

Line 79 in 0923d4a

$data[self::$internalModelName]['dhcp']['this_domain'] = (string)Config::getInstance()->object()->system->domain;

Describe the solution you like

The DHCP registered DNS names working automatically when configuring OPNsense out of the box, just like prior with ISC + Unbound.

Do not track changes to this afterwards, e.g. if a user changes the domain in the settings, or deletes the query forwarding in Unbound, just the wizard will configure this when followed.

config.xml.sample example:

  <dnsmasq>
      <enable>1</enable>
      <port>53053</port>
      <interface>lan</interface>
      <dhcp_ranges>
          <interface>lan</interface>
          <start_addr>192.168.1.100</start_addr>
          <end_addr>192.168.1.199</end_addr>
      </dhcp_ranges>
  </dnsmasq>
  <unbound>
    <enable>1</enable>
    <dot>
      <enabled>1</enabled>
      <type>forward</type>
      <domain>internal</domain>
      <server>127.0.0.1</server>
      <port>53053</port>
      <verify/>
      <forward_tcp_upstream>0</forward_tcp_upstream>
      <forward_first>0</forward_first>
      <description>Forward default domain to Dnsmasq DHCP</description>
    </dot>
    <dot>
      <enabled>1</enabled>
      <type>forward</type>
      <domain>1.168.192.in-addr.arpa</domain>
      <server>127.0.0.1</server>
      <port>53053</port>
      <verify/>
      <forward_tcp_upstream>0</forward_tcp_upstream>
      <forward_first>0</forward_first>
      <description>Forward default PTR to Dnsmasq DHCP</description>
    </dot>
  </unbound>

Describe alternatives you considered

Refering to the documentation to set it up:
https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

[Monviech]

https://forum.opnsense.org/index.php?topic=48744.0

[fallenguru]

I'd just like to respectfully suggest that using dnsmasq as the client-facing DNS server and having it forward non-local requests to Unbound (i.e. some version of https://docs.opnsense.org/manual/dnsmasq.html#dnsmasq-as-primary-dns-resolver) might be the better default.

The rationale being that (DHCP) clients that supply a hostname, or are assigned one via one of the various mechanisms dnsmasq has for this, can automatically accessed by name, including reverse lookups. IMHO, this is the expected OOTB behaviour, for a home/SMB router at least.
No further configuration required, and it won't break on user changes, unlike the currently recommended setup (https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration) or the setup proposed by the submitter.

IMHO, the benefits, to quote the docs: "a less complicated configuration and less adjustments in Unbound if new networks get introduced" far outweigh the loss of "Unbound statistics or blocklist features based on client IP" in a default configuration. Not least because the statistics need to be enabled manually and any blocklists require user configuration anyway.

Full disclosure: I'm coming from https://old.reddit.com/r/opnsense/comments/1nmc95n/whats_the_rationale_behind_having_clients_use/.

[Monviech]

I disagree here because e.g. Unbound blocklist source selection is on the roadmap:

#9136

With the current recommended setup you get all benefits from Unbound and Dnsmasq with the least functionality tradeoffs. The configuration is a bit harder, but the balance is hard to strike between multiple usergroups with different expectations.

[fallenguru]

I don't see how Unbound blocklist source selection would be impacted; blocking based on the target still works; it's only source-based blocking that breaks when all requests appear to come from localhost. I.e. you only lose the ability to use different blocklists based on client IP.

Anyhow, I do not want to get into an argument, I just wanted this on the record, so, peace. :)

[Monviech]

I understand your initial point and its valid, though there is also KEA and it would be quite confusing why dnsmasq has to run when Kea and Unbound are enabled and why it has to be deconfigured in that case for DNS.

There are so many possible configurations for each kind of setup that its hard to find the best overall solution.

Right now it is how its planned.

Also dont worry discussing this helps.