Understanding Dynamic DNS: A Beginner's Guide

Dynamic DNS, or DDNS, keeps a useful hostname associated with a changing IP address. It can help you locate a home VPN or another deliberately configured service without remembering the current public address. It provides the naming part of remote access; reaching and protecting the service are separate jobs.

What Is Dynamic DNS?

DNS associates names with records, including IPv4 addresses in A records and IPv6 addresses in AAAA records. A home connection may receive a new address after an ISP change or reconnect. A DDNS updater detects the address it should publish and sends an authenticated change to the DNS provider.

A resolver looks up that record and returns an address to the client. With ordinary DNS-only operation, the client's application connects to that address; its traffic is not routed through the DDNS provider as a redirect. A provider may separately offer web redirects or a proxy, but those are different features.

How the Update Cycle Works

1. A supported router or software updater detects the relevant public address.
2. It authenticates to the selected provider and updates the record when needed.
3. The provider serves the current record to DNS queries.
4. The remote client resolves the hostname and attempts to connect to the intended service.

Updates are not universally instantaneous. The updater has a checking interval, and resolvers cache answers according to the record's time to live. A change at the provider does not force every client to discard its cached answer immediately. An already established connection may also fail when the underlying address changes.

Check Reachability Before Choosing a Provider

DDNS can publish an address even when direct incoming connections are unavailable. Carrier-grade NAT is one common reason. RFC 6598 reserves 100.64.0.0/10, spanning 100.64.0.0 through 100.127.255.255, as shared address space for provider networks. It is not the same allocation as ordinary RFC 1918 private addressing.

Compare the router's WAN IPv4 address with an external IPv4 address check made through the same connection. A mismatch is a useful clue, but it can also reflect an upstream household router, VPN or another path. Matching addresses do not guarantee incoming ports will work: ISP filtering, firewall rules, listening services and port mappings still matter. Ask the ISP when the WAN arrangement is unclear.

A reachable public address may allow a deliberately configured VPN server. If the provider uses CGNAT, options include requesting suitable public addressing or using an outbound connection service. Cloudflare Tunnel, for example, connects outward rather than requiring a public origin address. Private overlay services have their own access model; neither type is simply another DDNS provider.

IPv6 can offer a different route, but both ends need suitable connectivity and the service's actual global address must be published. Keep the IPv6 firewall restrictive and permit only the intended service. A changing prefix, stale AAAA record or address belonging to the updater rather than the server can still break access.

Choosing a Naming and Update Service

No-IP's current free-tier information describes one hostname and confirmation every thirty days. A software update is not a substitute for that confirmation. Other services and plans have different conditions, so compare the live terms instead of relying on a universal free-provider ranking or a fixed annual domain price.

A Practical Setup Sequence

Choose the remote-access method first, then the hostname provider. Confirm that your router supports that provider or select a maintained updater. Configure the hostname and authentication using the provider's instructions. Keep one intended owner for each record; competing updaters can overwrite each other's addresses.

Check the provider's dashboard, updater logs and an independent DNS lookup. Then test the intended service from a different network. Testing only from home can be misleading because local DNS or NAT loopback may use another path. Verify account recovery, hostname renewal and what happens after the updater or router restarts.

Optional Cloudflare Updater Example

For a Linux host with Docker Engine and Compose already installed, favonia's versioned updater documentation provides a maintained container option. This example manages one IPv4 DNS-only hostname in a Cloudflare zone you control. It does not set up a VPN, port forwarding or a public application.

Create a Cloudflare API token with Zone DNS Edit permission limited to the intended zone. Use a fresh project directory for the following Bash commands, which prompt for the token without displaying it and record your actual user IDs. The DNS hostname must be a full name you are authorised to update; do not reuse a production record until you understand the updater's ownership behavior.

mkdir -p cloudflare-ddns/secrets
cd cloudflare-ddns
umask 077
read -r -s -p "Cloudflare DNS API token: " dns_token
printf '\n'
printf '%s' "$dns_token" > secrets/cloudflare_api_token.txt
unset dns_token
read -r -p "Full DNS hostname you control: " dns_hostname
printf 'DDNS_DOMAIN=%s\nDDNS_UID=%s\nDDNS_GID=%s\n' "$dns_hostname" "$(id -u)" "$(id -g)" > .env
unset dns_hostname

Save this as compose.yaml in that directory. The versioned image was checked in the publisher's registry. The container's user must be able to read the token file; on this Linux example, its UID/GID match the user that created the private file. No ports are published and host networking is unnecessary for this IPv4-only example.

services:
  cloudflare-ddns:
    image: ghcr.io/favonia/cloudflare-ddns:1.17.1
    restart: unless-stopped
    user: "${DDNS_UID:?Set DDNS_UID}:${DDNS_GID:?Set DDNS_GID}"
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    environment:
      CLOUDFLARE_API_TOKEN_FILE: /run/secrets/cloudflare_api_token
      IP4_DOMAINS: "${DDNS_DOMAIN:?Set DDNS_DOMAIN}"
      IP6_PROVIDER: none
      PROXIED: "false"
      UPDATE_CRON: "@every 5m"
    secrets:
      - cloudflare_api_token
secrets:
  cloudflare_api_token:
    file: ./secrets/cloudflare_api_token.txt

The configuration explicitly checks every five minutes, uses the current file-backed token variable and selects A records only. It does not maintain existing AAAA records; review stale IPv6 records separately. The updater's PROXIED=false affects new records, not the proxy status of existing ones. Set an existing non-HTTP service record to DNS-only in Cloudflare itself.

docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 cloudflare-ddns

Confirm the effective domain and detected address in the logs, then verify the provider's record. Protect the token and configuration backups, revoke a leaked token, and review release notes before changing the pinned version. Running a container as a non-root user is not the same claim as running the entire Docker daemon rootless.

Common Pitfalls and Security Checks

DNS-only records expose the published address. Cloudflare's ordinary HTTP proxy is not a general-purpose relay for arbitrary VPN protocols or ports. Choose proxy status for the service, and keep certificates, authentication and firewall rules appropriate to the actual access path.

Prefer protected remote access to publishing a camera, NAS login or router administration directly. A memorable name does not secure those services. Check MFA where available, strong account passwords, updater health and software maintenance. If remote access fails, diagnose naming, address reachability, firewall policy and application authentication separately instead of repeatedly changing the hostname.

Conclusion

DDNS makes changing addresses easier to manage. Its value comes from a maintained updater, accurate records and a deliberate remote-access design. Confirm the name resolves, test the service from outside the home and keep the account and update mechanism healthy.