[Kea-users] Getting Started: Dual-stack Dynamic DNS Updates

[Darren Ankney]

Hi Troy,

see responses in-line

On Fri, Mar 3, 2023 at 4:24 PM Troy Telford <ttelford.groups at gmail.com> wrote:
>
> I’ve been successful so far in getting Kea to serve IPv4 with both forward & reverse dynamic DNS. Thus far I’ve only used SLAAC and static zone files for IPv6 in DNS in my test/educational network. (A small network, so I can learn & experiment).
>
> I’ve had a notion of also learning DHCPv6 so I know how it works. (I’ve a goal to understand and have dual stack DHCP with forward/reverse DNS updates).
>
> It’s already clear it’s different from IPv4 DHCP. I’ve been able to piece together a rough idea of some basics - enough that there are signs of life: I configured `radvd` with the correct flags so macOS & iOS use DHCPv6, for example. it seems many of the hosts are getting IPv6 addresses from Kea-dhcp6, though it’s equally clear I’m missing important details, as things aren’t working as I’d thought:
>
> In this dual-stack environment, it seems kea-dhcp-ddns is sort of all over the place: I’m seeing either IPv4 updates, or IPv6 updates, but not both in DNS.
>
> I want to make sure I understand the situation properly before getting lost in the weeds (ie. Trying to ‘fix’ the wrong thing):
>
>    * Is it true that in a dual-stack environment, it’s necessary for the _client_ to be configured properly in order for `kea-dhcp-ddns` to be able to update the DNS server properly?

No.  You can set these options:

"ddns-qualifying-suffix": "example.com",
"ddns-generated-prefix": "dynamic",
"ddns-replace-client-name": "always",
"ddns-send-updates": true,
"ddns-update-on-renew": false,
"ddns-override-client-update": true,
"ddns-override-no-update": true,

which will force ddns updates and override whatever thing the client
sends as the hostname (tune behavior to your preference by changing
settings above). With those settings, it will make names like:

dynamic-fdfa-96a7-3813-30--233.example.com

You can override that by setting a hostname in a reservation for the client:

"reservations": [
          {
            "hw-address": "00:00:00:63:61:8d",
             "hostname": "somehost-v6"
        }
]

Note that you can reserve with duid also ... your Kea server may not
have access to the mac address.

>        * I’ve read that both v4 and v6 clients need to send the same DUID for ddns to work properly - is that correct?

yes - as ddns will not be able to create the same DHCID otherwise that
was used when adding the DHCPv4 A record.  Note that I added a '-v6'
to the hostname in the reservation for this reason (so that it adds
the AAAA to a different RR thus avoiding the DHCID problem).  There
might be some way to have Kea construct DHCIDs in a predictable way, I
have some vague recollection of that, but I haven't looked into it
deeply yet.

>        * Am I wrong that most Linux distributions, and macOS aren’t configured this way by default? (I haven’t checked Windows yet…)

You are correct - its possible to use an DHCPv6 style DUID in DHCPv4
(there is an RFC for it) but I've never seen a client that does.

>        * I’m sure there are minutae I need to learn - any hints?

Router advertisements are hard to get right.  I suspect yours are not
currently correct and your hosts are doing SLAAC still which is why
you are observing a subnet you didn't configure in DHCP on your
clients.

>    * While I don’t _think_ I’m running into any unimplemented functionality, is there something I should be aware of for the simple goal of dual-stack forward/reverse dynamic DNS? - (I’m using kea-2.2.0 on Debian Sid because I’ve apparently 'lived dangerously' for 25 years.)

I don't know as I'm not familiar with that Debian version.  I am
currently running Debian GNU/Linux 11 (bullseye)

>
> I’ve also noticed that many hosts are getting “new” IPv6 addresses that are from a subnet that’s not link-local (I think), and _not_ the subnet that I’m assigning via DHCPv6: fd75:81b2:5386:4f06::/64.

I suspect SLAAC is still happening.  Check your router advertisements.

>
> * I think it’s something akin to the 169.254 IPv4 address range, but my Google-fu fails me; is there anything special about such a subnet? Why would the interfaces be getting such an address?

fe80::/10 is akin to 169.254.0.0/16. IPv6 makes heavy use of that for
neighbor discovery and routing (via router advertisements).  Thats
really outside of DHCPv6, however.

Thank you,

-Darren