MyIP.dogChecking…
DNS and routing
Dynamic DNS: keep a hostname pointed at a changing address
Set up dynamic DNS with the correct address source, separate A and AAAA records, verify updates, and understand caching and CGNAT limits.
Published:
Sources checked
DNS and routing
Set up dynamic DNS with the correct address source, separate A and AAAA records, verify updates, and understand caching and CGNAT limits.
Published:
Sources checked
Checking…
Dynamic DNS keeps a hostname associated with an address that can change. An updater observes the intended destination address and asks the authoritative DNS provider to update the relevant record. You keep using a name, while the record follows supported address changes. This is useful for a service whose network assignment is dynamic but whose users need a stable name.
Dynamic DNS changes naming information. It does not make an unreachable service reachable, create an upstream port mapping, or keep a sleeping computer online. Before setting it up, identify the application, its destination address and the network path clients need. Use static vs dynamic IP if the assignment terminology is unfamiliar.
The process has four separate stages: detect the intended address, authenticate an update, publish the record, and let clients resolve the name. A success message at one stage does not prove the others completed. For example, a client can authenticate successfully while updating the wrong hostname, and a correct authoritative record can coexist with an older cached answer.
There is more than one dynamic DNS update mechanism. RFC 2136 specifies DNS UPDATE, while providers can offer their own authenticated APIs. Cloudflare documents an API-based update approach and mentions ddclient. A router's built-in client must support the chosen provider and method; entering an arbitrary provider name does not create compatibility.
This sequence makes dynamic DNS easier to diagnose later. Keep the hostname and updater location in your operational notes. If you replace a router or reinstall the client, those details help identify which component used to maintain the record instead of guessing from an old account name.
For an ordinary directly reachable IPv4 home service, the destination is usually the relevant public IPv4 allocation, with any required local forwarding configured separately. A router's LAN address is not that public destination. Under CGNAT, even the observed public exit may be shared and unable to accept the incoming connection you need. Port forwarding behind CGNAT
A VPN can make an external “what is my IP” request report the tunnel exit. Publishing that address through dynamic DNS may be wrong if the service is not reachable through that exit. Check the updater's traffic path, especially when the updater and the server run on different machines. Address detection should measure the intended destination arrangement rather than whichever interface happens to answer first.
For a local-only service, an internal naming system may be more appropriate than a public record. Publicly publishing a private address does not make it remotely routable. Decide who needs to resolve the name and from which network before selecting dynamic DNS. The public and private address guide explains the difference in scope.
An A record describes an IPv4 address; an AAAA record describes an IPv6 address. Treat their update paths independently. An updater supporting one family does not necessarily maintain both. If an old AAAA record remains while A is correct, clients selecting IPv6 can fail even though an IPv4-only check appears healthy.
An IPv6 server can have several addresses, including temporary source values. Select an address and assignment strategy suitable for serving that application, and account for provider prefix changes. Dynamic DNS should not blindly copy a transient source address from an unrelated device. The IPv6 format guide helps distinguish the address, prefix and local interface context.
Begin with the provider's published configuration and the updater's last result. Confirm the exact owner name and record type. Then use DNS lookup to query that name through its named public resolver. Preserve the returned data, TTL, response code and timestamp. This query checks one resolver's view; it does not inspect every cache worldwide.
Compare the answer with the destination expected for that family. A matching record supports the naming step of dynamic DNS. Next, test the dynamic DNS hostname with the actual application from an appropriate network. A successful lookup followed by a failed connection moves the investigation toward routing, transport, firewall or application behavior, rather than automatically calling for another DNS edit.
After a normal address change, repeat the same comparison. Record when the updater noticed the change, when the provider accepted it, and when the selected resolver returned it. This makes dynamic DNS delays measurable. Do not repeatedly restart a working connection just to force a test if the provider may return the same address or interrupt other users.
TTL controls normal caching behavior for a record. Reducing the value after an older answer has been cached does not shorten every existing cache timer retroactively. Negative answers can also be cached. A newly created hostname may therefore require a different investigation from an existing name that still returns its former address. Negative caching
Dynamic DNS does not provide a universal “instant propagation” guarantee. Update intervals, API failures, authoritative publication, caches and application behavior all contribute to the observed delay. Choose a supported polling interval and retry policy. Aggressively submitting unchanged records can add provider load without changing what a client with an existing answer sees.
The updater never runs. Check whether its host is powered on and whether the scheduled service is enabled. Review the client's actual status and last attempt. Dynamic DNS cannot maintain a record when the only updater is a laptop that has been asleep since the address changed.
The provider rejects the update. Preserve the status and message, then check credential permissions, record identifiers, supported authentication and account requirements. Consult the provider's current API documentation. Do not paste a token into a public forum while asking why dynamic DNS authentication failed; a redacted error and permission description are usually more useful.
The record changes back. Look for another router client, background task or old server still updating it. Compare timestamps and reported values. Conflicting dynamic DNS writers can produce a pattern that resembles unstable address assignment even when each writer is consistently publishing its own different observation.
The name resolves correctly but the service fails. Confirm the application is listening on the intended interface and protocol, then check the local firewall and supported inbound path. For IPv4, a home forwarding rule cannot configure a provider's upstream translator. Dynamic DNS solves the naming problem, not the missing path through CGNAT.
The answer shows a proxy address. A provider's proxy feature can intentionally publish its delivery network instead of the origin value. Inspect the record's proxy mode and the service's supported protocols. Dynamic DNS may update the configured origin while public queries continue returning proxy addresses. Cloudflare proxy behavior
Use the provider's smallest practical permission scope and follow its credential-rotation procedure. Cloudflare's token documentation illustrates permissions and resource selection. Keep secrets out of browser code, screenshots and public repositories. Dynamic DNS credentials can affect where users are directed, so treat them as configuration access rather than harmless diagnostic text.
When retiring a service, disable its updater and remove or deliberately repurpose the old record. Otherwise, dynamic DNS can leave a stale hostname pointing to an address that is later reassigned. Maintain the application's authentication and encryption independently of the name. Knowing a convenient hostname should not be enough to administer the service.
Does it provide a static IP? No. Dynamic DNS maintains a name-to-address relationship while the address can still change. Applications that require a contractually fixed source or destination need an arrangement that actually supplies that property.
Will it fix CGNAT? No. A correct name can point at a shared exit without giving you an inbound mapping. Confirm the service architecture with the provider and choose a supported access method before treating dynamic DNS as the missing piece.
Can MyIP.dog update my records? The tools here observe addresses and query records; they do not store your DNS provider credential or operate your updater. Use the checks to verify a dynamic DNS setup maintained by your own supported client, then keep the source and time with each result.