Dynamic DNS (DDNS)

Dynamic DNS (DDNS) is a service that automatically updates a domain name's DNS record whenever the underlying IP address changes. Most residential internet connections are handed a public IP that the provider can rotate without notice, which would otherwise break any domain pointed at a home server. DDNS keeps a stable, memorable name reliably pointing at a moving target, making it a staple for sovereign Bitcoiners hosting services from home.

How it works

A small client runs on your router or a device inside the network. It periodically checks the connection's current public IP and, when it detects a change, contacts the DDNS provider's API to update the matching A or AAAA record. Because the change happens at the authoritative level, resolvers around the world pick up the new address as their cached copies expire, governed by the record's time-to-live (TTL) value, which DDNS setups usually keep low — often 60 to 300 seconds — so an IP rotation causes at most a few minutes of stale answers. Many consumer routers ship with DDNS clients built in, and most domain registrars and DNS hosts expose an update API, so the moving parts amount to one background process and one HTTPS call.

Why it matters for self-hosting

Without DDNS, a home node reachable at node.example.com would become unreachable the moment the ISP reassigns the address, and you would have to edit DNS by hand each time. With DDNS, the name simply follows the address. This lets you point a personal domain at a Bitcoin or Lightning node, a wallet backend, a local-AI endpoint, or a monitoring dashboard for your miners and trust that it stays reachable from anywhere. It is the difference between self-hosting as a hobby that breaks on ISP whim and self-hosting as dependable infrastructure — and it costs nothing but a cron-like client and a low TTL.

Limitations

DDNS solves the changing-address problem but does nothing about address translation or carrier-grade NAT; a correct DNS record is useless if inbound packets are still dropped before they reach you. Pairing it with port forwarding handles the ordinary home-router case, but if your ISP puts you behind CGNAT — no public IPv4 of your own — no DNS record can help, and you need a different reachability strategy: a Tor onion service, a tunnel to a small VPS acting as a reverse proxy, or a VPN with a static endpoint. DDNS also requires trusting the provider with update access to your record, and a public hostname that follows your home IP is a standing correlation between your domain and your physical connection — worth a moment's thought in your threat model before you bind your name to your house.

Practical guidance

Run the update client on an always-on device rather than a laptop, keep the TTL low, and expose only what must be exposed — a firewall should drop everything except the ports you deliberately opened. For services only you use, consider whether a private overlay network or Tor beats a public hostname entirely: the most sovereign DNS record is sometimes the one you never publish. DDNS builds directly on the naming concepts in DNS; understanding both together turns "my node went dark again" into a solved problem.

Provider choice deserves a moment's care. Registrar-integrated DNS APIs, dedicated DDNS services, and self-hosted update scripts against your DNS host's API all work; whichever you choose, scope the API credential to updating that one record rather than managing the whole zone, so a leaked token on your router cannot redirect your entire domain. Monitor the updater itself — the silent failure mode is a client that stopped running months ago, discovered only when your IP finally rotates. IPv6 softens the problem without solving it: prefixes still change with many ISPs, so AAAA records need the same automation.