You run a server at home. You want to reach it from anywhere. But your home internet connection has a dynamic IP address that changes — sometimes weekly, sometimes when the modem reboots. Without a fixed IP, how do you keep a usable URL pointing at your home network?

Dynamic DNS (DDNS) solves this. A small client on your network watches your public IP; when it changes, it updates a DNS record automatically. The result: a hostname like myhome.ddns.net that always resolves to your current IP, even as that IP shifts underneath.

Why Dynamic IPs Exist

Residential ISPs typically assign IPs via DHCP with leases of a few hours to a few days. The IP you have today might be different tomorrow:

Modem reboot — Often triggers a new IP.
Lease expiration — Renewal might give you the same IP or a different one.
ISP reconfiguration — Maintenance, network rebalancing.
Multi-home / failover — Connection drops to backup link with different IP.

For most consumers this is fine; they’re clients, not servers. But for the use cases that need to expose home infrastructure to the internet, dynamic IPs are a problem.

How DDNS Works

The mechanism:

Your network has a public IP (assigned by your ISP, dynamic).
A DDNS client runs somewhere — on your router, NAS, or any always-on device.
The client periodically checks your current public IP (often by querying a “what’s my IP” service).
If the IP has changed, the client calls the DDNS provider’s API to update your hostname’s DNS record.
The provider updates the DNS record so myhome.ddns.net now points to the new IP.
DNS caches converge (usually within minutes for low-TTL records).
Others can reach you via the hostname.

The TTL on DDNS records is typically very short (60 seconds or less) so changes propagate fast. See DNS caching for the propagation mechanics.

Use Cases

Home servers

The classic: a Plex/Jellyfin/Synology NAS at home that you access from your phone away from home. DDNS gives you a usable URL.

Game servers

Hosting a Minecraft / game server at home for friends. They connect via your DDNS hostname instead of memorizing an IP.

Remote desktop / SSH

Reaching home workstations or development machines.

IoT and home automation

Cameras, smart-home hubs, or home-assistant exposing services on the public internet (with appropriate security).

Small business

Branch offices with dynamic IPs needing inbound connectivity for site-to-site VPN endpoints.

Personal cloud

Self-hosted Nextcloud, photo backup, file servers.

For VPN access home, DDNS is often the endpoint hostname your VPN client connects to.

DDNS Providers

Popular providers in 2026:

Free tier

DuckDNS (duckdns.org) — Free, simple, no-frills.
No-IP — Free with periodic confirmation requirement.
FreeDNS (afraid.org) — Free, lots of subdomains available.
Dynu — Free tier available.

Paid

Dynu, No-IP Plus, DynDNS (now Oracle) — Paid tiers offer custom domains, longer commitments, better reliability.

Cloudflare DNS API

Not a traditional DDNS provider, but a popular DIY route: use Cloudflare for free DNS, write a small script that updates A records via API. Works with your own domain.

Router-built-in

Many home routers (Asus, Ubiquiti, Mikrotik, OpenWrt) have built-in DDNS clients for major providers. Configure the credentials, the router handles updates.

Using Your Own Domain

For more control, point your own domain (example.com) at a DDNS service:

CNAME home.example.com to myhost.ddns.net. The CNAME doesn’t change; the underlying A record at ddns.net changes. Resolvers follow the chain to get the current IP.

Or, for more independence, use your DNS provider’s API directly:

#!/bin/bash
# Update Cloudflare A record with current public IP
ZONE_ID="..."
RECORD_ID="..."
API_TOKEN="..."

CURRENT_IP=$(curl -s https://api.ipify.org)

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
    -H "Authorization: Bearer $API_TOKEN" \
    -H "Content-Type: application/json" \
    --data "{\"content\":\"$CURRENT_IP\"}"

Cron this to run every 5 minutes. The DNS record is always current.

DDNS Behind CGNAT

A big gotcha in 2026: many ISPs use CGNAT. Your “public” IP is actually shared with hundreds of other customers. DDNS still updates the IP correctly, but you can’t accept inbound connections — the CGNAT only allows outbound.

Symptoms: DDNS works (myhost.ddns.net resolves), but nc -zv myhost.ddns.net 22 from outside times out.

Workarounds:

Request a public IP from your ISP (sometimes available for an extra fee).
Use a reverse-tunnel service (Cloudflare Tunnel, ngrok, tailscale) — these establish outbound connections from your network to a public endpoint, then proxy inbound back.
Mesh VPN (Tailscale, Nebula, ZeroTier) — peer-to-peer connections that work through CGNAT.

For modern home server use, Cloudflare Tunnel + DDNS-equivalent is often the most practical setup. The tunnel handles inbound traffic via outbound connections; you get a stable URL without traditional DDNS.

IPv6 and DDNS

A few notes for IPv6:

IPv6 prefixes can also change (less commonly than IPv4, but it happens).
DDNS for IPv6 updates AAAA records instead of A records.
Many DDNS providers support IPv6 in 2026.

For dual-stack home setups, your DDNS client updates both A and AAAA records to keep them in sync.

Security Considerations

Running a service exposed via DDNS:

Authentication

Anything you expose must be properly authenticated. SSH key-only, strong passwords for web apps, HTTPS with valid certs.

Firewalling

Only open the ports you need. Default-deny outside of explicit allows.

Rate limiting

Public-facing services should rate-limit logins to prevent brute force.

Regular updates

Internet-exposed services need patching faster than internal ones. Set up auto-updates where possible.

Reverse-tunnel alternative

For better security, use Cloudflare Tunnel or similar instead of opening ports directly. The traffic still arrives at your home, but the attack surface is shifted to Cloudflare’s infrastructure.

DDNS Reliability

A few considerations:

IP detection

The client must reliably detect your current public IP. “What’s my IP” services occasionally fail; cache or retry.

Update frequency

Too frequent = wasted API calls. Too infrequent = stale records during outages. 5-minute intervals are typical.

Failure handling

If the DDNS update fails (provider down, credential expired), the client should retry with backoff and alert.

Multiple connections

If you have multiple internet connections (e.g., fiber + 5G), which IP do you publish? Usually the primary, but some setups DDNS both for failover.

TLS Certificates for DDNS Hosts

You probably want HTTPS for any web-facing service. With a DDNS hostname:

Let’s Encrypt issues certificates for DDNS hostnames just like any other.
DNS-01 challenge works well for DDNS because you can prove control of the DNS record via API.
HTTP-01 challenge requires port 80 reachable, which behind CGNAT may not work.

Most DDNS hosts in 2026 should use Let’s Encrypt with DNS-01 challenge via their DDNS provider’s API.

TL;DR

DDNS gives you a stable hostname for a dynamic IP.
A small client updates DNS records whenever your public IP changes.
Free providers exist; you can also DIY with your own domain + DNS API.
CGNAT breaks traditional inbound DDNS — use reverse-tunnel alternatives.
For modern home setups, Cloudflare Tunnel often replaces traditional DDNS.
IPv6 versions update AAAA records.
Security matters — anything exposed needs auth, firewalling, patching.
TLS via Let’s Encrypt with DNS-01 challenge.

DDNS has been around forever; the use cases keep evolving with the network architecture. For modern home server setups, you’re often choosing between “traditional DDNS + port forwarding” and “reverse-tunnel + cloud-managed DNS.” Both have valid use cases. For DNS basics, see how DNS lookup works; for the caching that determines propagation speed, DNS caching explained.

Dynamic DNS (DDNS) Explained: A Stable Name for a Changing IP