Why Does Dynamic DNS Update the Wrong Public Address?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Why Does Dynamic DNS Update the Wrong Public Address? - Zima Store Online

Dynamic DNS updates the wrong address when the updater observes a different interface or internet exit than remote clients must reach.

In a home network, the router may report a private WAN address behind another gateway, a server-side updater may see a VPN or proxy exit, an IPv6 updater may overwrite an IPv4 record, or two clients may update the same hostname from different locations. The diagnosis begins by choosing one public-address source of truth and then identifying exactly which updater, record, address family, and detection method produced the wrong value.

Compare Three Addresses at the Same Time

Record the DDNS record, the router’s WAN address, and the public address observed by an external IPv4 or IPv6 service. Add timestamps so a legitimate recent change is not mistaken for a wrong update.

A TP-Link community case showed a router reporting an address from a provider NAT pool while the outside internet saw a different address, leaving the DDNS hostname pointed at the wrong WAN-side address.

If all three match, the problem is probably DNS caching or remote reachability rather than the update value. If the DDNS record matches the router but not the external address, investigate upstream NAT; if it matches neither, inspect the updater configuration and logs.

Identify How the Updater Detects the Address

Determine whether the DDNS client reads a named interface, asks the router, parses a local gateway, uses the source address of the update request, or queries an external “what is my IP” service.

A Zyxel community discussion asks why a firewall behind another NAT router cannot automatically update the true public address when it only knows the upstream private WAN address.

Choose external detection when the updater sits behind NAT and the provider supports it. Choose interface detection only when that interface actually owns the public address; otherwise, a perfectly functioning updater can publish the wrong value by design.

Check for Double NAT and CGNAT

Inspect whether the router WAN address falls inside a private or shared range and whether another modem or ISP gateway performs the first NAT. Dynamic DNS can publish an address, but it cannot create inbound forwarding through an upstream network you do not control.

A German Synology support-forum case reported that provider NAT caused DDNS to detect an address that was not the actual public endpoint.

If you control the upstream router, place the downstream router in bridge mode or forward the required path through both layers. If the ISP uses CGNAT, request a public address or use an outbound tunnel or relay rather than repeatedly changing the DDNS client.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Separate IPv4 and IPv6 Updates

Inspect the A and AAAA records independently and compare each with an external test for the same address family. Do not assume one successful IPv6 update proves the IPv4 record is correct.

A client configured to monitor one interface may publish a temporary IPv6 address, a delegated-prefix address that later changes, or an IPv4 address from a VPN exit. Keep separate update jobs and provider records when the address families have different lifecycles.

Disable only the suspect address-family update and repeat the test. If remote access recovers when the incorrect AAAA or A record is removed, repair that path before restoring dual-stack DNS.

Find Duplicate Clients and Wrong Record Targets

List every router, NAS, container, script, cloud host, and mobile device that has credentials to update the hostname. Two valid clients in different locations can repeatedly overwrite one another.

Dynu users have documented cases where one update client caused multiple records to share one IP because the account or client configuration targeted more records than intended.

Give each location and address family a distinct hostname, token, and update job. Revoke unused credentials and confirm the log names the exact record being changed before trusting a success message.

Validate the Record Through a Real Address Change

After correcting the detection method and updater ownership, force a safe WAN reconnect or wait for the next legitimate address change. Record the new external address, update log, authoritative DNS answer, recursive resolver answer, and remote connection result.

The ZimaSpace guide to why remote access follows old IP state provides the next stage after the DDNS value itself becomes correct.

The issue is resolved only when one approved updater publishes the correct IPv4 or IPv6 address, no second client overwrites it, the authoritative answer changes within the expected interval, and an external client reaches the intended home service.