Dynamic DNS (DDNS)

Automatic DNS updates for changing IP addresses — from RFC 2136 protocol mechanics to consumer DDNS services and enterprise deployments.

DNS was designed for a world where IP addresses were stable. A server got an address, an admin added an A record, and that record stayed correct for months or years. But the modern internet is far more dynamic — laptops move between networks, ISPs rotate residential IPs, cloud instances spin up and down, and IoT devices appear and disappear.

Dynamic DNS (DDNS) bridges this gap by allowing DNS records to be updated automatically when IP addresses change. It’s a simple concept with implementations ranging from free consumer services to enterprise-grade RFC-compliant update protocols.

The Problem: Changing IP Addresses

Most residential and many business internet connections use dynamic IP addressing. Your ISP assigns an IP from a pool via DHCP, and that A record address can change when your lease expires, your router reboots, or the ISP decides to shuffle their pool.

This creates problems when you want to reach a device by name:

  • Running a home server? Visitors can’t bookmark your IP because it changes
  • Managing a remote office? VPN configurations break when the endpoint IP changes
  • IoT devices reporting home? They can’t register a fixed hostname

Static IPs are available from most ISPs — for a premium. DDNS eliminates the need for that premium by keeping DNS records synchronized with your current IP.

RFC 2136: DNS UPDATE

The IETF’s formal solution to dynamic DNS is RFC 2136 — Dynamic Updates in the Domain Name System (DNS UPDATE). Published in 1997, it defines a protocol for modifying DNS zone data on an authoritative server programmatically.

How DNS UPDATE Works

DNS UPDATE uses the standard DNS message format (from RFC 1035) with a different opcode. An UPDATE message contains four sections:

  1. Zone section: Identifies which zone is being updated
  2. Prerequisite section: Conditions that must be true for the update to proceed (optional but powerful)
  3. Update section: The actual changes — add, delete, or modify resource records
  4. Additional section: TSIG signatures or other authentication data

Here’s a conceptual example of adding an A record:

; DNS UPDATE message
Zone:          example.com
Prerequisite:  (none)
Update:        ADD   home.example.com.  300  IN  A  198.51.100.42

And a more sophisticated update with prerequisites:

; Only update if the current A record matches the old IP
Zone:          example.com
Prerequisite:  RRSET EXISTS (home.example.com. A 198.51.100.41)
Update:        DELETE home.example.com.  A  198.51.100.41
               ADD    home.example.com.  300  IN  A  198.51.100.42

Prerequisites enable atomic compare-and-swap operations — essential for avoiding race conditions when multiple devices might update the same record.

Authentication with TSIG

Unauthenticated DNS updates would be a security nightmare — anyone could modify your zone. TSIG (Transaction Signatures), defined in RFC 2845, provides authentication using shared secret keys:

; nsupdate command with TSIG
$ nsupdate -k /etc/bind/keys/home.key
> server ns1.example.com
> zone example.com
> update delete home.example.com A
> update add home.example.com 300 A 198.51.100.42
> send

The TSIG key is a shared HMAC secret between the client and the DNS server. The server only accepts updates signed with authorized keys, and can restrict which keys are allowed to update which records.

GSS-TSIG (RFC 3645) extends this to Kerberos authentication, which is what Microsoft Active Directory uses for its DNS update mechanism.

nsupdate: The Standard Client

nsupdate is the standard command-line tool for sending DNS UPDATE messages, included with BIND. It’s the reference implementation that most DDNS scripts and tools use under the hood:

#!/bin/bash
NEW_IP=$(curl -s https://api.ipify.org)

nsupdate -k /etc/bind/keys/home.key << EOF
server ns1.example.com
zone example.com
update delete home.example.com A
update add home.example.com 300 A ${NEW_IP}
send
EOF

This script checks the current public IP, then sends a DNS UPDATE to replace the old A record. Run it via cron every 5 minutes, and you have a basic DDNS system.

Consumer DDNS Services

Most people don’t run their own authoritative DNS servers. Consumer DDNS services provide a simpler solution: they manage the DNS infrastructure and provide an API or client for updating your IP.

How Consumer DDNS Works

  1. You create an account and register a hostname (e.g., myhome.ddns.net)
  2. You install a client or configure your router to detect IP changes
  3. When your IP changes, the client calls the provider’s HTTP API
  4. The provider updates the A record for your hostname

The update protocol is typically a simple HTTP request:

GET /nic/update?hostname=myhome.ddns.net&myip=198.51.100.42
Host: api.ddnsprovider.com
Authorization: Basic base64(username:password)

Many consumer routers have built-in DDNS clients supporting popular providers.

  • No-IP — Free tier with hostnames on *.ddns.net and similar domains. Requires periodic confirmation to keep free hostnames active
  • DynDNS (now Oracle Dyn) — One of the original DDNS providers, now primarily enterprise-focused
  • Duck DNS — Free, open-source-friendly, supports custom domains via CNAME
  • Cloudflare — If your domain uses Cloudflare DNS, their API supports programmatic record updates, effectively providing DDNS for your own domain
  • afraid.org (FreeDNS) — Free DDNS with a large selection of shared domains

Custom Domain DDNS

Using a free hostname like myhome.ddns.net works, but you can also point your own domain to a DDNS address:

; In your example.com zone
home.example.com.    IN CNAME    myhome.ddns.net.

Or, if your DNS provider has an API (Cloudflare, Route 53, DigitalOcean), you can update A records on your own domain directly using scripts or tools like ddclient, inadyn, or custom webhook integrations.

Enterprise Dynamic DNS

In enterprise environments, DDNS takes a different form. It’s deeply integrated with network infrastructure:

Microsoft Active Directory DNS

Active Directory is perhaps the largest deployment of dynamic DNS in the world. When a Windows machine joins a domain or renews its DHCP lease, it automatically registers its hostname in DNS using GSS-TSIG authenticated updates.

1. PC gets IP 10.0.5.100 from DHCP
2. PC sends DNS UPDATE: workstation.corp.example.com → 10.0.5.100
3. AD DNS server validates Kerberos credentials
4. Record is created/updated

This is why Active Directory requires dynamic DNS — without it, domain-joined machines can’t register themselves, and service location (via SRV records) breaks.

DHCP-DNS Integration

In enterprise networks, the DHCP server often handles DNS updates on behalf of clients:

  1. DHCP server assigns IP to client
  2. DHCP server sends DNS UPDATE to the authoritative server
  3. Forward record (A/AAAA) and reverse record (PTR) are both created

ISC DHCP and Kea DHCP both support this pattern, typically authenticated with TSIG keys. This is more reliable than client-initiated updates because the DHCP server always knows the current assignment.

DDNS for IoT and Home Networks

The explosion of IoT devices has created new DDNS use cases:

Home Servers and NAS

Network-attached storage (NAS) devices from Synology, QNAP, and others include built-in DDNS clients. Synology even provides its own DDNS service (yourname.synology.me) for free.

Remote Access

Home automation platforms (Home Assistant, OpenHAB) use DDNS to enable remote access. Instead of remembering (or constantly looking up) your home IP, you access myhome.duckdns.org.

Security Cameras

Many IP camera systems support DDNS, allowing remote viewing without a static IP. The camera or DVR updates a DDNS hostname whenever the IP changes.

The Port Forwarding Caveat

DDNS solves the IP address problem, but not the port problem. Most residential connections are behind NAT, so you also need port forwarding configured on your router. And with the rise of CGNAT (Carrier-Grade NAT), some ISPs place multiple customers behind a single public IP, making traditional port forwarding impossible.

Solutions for CGNAT include:

  • IPv6 — if available, each device gets a globally routable address
  • Reverse tunnels — services like Cloudflare Tunnel or ngrok bypass NAT entirely
  • VPN — connecting back to a VPS with a static IP
  • UPnP/NAT-PMP — automatic port forwarding (security concerns apply)

Key Takeaways

  • RFC 2136 DNS UPDATE is the IETF standard for dynamic DNS, supporting prerequisites and TSIG authentication
  • Consumer DDNS services (No-IP, Duck DNS, DynDNS) provide free/cheap DDNS for home users via simple HTTP APIs
  • Enterprise DDNS is deeply integrated with Active Directory and DHCP, using GSS-TSIG for Kerberos authentication
  • IoT and home networks rely on DDNS for remote access to NAS, cameras, and home automation
  • CGNAT is making traditional DDNS less effective — reverse tunnels and IPv6 are the modern solutions
  • nsupdate is the standard command-line tool for RFC 2136 DNS UPDATE operations