If you want to reach a gateway at a remote site by name, that name has to point at the gateway's current address, but many field connections hand out a public address that changes every time the link reconnects. Dynamic DNS is the workaround: the gateway tells a DNS service its new address each time it changes, so a fixed hostname always resolves to wherever the gateway currently lives. This guide explains what dynamic DNS does, how the update mechanism keeps a hostname current, and why operators often reach for a fixed-IP SIM instead of relying on DDNS at all.
Dynamic DNS in one line: Dynamic DNS, or DDNS, keeps a stable hostname mapped to a device whose public IP address changes over time. The device runs a small client that notifies a DNS provider whenever its address changes, and the provider updates the hostname's record so it always resolves to the current address. It is a way to make a gateway on a dynamic IP reachable by name, though a fixed-IP SIM often removes the need for it entirely.
Names are stable and easy to work with; addresses are not. When you want to connect to a remote gateway - to reach a web interface, open a maintenance session, or point a client at it - it is far more convenient to use a hostname than to track a raw IP address. The trouble is that the connection at many remote sites, whether a home-style broadband line or a mobile data link, is handed a public IP dynamically, and that address can change whenever the link drops and reconnects, when the lease expires, or when the carrier reassigns it. A hostname that was correct this morning may point nowhere by this afternoon.
Dynamic DNS closes that gap by decoupling the name from the address in a way that can keep up with change. Instead of a static record that an administrator edits by hand, the hostname is served by a DNS provider that accepts programmatic updates. A small client running on the gateway or router watches its own public address and, whenever it changes, sends the new value to the provider, which updates the record. The name stays put; only what it points to is quietly refreshed underneath it.
There is always a short lag involved. DNS records carry a time-to-live that tells other systems how long they may cache the answer, and after an address change there is a window where a cached lookup still returns the old value until the record expires and is fetched fresh. DDNS records therefore use short time-to-live values to shrink that window, at the cost of more frequent lookups. This is why DDNS is well suited to occasional access to a site but is a weaker foundation for anything that needs an unbroken, always-correct path.
The heart of dynamic DNS is the update client and the provider that trusts it. The client, which may be built into the router or gateway or run as a separate agent, is configured with a hostname and a credential for the DDNS service. It periodically checks what its current public address actually is, because behind carrier network translation a device often cannot see its own external address directly, and compares that to what it last reported. When the two differ, it sends an authenticated update to the provider asking it to change the record for that hostname.
The provider validates the request and rewrites the DNS record so the next lookup of the hostname returns the new address. From that point, anyone resolving the name is steered to the gateway's current location, subject to the caching lag described by the record's time-to-live. Good clients also handle the awkward cases: they avoid hammering the provider with needless updates when nothing has changed, they retry sensibly if an update fails, and they detect the true external address rather than an internal one that would be useless to an outside caller.
The reliability of the whole scheme rests on that update path staying healthy. If the gateway's link is flapping, its address may change faster than updates can propagate and caches can expire, leaving the hostname chasing a moving target. If the update client stalls or loses its credential, the record silently goes stale and the name keeps pointing at an address the gateway no longer holds. Because the mechanism is only as current as its last successful update, DDNS is a best-effort convenience rather than a guarantee that a site is reachable at any given instant.
For a fleet of remote industrial sites, dynamic DNS is one answer to the reachability problem, but it is often not the preferred one. A cleaner alternative for cellular sites is a fixed-IP SIM, where the mobile data plan assigns the gateway an address that does not change, so a plain static DNS entry - or even a bare address - stays correct indefinitely with no update client to maintain. That removes the moving parts entirely: there is no client to stall, no record to go stale, and no caching lag after a reconnect, which matters when access needs to be dependable rather than occasionally convenient.
There is also a more fundamental point about how modern field sites are reached at all. Many operators avoid inbound connectivity to remote sites entirely, because an inbound-reachable gateway is an exposed one, and instead have each site dial outward to a central service. When a site only ever connects out, the problem DDNS solves - making an inbound-reachable device findable by name - largely evaporates, because nobody is trying to connect in. In that model DDNS is neither needed nor desirable; the address the site happens to hold does not matter, because the meeting point is a fixed cloud endpoint the site reaches on its own.
This is the pattern that fits cloud SCADA well. With a platform such as Merobix, each remote gateway establishes an outbound connection to the hosted service to send its readings and alarms, so the platform does not need to know or track the site's ever-changing public address, and DDNS plays no part in the monitoring path. Where an operator does need occasional inbound-style maintenance access to a site, a fixed-IP SIM or an outbound reverse-tunnel approach usually gives a more stable and more secure result than depending on a DDNS record staying current. DDNS remains a legitimate tool for reaching a device by name on a changing address, but for a serious field deployment it is often the fallback rather than the design of choice.
Many connections, including consumer broadband and standard cellular data plans, hand out public addresses dynamically rather than permanently, so the address can change when the link drops and reconnects, when its lease expires, or when the carrier reassigns addresses in its pool. Unless you specifically pay for a static or fixed address, you should assume the public IP can change at any reconnect. Dynamic DNS exists precisely to cope with that behaviour.
A fixed-IP SIM is usually the more dependable choice, because the address never changes, so there is no update client to maintain and no caching lag after a reconnect to leave a hostname briefly stale. Dynamic DNS is a best-effort convenience that is only as current as its last successful update. For sites that only ever dial outward to a cloud service, neither is strictly needed for monitoring, because the site's address does not have to be found.
Dynamic DNS can keep a hostname pointed at a device's public address, but if the carrier places the site behind network address translation, that public address is shared and inbound connections still cannot reach the specific device, so DDNS alone will not make it accessible. In that situation an outbound-connection approach or a fixed public address is required. This is a common reason DDNS proves insufficient on cellular field links.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.