Unbound DNS registration not working for failover DHCP configuration

[gromit]

I have a HA setup currently running OPNsense 22.1.5.  The HA has been working well but recently, when I went to configure HA DHCP (https://docs.opnsense.org/manual/how-tos/carp.html#optional-setup-dhcp-server), I find that the resultant setup does not work correctly for me---at least it does not work as I expect it to do.

The way in which it is not working is this: I have the "DHCP Registration" option of Unbound enabled but hostnames are not registered correctly in the local DNS.  Hostnames are registered only in the DNS of the HA node whose DHCP server issued the DHCP lease of the client.

Is this how it is supposed to work?  As I say above, this is not how I would expect things to work.  I would expect DHCP-registered hosts to be resolvable in both the active and passive nodes.

Here is an example:

HA Node A leases include this:

Code: [Select]

Interface   IP address      MAC address       Hostname Description Start                   End                     Status Lease type
PLUMBING    192.168.115.174 00:50:56:97:38:32                      2022/04/11 18:29:56 UTC 2022/04/11 20:29:56 UTC |||||  active
APP         192.168.116.177 00:50:56:97:89:1b rum-dev              2022/04/11 18:32:02 UTC 2022/04/11 20:32:02 UTC |||||  active
HA Node B leases include this:

Code: [Select]

Interface   IP address      MAC address       Hostname Description Start                   End                     Status Lease type
PLUMBING    192.168.115.174 00:50:56:97:38:32 awx-test             2022/04/11 18:29:56 UTC 2022/04/11 20:29:56 UTC |||||  active
APP         192.168.116.177 00:50:56:97:89:1b                      2022/04/11 18:32:02 UTC 2022/04/11 20:32:02 UTC *      active
||||| = "Online" graphic; * = "Offline" graphic.


From HA Node A, I can resolve rum-dev but not awx-test and vice versa from HA Node B. I would expect that the "DHCP Registration" Unbound option would allow DHCP hostnames to be resolvable from both Node A and Node B.

In my DHCPv4 configuration I have the CARP VIP set for "DNS Servers" and "Gateway" and the "Failover IP" points to the real IP address of the opposite node in the HA pair.

Should this work or am I misconfiguring something?

Note: Static DHCP entries work fine, DNS-wise.

[franco]

Yes, the DHCP synchronisation protocol does not include the host name.


Cheers,
Franco

[gromit]

Yes, the DHCP synchronisation protocol does not include the host name.


Cheers,
Franco

Many thanks, Franco for confirming this.

So, would it be fair to say if I wanted DNS registration of DHCP hostnames in a HA OPNsense setup I should opt for one of these options:

• Stick to DHCP static mappings
• Use DHCP relay or otherwise offload DHCP onto some external HA DHCP service

Is there any other solution I might have missed?  (I'm inclined to opt for DHCP static mappings.)

[franco]

Right, these are the options. Static mappings is the contained solution since it then can use XMLRPC to sync the known hostnames to both systems.


Cheers,
Franco

[j_s]

I have had this problem for months, and finding this thread is really bad news for my long term plan for our corporate network.  It hasn't been an issue worth investigating and I finally had a chance to look into it today, and found this thread.

This is devastating news for Opnsense with HA where DHCP leases are needed to be in DNS and you have a lot of devices (we'd potentially have more than 2500 devices in less than a year, and doing static IPs is really not convenient for that number of devices).

[franco]

It's strange to put it that way when isc-dhcp never supported this. Luckily there are options to use external DHCP servers that can possibly do this. A lot of companies go this route because they have one running and integrated into their network already.


Cheers,
Franco

[Patrick M. Hausen]

I am not happy with the architecture of the DHCP-Unbound integration. But I don't want to complain about a piece of software that someone provides for free and that solves a problem, either. So this is what we have for now.

What we should do in the future, though, is teach the BIND plugin to handle proper DDNS updates from dhcpd. You know, standards and stuff  [1] The DHCP server part is already in place in both the server software and OPNsense. For BIND the server of course can do it, but the UI and middleware parts in OPNsense are missing for now.

I will probably start to work on that in a couple of weeks. I have two other OPNsense issues on my desk that I need to address first. Now that I found why my development environment stopped working ...

Kind regards,
Patrick

[1] https://datatracker.ietf.org/doc/html/rfc2136

[franco]

As discussed earlier that would be good solution to work towards, yes.


Cheers,
Franco

[j_s]

It's strange to put it that way when isc-dhcp never supported this. Luckily there are options to use external DHCP servers that can possibly do this. A lot of companies go this route because they have one running and integrated into their network already.


Cheers,
Franco

Yeah, I had no idea about this limitation until yesterday when I posted.  I've not worked with HA configurations of Opnsense until Q4 2021.  So I'm learning as I go what does/doesn't work well together and how to work around things.

One thing I did find with the 21.7 versions is that if you turned on "promiscuous mode" for that interface, everything seemed to be fine.  We tried it as a "well, what do we have to lose if it doesn't work?" and it worked.  I have no idea what other consequences there would be for leaving that on 24x7.  But as the router is horribly overpowered for its use (and despite having 2500 clients, they'll never have more than about 500Mb/sec of traffic total as they aren't desktops and such with any kind of possible high throughput needs) I figured I'd never have a problem.

Once 22.1 came out then it stopped working, and I just accepted that it didn't work.  I have no idea if promiscuous mode should have fixed it or it was just a happy side-affect.

I'm also considering the possibility of setting the failover split to 256.  In the event of a failover (planned or unplanned) I could handle the DNS not resolving while all the devices obtain new IPs from the other device.

I'm going to explore the options with promiscuous mode and failover split in more detail this weekend or next week and I'll report back what I find.

I'm going to pm you pmhausen to discuss some things about this in more detail.  The company I'm working with may be willing to sponsor this code.

[random1104]

Hello!, did anybody test this further?. I have the same situation, we're some hostnames can be resolved (whatever was served by firewall A, but any lease served by firewall B fails to resolve).

I understand static mapping would "solve" this, but it not always desired (highly dynamic environments)

[evertux1]

Hello!, did anybody test this further?. I have the same situation, we're some hostnames can be resolved (whatever was served by firewall A, but any lease served by firewall B fails to resolve).

I understand static mapping would "solve" this, but it not always desired (highly dynamic environments)

As DNS By itself is capable of providing ultimate redundancy -> the whole internet relies on that principle  , couldn't it make sense to just use the DNS function which is intended for this case? I talk about using DNS-Replication. so "Opnsense device 2" just replicates from "Opnsense device 1" and in case of failure "Opnsense device 2" continues to work, only new DNS-Records will not be created automatically, till you exchange the primary and secondary role.

regards

M.

[amir]

I have the same issue and this is a big deal. In a dynamic environment with lots of nods, this is an issue?
Can we solve this somehow with DNS?