What is dynamic DNS and is it safe to use?

Dynamic DNS lets a device update its own DNS record when its IP address changes, so a hostname keeps pointing at it. The mechanism is standard and safe when updates are authenticated and the service behind the name is hardened. The risks come from weak update keys and exposed home services.

How does a DNS record change on its own?

DNS normally holds fixed records edited by an administrator. The dynamic update protocol in RFC 2136 lets a client send an UPDATE message to the authoritative server to add or delete records in a zone. A router at a branch office, for instance, can tell the zone that branch1.example.net now lives at a fresh address after its provider reassigns it.

Many consumer services use a simpler route. The device calls an HTTPS endpoint with a username and token, and the provider edits the record. The idea is the same, only the transport differs.

Why do people use it?

Residential and small business connections often get addresses that change without notice. If you host a camera, a file share or a remote desktop at that address, you need a stable name. Dynamic DNS gives you one. It also helps labs, field equipment and temporary environments that come and go.

Short record lifetimes (TTL) matter here. A low TTL tells resolvers to re-ask quickly, so a change spreads within minutes instead of hours.

What are the security risks?

Three problems show up repeatedly.

First, unauthenticated or weakly authenticated updates. If anyone who knows the zone name can send an update, anyone can redirect your hostname. RFC 2136 itself leaves authentication to other mechanisms. RFC 8945 defines transaction signatures (TSIG), which sign each message with a shared secret so the server can verify the sender. RFC 3007 covers secure update more broadly.

Second, exposure. A stable name makes your home or office service easy to find and scan. An administration page reachable from the internet, left on default credentials, is the classic failure. The name did not cause that, but it advertises it.

Third, dangling and abandoned names. If you stop using a provider hostname but a CNAME or reference to it remains elsewhere, someone else may register that name and receive your traffic. Attackers also use dynamic DNS hostnames for command and control because they are cheap and quick to rotate, so some organizations monitor or restrict lookups to those domains.

Constructed example: a branch router

A small firm runs a VPN endpoint on a branch router with a changing address. Staff connect to vpn.branch.example.net. The router updates its record with a TSIG key kept on the device. When a technician replaces the router, nobody revokes the old key. A year later the old device is sold on a marketplace, still holding a valid signing key for the zone.

The fix is boring and effective: one key per device, scoped to a single record name, rotated on a schedule and revoked at decommissioning.

How to check or apply this

1. List every hostname that is updated dynamically and who or what holds its credentials.
2. Require signed updates (TSIG) or a per-device API token. Avoid a shared password across devices.
3. Limit each key to its own record so a stolen key cannot rewrite the whole zone.
4. Keep TTLs low only for records that truly change. Longer TTLs reduce lookup load.
5. Put the service behind a VPN or an authenticated gateway instead of publishing it openly.
6. Remove DNS records and keys when you retire a device or a service.
7. Review outbound DNS logs for lookups to dynamic DNS provider domains you do not recognize.

Quick check

Sources

• RFC 2136, Dynamic Updates in the Domain Name System
• RFC 8945, Secret Key Transaction Authentication for DNS (TSIG)
• RFC 3007, Secure Domain Name System Dynamic Update

Last reviewed: 18 October 2026.