If you are using Dynamic DNS, or are considering implementing it at your home or business, it is important to understand its limitations. Dynamic DNS is not inherently bad or insecure. It is simply a mechanism for keeping a DNS record aligned with a public IP address that changes periodically.

I have encountered Dynamic DNS in several homes and small businesses where it was used to make a locally hosted service accessible from the Internet. I have even seen a business operate its email server over an ADSL connection with a dynamic IP address. Unsurprisingly, this resulted in mail-delivery problems.

You should definitely not operate an email server on a connection that doesn’t have a static assigned IP address. In fact, you probably shouldn’t be operating your own email server these days anyway.

What is Dynamic DNS?

Dynamic DNS (usually abbreviated as DDNS) is a method of automatically updating a DNS record when the public IP address associated with a hostname changes. For example, a hostname such as home.example.com might point to the public IP address assigned to your internet connection. If that address changes, a DDNS client running on your firewall or other device updates the relevant DNS record so that the hostname points to the new address.

Why use Dynamic DNS?

Port forwarding is one of the ways to expose an internal host to the Internet using your public IP address, but many residential and small-business Internet connections do not include a permanently assigned public IP address. Instead, the ISP allocates an address dynamically.

Some dynamically assigned addresses remain unchanged for long periods. However, the ISP does not guarantee that the address will remain the same, and it may change following a router restart, connection reset, lease renewal or network reconfiguration. This means that you often get assigned a different IP address - even if you have an ‘always on’ connection like cable, fibre, ADSL or wireless.

This becomes a challenge when you want to connect to your service from the Internet, becuase the public IP address becomes a moving target. DDNS can be used to work around this problem by updating a DNS record. Without DDNS, you would need to manually determine the new public IP address and update your DNS hostname manually whenever it changed. A DDNS client automates this process by detecting the current public IP address and updating the selected DNS record when it changes.

Although this seems simple enough, there are several caveats to consider.

Update and caching delays

The DDNS client first needs to detect that the public IP address has changed. Depending on the router, software and update interval, this may happen within seconds or may take several minutes. The client must then update the record at the DNS provider. This part is normally quick, but other DNS resolvers may already have cached the previous address.

Each DNS record has a Time to Live, or TTL, which tells recursive resolvers how long they may cache the answer. A frequently changing DDNS record will typically use a relatively low TTL, such as 60 seconds. Until the cached record expires, some devices may continue using the previous IP address. Operating systems, browsers and applications may also maintain their own caches. In some circumstances, recursive resolvers can deliberately serve stale DNS information when they cannot reach the authoritative DNS servers.

Ultimately, this means that a DNS update is not neccessarily immediate for every device.

Availability due to stale addresses

Until the DNS record has been updated and cached copies have expired, connections may continue to use the old IP address.

In this scenario, several outcomes are possible:

1. The previous IP address may no longer respond, causing the connection to fail.
2. The IP address may have been assigned to another customer whose firewall rejects the connection.
3. The IP address may have been assigned to another customer who also has service listening on the same port, causing the connection to reach an unintended destination.

The window for the above occurring (while your IP address is being updated) is generally a few seconds up to a minute or two. Under normal conditions, this short period of potential downtime might be acceptable, but what happens if your Internet connection goes down and your IP address cannot be updated for minutes or even hours? In such cases, visitors will obviously be unable to access the intended service, but there is an increased possibility of them ending up at a completely different website or service entirely with scenario 3.

Security considerations

When using Dynamic DNS you cannot be certain whom you are communicating with based on IP address alone. Many servers and other systems on the Internet typically have statically assigned IP addresses, and these addresses are often used as a form of identification. Although this is not a strong method of authentication, it is still widely used.

We know that with a dynamically assigned IP address the IP can change at any time and may subsequently be assigned to another Internet user. This means that you cannot be certain whom you are communicating with by using the IP address alone as an identifier. Without additional methods of verifying the identity of the remote system, there is a possibility that you could provide security credentials or sensitive information to a system other than the one intended.

You also need to protect the credentials used by the DDNS client. If an attacker obtains these credentials (perhaps because your update process is insecure) someone other than you could replace your IP address with their own and redirect traffic to a server under their control and subsequently intercept or serve malicious content.

An HTTPS server should present a trusted TLS certificate that matches the hostname being accessed, and the browser should validate this certificate before establishing the connection. If the old IP address has been assigned to another system, certificate validation should fail and the browser will display a warning. The concern is that many people who self-host services use self-signed certificates, and they have become accustomed to ignoring certificate warnings. In doing so, they may overlook the very warning that indicates that they have reached an unintended or potentially malicious system.

Monitoring services

This brings us to simple monitoring, which is not so simple with DDNS. ICMP Ping is often used to determine if a host is online. You ping the host and it responds, simple enough. However, an ICMP ping response only indicates that a device at the resolved address responded. It cannot not confirm the identify of the device.

In the event that your Internet connection goes down (or during a periodic IP change) your monitoring system will reflect that host is down however, if you don’t get assigned a new IP address and the relevant DNS record isn’t updated, your previous IP address will probably get leased to a new client a few minutes later. Monitoring will reflect that the host is up again (because most consumer routers connected to the Internet respond to ping), except you’re actually pinging a different system altogether!

This means that your monitoring strategy needs to be more complex by using an authenticated health endpoint rather than testing only basic network reachability.

DDNS doesn’t work with CGNAT

Due to the exhaustion of IPv4 addresses, many ISP’s are now using Carier Grade NAT (CGNAT) where your router gets assigned a special ISP-level private address. The ISP then uses NAT so that multiple-customers can share a single public IP address. Dynamic DNS cannot overcome CGNAT because your router does not receive a unique routable IP address. The ISP’s shared NAT blocks unsolicited inbound connections, so even if you have port forwarding configured correctly on your router, inbound connections will fail.

Conclusion

Dynamic DNS combined with router port forwarding remains a viable way to provide remote access, but it’’s increasingly being seen as a legacy approach. The underlying problem of having an IP address that can change at any time impacts reliability, security and monitoring. There are certainly ways to work around some of the issues mentioned above, but is all the added effort and complexity worth it?

For business-critical public services, commercial hosting and cloud infrastructure are now sufficiently affordable to offer a more reliable, scalable, and manageable platform.

Where self-hosting is still required, outbound tunnels and identity-aware proxies provide a more secure and reliable alternative to conventional inbound access. These services do not require open inbound firewall ports and can operate behind CGNAT.

Cloudflare Tunnel is a managed service that uses a lightweight connector to create an encrypted, outbound-only connection between a private network and Cloudflare’s global network. It can publish internal applications without requiring a public IP address or open inbound firewall ports.

Pangolin is an open-source, identity-based remote-access platform that combines reverse-proxy and zero-trust VPN capabilities. Available as either a self-hosted or managed service, it uses WireGuard-based tunnels to provide controlled access to public and private resources, with policies based on users, roles, devices, and other contextual information.