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.