Kea + Unbound + Bind for local name resolution

[cinergi]

Hello,

Just wondering if anyone is using Kea DHCP together with Unbound for default DNS resolution and Bind for local zone resolution via dynamic RFC2136 updates from Kea?  This seems like an elegant way to get local resolution of DHCP-assigned addresses while using Kea instead of dnsmasq.  But does it work well in practice?

Thanks!

[meyergru]

We discussed this back and forth already and not an exact answer to your question, but:

IMHO, the easiest way is to just use Kea DHCP static reservations, where the names of the host entries can directly be used in Unbound directly when you check "Register DHCP Static Mappings". That way, there is no need for any additional DNS resolver and you can control which names are being registered, which cannot be done if the hosts themselves present their names.

The only disadvantage I can see is that you have to create static reservations for all hosts you need to be resolvable, because there is no equicalent of ISC dynamic DHCP bindings in OpnSense's implementation of Kea DHCP yet.

However, I need exactly those hosts to have static IPs as well, so I do not miss anything. Also, more often than not, I also want to have aliases for hosts, sometimes to have different services on the same one, so I need to configure those in Unbound anyway.

[nero355]

The only disadvantage I can see is that you have to create static reservations for all hosts you need to be resolvable, because there is no equicalent of ISC dynamic DHCP bindings in OpnSense's implementation of Kea DHCP yet.

Doesn't the new KEA DDNS feature solve that issue ?!

[meyergru]

That is basically the OPs question. I know that the DDNS feature has been added to Kea recently, but I think that Unbound has no RFC2136 support, so you really need anther DNS server that supports it, like BIND, which makes the setup quite complex.

[nero355]

That is basically the OPs question.

It seems I misunderstood the whole post or something... My bad! >_<

I know that the DDNS feature has been added to Kea recently, but I think that Unbound has no RFC2136 support, so you really need anther DNS server that supports it, like BIND, which makes the setup quite complex.

You are right : https://docs.opnsense.org/manual/kea.html#dynamic-dns-rfc2136

Should have read it first before replying... LOL!

Together with : https://kea.readthedocs.io/en/latest/arm/ddns.html
I think it should be doable to configure everything without needing any kind of HowTo/Tutorial :)



There is just one thing I don't understand :

Why is this mentioned :

KEA allows registering client FQDNs via dynamic DNS (RFC2136) to an authoritative DNS server.

Such an authoritative DNS server will be ISC BIND or an alternative like PowerDNS.
Recursive DNS servers like Dnsmasq or Unbound are not able to fulfill this role.

When clients register their IP address, the DHCP server will receive a Client FQDN (DHCP option 81) that either contains a client hostname or an FQDN. In cases where clients only send a hostname, using the DNS qualifying suffix will construct an FQDN and force an update anyway.

AFAIK one of the advantages or DNSmasqd is exactly that :

Each DHCP Client is also immediately available in the DNS part of DNSmasqd.



Feel like I have completely misunderstood here something... or not... ?!

[Monviech (Cedrik)]

The simplest way for this is to use Dnsmasq because it was made for exactly this purpose.

But there are very large networks where an authoritative nameserver combined with KEA makes sense, its way more scalable.

But none of these ways is inherently cleaner than the other. I would always choose the simplest way with the least moving parts, which is dnsmasq for these home/homelab style setups (I assume most who ask these questions here dont ask for an enterprise setup, because these have proper DNS infrastructure set up already which would naturally benefit from KEA.)

So instead of KEA+Unbound+Bind you can just use Dnsmasq as single unified daemon that does it all with no surprises xD

TLDR
People often underestimate operational complexity and overestimate the benefits of modularity for small deployments.

[dseven]

FWIW; the one thing (that I know of so far) that makes dnsmasq unsuitable for my small "home lab" environment is lack of prefix delegation support. I do use that with a sandbox instance of OPNsense behind my "production" instance.

[allan]

Prefix delegation and dhcp registration into Unbound is why I am still running the ISC dhcpd. Aside from my home lab, Apple's HomeKit uses prefix delegated IPv6 addresses. I guess it assigns IPs to downstream nodes.

[Monviech (Cedrik)]

We just recently added dynamic prefix delegation to KEA in 26.1.9, was one of the roadmap items I worked extensively on.

But the Unbound DNS registration for dynamic hosts will most likely not come, only DHCP reservations are synced with Unbound -> which should actually be sufficient for most setups.

So overall ISC DHCP should be able to be cleanly replaced now.

[allan]

But the Unbound DNS registration for dynamic hosts will most likely not come, only DHCP reservations are synced with Unbound -> which should actually be sufficient for most setups.

I saw a discussion where someone got a script to do that. It is likely the direction I will go, but I figure I'll ride this ISC horse until the sun sets. :)

[Monviech (Cedrik)]

When using KEA I would rather go with Bind like the OP of this thread plans to do. They're like brothers in arms, ISCs own tooling (Stork) combines them both as well.

[allan]

Good point. If I am considering a workaround, I should at least look at other options as well. Thanks for that suggestion.

[allan]

I felt brave and decided to bite the bullet. After about 12 hours, I didn't get it all working so I caught a little hell from my wife. 😬 I think I finally got most of the fires out so below are my notes:

• I decided to break out my different VLANs (e.g. IoT) into their own forward zones. I used sub-zones in the format vlan.domain.tld. This method makes it easier to troubleshoot.
• Uncheck Register ISC DHCP4 Leases and Register DHCP Static Mappings under Services > Unbound > General to avoid creating entries in Unbound since I still have ISC dhcpd installed.
• Restarting Bind caused the zone reload to fail with journal rollforward failed: journal out of sync with zone errors in the Bind log. I used rndc sync -clean to clear out the *.jnl files before restarting. I need to find a better way since I lose DDNS entries without the journal. I tried rndc stop and rndc freeze before clicking Save and neither fixed it.
• Under each Kea subnet DDNS setting, I had to end the forward and reverse zones, and qualifying suffix fields with a dot (.). Otherwise, Bind could not find the correct zone to update.
• I got DDNS update failures with 'RRset exists (value dependent)' errors in Bind for devices that are IPv4+IPv6 dual stack. I think this is due to both using the same DHCID and it became a race to create the first record. I set no-check-with-dhcid in each Kea subnet to fix it.
• My gateway was named "gw.vlan.domain.tld". Even when Unbound is set to forward all vlan.domain.tld queries to Bind, it refused to forward this one. I had to change my gateway domain name under System > Settings > General > Domain to something else.
• Some devices (OpenWRT) only send host names to Kea. This is what "DNS qualifying suffix" was supposed to fix. That setting worked for IPv4 but not IPv6; maybe OpenWRT sent FQDNs on IPv4 but I did not check. Kea logs showed No DNS servers match FQDN hostname. Reserving their IPv6 address fixed it. I think this issue is with upstream but that requires confirmation. Any IPv6 lease that is not FQDN under the Hostname column needs this reservation.
• I used dig @x.x.x.x -p 53530 name to query Bind directly. Otherwise, I got Unbound's cached entry.
• Once everything is confirmed to work, I set Bind to listen on 127.0.0.1 and ::1 so networks cannot query it directly.

So far so good. I had to create some CNAME records for our printer and SIP proxy. This gets Windows and desk phone working until I get time to reconfigure them and switch to using their IoT names instead.