Services: Kea: DDNS: Add qualifying suffix usage to docs (#863)

* Services: Kea: DDNS: Add qualifying suffix usage to docs

* Add attention note for DDNS updates

* Small style fixes

* Pools had a tab mixed in
This commit is contained in:
Monviech 2026-03-26 09:40:35 +01:00 committed by GitHub
parent 15b49e0d44
commit b3cea75250
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -92,7 +92,7 @@ This is the DHCPv4/v6 service available in KEA, which offers the following tab s
========================================= ====================================================================================
Subnet Subnet to use, should be large enough to hold the specified pools and reservations
Description You may enter a description here for your reference (not parsed).
Pools List of pools, one per line in range or subnet format (e.g. 192.168.0.100 - 192.168.0.200 , 192.0.2.64/26). Leave this blank if you do not want to offer dynamic leases (i.e: "Deny unknown clients")
Pools List of pools, one per line in range or subnet format (e.g. 192.168.0.100 - 192.168.0.200 , 192.0.2.64/26). Leave this blank if you do not want to offer dynamic leases (i.e: "Deny unknown clients")
Match client-id By default, KEA uses client-identifiers instead of MAC addresses to locate clients,
disabling this option changes back to matching on MAC address which is used by most dhcp implementations.
**DHCP option data**
@ -111,7 +111,8 @@ This is the DHCPv4/v6 service available in KEA, which offers the following tab s
IPv6-only Preferred (Option 108) The number of seconds for which the client should disable DHCPv4. The minimum value is 300 seconds.
Options Select custom DHCPv4 options that were created in the options tab.
**Dynamic DNS**
DNS forward zone DNS zone where DHCP clients should be registered (e.g. home.arpa)
DNS forward zone DNS zone where DHCP clients should be registered (e.g. "home.arpa.").
DNS qualifying suffix If a DHCP client only sends a hostname in option 81, append this suffix to create an FQDN (e.g. "home.arpa.").
DNS server Authoritative DNS server receiving dynamic updates.
TSIG key name TSIG key name used for secure DNS updates.
TSIG key secret Base64 encoded TSIG key secret.
@ -128,13 +129,14 @@ This is the DHCPv4/v6 service available in KEA, which offers the following tab s
Allocator Select allocator method to use when offering leases to clients.
PD Allocator Select allocator method to use when offering prefix delegations to clients
Description You may enter a description here for your reference (not parsed).
Pools List of pools, one per line in range or subnet format (e.g. 2001:db8:1::-2001:db8:1::100, 2001:db8:1::/80). Leave this blank if you do not want to offer dynamic leases (i.e: "Deny unknown clients")
Pools List of pools, one per line in range or subnet format (e.g. 2001:db8:1::-2001:db8:1::100, 2001:db8:1::/80). Leave this blank if you do not want to offer dynamic leases (i.e: "Deny unknown clients")
**DHCP option data**
DNS servers DNS servers to offer to the clients
Domain search The domain search list to offer to the client
Options Select custom DHCPv6 options that were created in the options tab.
**Dynamic DNS**
DNS forward zone DNS zone where DHCP clients should be registered (e.g. home.arpa)
DNS forward zone DNS zone where DHCP clients should be registered (e.g. "home.arpa.").
DNS qualifying suffix If a DHCP client only sends a hostname in option 81, append this suffix to create an FQDN (e.g. "home.arpa.").
DNS server Authoritative DNS server receiving dynamic updates.
TSIG key name TSIG key name used for secure DNS updates.
TSIG key secret Base64 encoded TSIG key secret.
@ -432,12 +434,13 @@ KEA allows registering client FQDNs via dynamic DNS (RFC2136) to an authoritativ
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 usually provides a `Domain Option` (DHCP option 15). This allows the client to construct an FQDN out of their configured
hostname, and this domain. The DHCP server will receive this as `Client FQDN Option` (DHCP option 81), registering the hostname in the best matching configured forward zone.
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.
.. Attention::
The client is responsible to send the Dynamic DNS update request via DHCP option 81. Only with this payload, the hostname will be registered in a forward zone.
Clients that do not send any hostname cannot be registered, the administrator must ensure all of their devices have unique hostnames configured.
As an example setup, we have configured a zone like this in ISC BIND.
@ -469,6 +472,7 @@ Domain name ``four.example.com``
**Dynamic DNS**
DNS forward zone ``four.example.com.``
DNS qualifying suffix ``four.example.com.`` (optional, use if your clients do not send an FQDN via DHCP option 81)
DNS server ``203.0.113.1``
TSIG key name ``key.four.example.com.``
TSIG key secret ``bZEG7Ow8OgAUPfLWV3aAUQ==``
@ -494,6 +498,10 @@ The DDNS Agent attempts to match each request to the appropriate DNS server and
but different `TSIG key names` and `TSIG key secrets`, only the first one will be taken into account.
Best practice would be creating one unique `DNS forward zone` per subnet, each with a unique `TSIG key name`.
.. Attention::
Only subnets that have a DNS server configured will send DDNS updates.
Prefix Delegation (IA_PD)
------------------------------------------