Why Doesn’t My DNS Get Updated by Kea?
  • 28 Aug 2023
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Why Doesn’t My DNS Get Updated by Kea?

  • Dark
    Light
  • PDF

Article Summary

Kea does DNS updates if the client sends either the Host Name or Fully Qualified Domain Name (FQDN) option in the REQUEST.

If the client sends both, the server will use the FQDN. Typically a client would issue a DISCOVER asking for the Host Name and then send it back in the REQUEST, or use it to construct a FQDN option and send that in the request.

If your client is not providing either option, the server does not do DNS.

Additionally, according to RFC 4702, the client is able to specify flags suggesting server behavior as pertains to DDNS updates. Certain combinations of flags specify that the server should do no updates. If the client sets the flags this way, then Kea will perform no DDNS updates.

Force Dynamic DNS updates with Kea

There are some settings that can force DDNS updates to be sent by Kea even if options, as described above, are not sent by the client, or if the client specifies that no updates should be done. There are also options that can override what the client sends, which may be desirable in some cases and overcomes the problem of no FQDN being sent by the client.

  • "ddns-override-client-update": true - Ignores the client's delegation requests. Causes Kea to perform Dynamic DNS updates even though the client indicated its intention to perform the updates itself.
  • "ddns-override-no-update": true - Ignores the client's wishes for no DDNS updates to be performed.
  • "ddns-qualifying-suffix": "example.com" - Sets the contents of the domain part of the FQDN.
  • "ddns-generated-prefix": "dynamic" - Sets the prefix of the host part of the FQDN (defaults to 'myhost' if not specified).
  • "ddns-replace-client-name": "always" - Replaces or generates a client name for use in DDNS, regardless of what the client did or did not send. It is also possible to set the hostname parameter in a reservation, to be used in place of a generated FQDN (and anything the client sent) even if "always" is set for this parameter.

Using the above settings, it should be possible to cover most DDNS needs and prevent client settings from causing unpredictable behavior. If a dynamic client received address 192.0.2.12 from a Kea server with the above settings enabled, forward (A) and reverse (PTR) Dynamic DNS entries would be created for the client with an IP address of 192.0.2.12 and an FQDN of "dynamic-192-0-2-12.example.com", as shown in the examples below.
A:

dynamic-192-0-2-12.example.com IN A 192.0.2.12

PTR:

12.2.0.192.in-addr.arpa. IN PTR dynamic-192-0-2-12.example.com

These entries are created without regard for the information provided for the client hostname or in the RFC 4702 flags during DHCP communication.

Full details for Kea and DDNS are available in the ARM (DDNS server, DHCP4-specific, and DHCPv6-specific).