Dynamic DNS (DDNS) is a DNS mechanism that automatically updates host address records when IP addresses change, eliminating the need for manual record edits and keeping hostnames correctly mapped to changing addresses in DHCP and provider-assigned environments. The system works by sending address changes to an authoritative DNS server through RFC 2136 updates or provider services, with authentication controls such as TSIG keys ensuring only authorized senders can modify records. Proper DDNS configuration requires coordinating DNS, DHCP, and IP address management while managing TTL values, reverse zones, and security restrictions to prevent stale records, hijacking, and name conflicts.
How DDNS works
DDNS works by sending a change to an authoritative DNS server whenever a host's address changes. The change can come from the host, from a DHCP server acting for it, or from a provider's update client.
- Address change: A host receives a new IP address from DHCP, a router reconnects with a new address from its internet provider, or a static assignment is edited.
- Update request: The host, the DHCP server or a small update client sends the new address to the DNS server. Standards-based deployments use the dynamic update message from RFC 2136. Many hosted services use an HTTP-based update request instead.
- Authentication: The DNS server checks that the sender is allowed to change the record. Standards-based updates are commonly secured with transaction signatures (TSIG) as defined in RFC 8945, or with other keys. Hosted services typically use account credentials or tokens.
- Record change: The server replaces the old A or AAAA record with the new address and increments the zone serial number so secondary servers can pick up the change.
- Resolution: Clients that query the name receive the new address once cached copies of the old answer expire, which is controlled by the record's time to live (TTL).
Dynamic updates may also remove or adjust related records, such as PTR records for reverse lookups. A short TTL shortens the window in which clients use a stale address but raises query volume.
Common DDNS issues
Records created for DHCP clients remain after the lease ends if the DHCP server does not remove them or lacks permission to do so. Another device later receives the same address and two names resolve to it.
The DNS server returns a REFUSED response when the sender is not authorized, the key or TSIG signature does not match, or the zone does not allow dynamic updates. The record then keeps its old address with no obvious error on the client.
When the DHCP server and the client both try to update the same record, or two hosts claim the same name, one overwrites the other or the update fails. Unclear update responsibility between client and server is the usual cause.
The forward A or AAAA record is updated but the PTR record is not, because the reverse zone is missing, not dynamic or not authorized. Reverse lookups then fail or return an old name, which breaks logging and some authentication checks.
A high TTL on a dynamically updated record lets resolvers keep the old address after the update succeeds. Users see intermittent failures until cached answers expire.