What methods does dynv6 offer to update DNS records?

Updated

dynv6 supports five update paths: a REST API, an Update API, a DynDNS API, SSH with public key authentication, and DNS updates secured with TSIG keys. It also supports webhooks that notify external services when your IP address changes. Which one fits depends on what is generating the update — a router, a script, a DNS server, or another service.

The update methods at a glance

Method Typical caller What it needs Best when
REST API Custom scripts, apps HTTP client, zone/record identifiers You want full control over records and zones
Update API Simple scripts, cron jobs HTTP request with hostname and address You want a minimal update call
DynDNS API Routers, NAS devices Router's built-in DynDNS client Your device already speaks the DynDNS protocol
SSH with public key authentication Servers, admin scripts SSH key pair registered with dynv6 You prefer pushing updates over an authenticated shell
DNS updates with TSIG keys DNS servers, nsupdate-style tools Shared TSIG secret You update records through the DNS protocol itself
Webhooks External services A URL to call on IP change You need to notify something else, not just dynv6

Choosing by scenario

Your router or NAS has a DynDNS field

Use the DynDNS API. This is the path of least resistance: you enter the hostname and credentials your device expects, and the device sends the update whenever its address changes. No scripting required.

You are writing your own updater

Use the REST API if you need to manage zones and records in detail, or the Update API if you only need to push a new address for an existing hostname. Both are HTTP-based, so any language with an HTTP client works.

You manage servers and already use SSH keys

Use SSH with public key authentication. You register your public key with dynv6, then push updates over an authenticated SSH session instead of embedding an HTTP token in a script.

You run your own DNS tooling

Use DNS updates with TSIG keys. TSIG authenticates the update at the DNS protocol level, which fits environments where updates are already issued through DNS tooling rather than HTTP.

You need to tell another system about the change

Use webhooks. When your IP address changes, dynv6 can call an external service so that system stays in sync — useful when the address change matters beyond dynv6's own records.

How dynv6 maps a private host to a public hostname

dynv6 combines your MAC address or Host ID with your dynamic IPv6 prefix. The documented example is:

2001:1234::/64 + 00:80:41:ae:fd:7e = 2001:1234::280:41ff:feae:fd7e

This is why you do not need NAT or port forwarding to reach private hosts: the hostname resolves to an address derived from the prefix and the host identifier.

Before you commit

dynv6 describes itself as free for everyone, and you can either choose a free hostname or delegate your own domain to it. Two limits are stated on the site and matter for method choice:

  • There is no enterprise-grade DDoS protection or SLA.
  • The site advises against using it for critical services.

If your update path feeds anything business-critical, treat those two statements as the deciding factor rather than the feature list.

Verifying an update worked

Whichever method you pick, the check is the same: after the update runs, resolve the hostname and confirm it returns the address you sent. If it does not, the usual causes are a wrong hostname or zone identifier, a stale credential or TSIG key, or the update reaching dynv6 but the record not matching the name you queried.