Dynamic DNS, or DDNS, automatically updates a hostname's DNS records when its IP address changes. A DDNS client running on a router, server, or other device detects the intended public IPv4 or IPv6 address, authenticates to a DNS service, and updates the corresponding record. Later lookups can return the new address once the DNS service publishes the change and cached answers are refreshed.

DDNS changes DNS data only. It does not open a firewall, create a port forward, bypass carrier-grade NAT, start a service, or guarantee that a domain will always be reachable. Those are separate network and application requirements.

Why Dynamic Addresses Need an Updater

Many internet connections receive addresses that are not permanently assigned. An ISP can change an IPv4 address after a reconnect, lease event, equipment change, or network operation. IPv6 prefixes and individual IPv6 addresses can also change according to provider and device policy.

A static DNS A record continues to contain its old IPv4 address until someone edits it. An AAAA record behaves the same way for IPv6. DDNS automates that edit so a stable hostname, such as gateway.example.com, can follow the selected address.

The updater must select the address that should receive incoming connections. A router can read its WAN interface, but an upstream router or carrier-grade NAT may give that interface a private or shared address instead of a public one. An external address-discovery service can report the source address it sees, although a request sent through a VPN may reveal the VPN exit address. Check that the result belongs to the intended connection.

IPv4 and IPv6 need separate address checks. For an IPv6 service on an internal host, the AAAA record normally needs that host's globally routable address, not the router's WAN address. A host may also have link-local and temporary privacy addresses, so choosing the first address in a list is unreliable. Select an address intended for incoming connections and keep the record updated if that address or its network prefix changes.

How the DDNS Update Cycle Works

The client first reads or discovers the current address. It compares that value with the last successful update, the provider's record, or another stored state. When the intended address has changed, the client sends an authenticated request to the DNS provider or primary DNS server.

Consumer DDNS services often accept updates through an HTTPS endpoint or a provider API. Other DNS servers support the DNS Dynamic Update protocol, with authentication and permissions configured on the server. The client must use an update method supported by the DNS service.

The update specifies the hostname, record type, new address, and sometimes a TTL, along with any zone or record identifier the service requires. A successful response shows that the DNS service accepted the request. The new data must still reach the authoritative name servers, which serve the zone's records, before those servers can answer with the new address. Recursive resolvers may continue returning cached answers, as explained below.

The client records the result and waits for the next change or scheduled check. Repeatedly sending the same value can exhaust the provider's request allowance, so follow its refresh requirements instead of sending continuous updates. After a failed request, the client should wait before retrying and increase that delay up to a configured limit if failures continue.

Protect DDNS Updates

Anyone who obtains the update credential may be able to change the DNS records it controls. Restrict the DDNS client's permissions to the required zone, names, and record types wherever the platform supports those restrictions. An account-wide token could expose unrelated DNS records or account settings if the updater is compromised.

Store the credential using the platform's protected secret facility, restrict file and configuration permissions, and keep it out of command history and logs. Use authenticated encrypted transport for provider APIs. Standards-based dynamic updates should use the server's supported authenticated update mechanism and a narrowly defined update policy.

Run only one active updater for a record unless multiple clients are configured to coordinate their updates. Two routers or scripts that detect different outgoing addresses can repeatedly replace the same DNS record with conflicting values. Logs should identify the client and selected address without exposing the token.

Validate the address before publishing it. For a public endpoint, reject malformed input, the wrong IP version, and addresses reserved for loopback, link-local, private, or carrier-grade NAT use. If the same name has a different address inside the network, update that internal DNS record separately using the appropriate permissions.

Why the Old Address Can Remain Visible

DNS resolvers cache answers. A recursive resolver can normally reuse an old A or AAAA answer until its remaining TTL expires, so clients using different resolvers may receive the new address at different times. Some resolvers can also serve an expired answer when they cannot obtain a fresh one, so TTL expiration does not always end the delay.

The updater cannot remove answers already stored in other resolvers' caches. A shorter TTL reduces normal cache retention, but it also increases DNS queries and makes clients depend more often on the authoritative servers being available. Choose a value supported by the DNS provider that suits how quickly clients need to discover address changes.

A DNS answer saying that a name or record does not exist can also be cached. If an updater deletes a record before creating its replacement, a resolver may query during the gap and retain that negative answer. Where supported, replace the record in a single update instead of using separate delete and create requests.

Local application and operating-system caches may add delay beyond what one recursive query shows. An existing connection can continue using the old destination without performing DNS again. DDNS controls future name resolution; it does not migrate live sessions.

Reachability Is a Separate Test

A correct public DNS answer only maps a name to an address. For IPv4 behind a router, inbound connectivity may require a supported port-forwarding rule and a firewall policy. For IPv6, the destination may have a global address while the firewall still blocks unsolicited inbound traffic.

Carrier-grade NAT places multiple subscribers behind an ISP-controlled public IPv4 address. Updating a hostname to that shared address does not give the subscriber control over inbound mappings. DDNS is therefore not a CGNAT bypass.

The service must also listen on the expected interface and port and use a valid certificate when TLS is required. A private service needs appropriate access controls, such as authentication, as well. If an address update succeeds but the application remains unavailable, check routing, NAT, firewall rules, and the service itself separately from DNS.

Verify a Hostname Update in Stages

For a DNS record that points directly to the service, compare the intended public address with the address detected by the DDNS client, the authoritative answer, and the answer from a recursive resolver. Differences help locate a problem in address discovery, publication, or caching. A record served through a proxy may return the proxy's address instead of the service's address.

First, check the router or service host for the address that should be published, accounting for upstream NAT or a VPN. Compare that address with the updater log, including the request time, DNS provider's response, and record identifier. Remove credentials and unrelated network data before sharing logs.

Second, query the authoritative name servers directly for each updated type:

dig @authoritative-server.example. gateway.example.com. A +norecurse +noall +answer +comments
dig @authoritative-server.example. gateway.example.com. AAAA +norecurse +noall +answer +comments

Replace the example names with the hostname being updated and an authoritative server for its zone. The options disable recursion and show the answer with the response header; check the status and the aa flag to confirm an authoritative response. Query the other listed authoritative servers as well, since different answers may indicate that some servers have not received the change. Keep the returned addresses and TTLs for comparison.

Third, query the recursive resolvers used by the affected clients. An old answer with time left on its TTL can be expected during normal caching. If the old answer persists, check whether the resolver can reach the authoritative servers and whether it is serving expired data while attempts to refresh the answer fail.

Finally, test the application from an external network where you have permission to do so. A successful application request shows that the service is reachable from that network at that time. Keep the DNS lookup result separate from the application result so a working name lookup is not mistaken for a working service.

Monitor the DDNS Client

Alert when address discovery fails, credentials are rejected, updates are rate-limited, the provider returns an error, or authoritative data does not match the intended value after the normal publication window. Also alert when the client has not checked in for longer than its expected schedule.

Review credentials, token permissions, client software, and DNS provider compatibility after software or account changes. Revoke unused tokens and remove abandoned updater instances. Keep domain registrations and DNS subscriptions current: if a domain or service is suspended or removed, a running DDNS client cannot restore public resolution by itself.