Prosumer · Dynamic DNS

Using UniFi Dynamic DNS with DynIP

Your UniFi gateway already ships a Dynamic DNS client. This guide configures it to keep your DynIP zone's A record pointed at the gateway's current WAN IPv4 — four fields in the UniFi UI, no scripts, no SSH, nothing to install. The one non-obvious part is that you must pick Custom, not the option called “Nsupdate”, and this guide explains why.

What this is for

UniFi OS bundles inadyn, a small DDNS daemon, and exposes a handful of its settings through Settings → Internet → Dynamic DNS. Pointed at DynIP, it sends a periodic HTTP GET to api.dynip.dev/update carrying your hostname, the detected WAN IPv4, and your key. DynIP updates the zone's A record and answers good.

The division of labor is simple: the gateway owns IP detection and scheduling; DynIP is authoritative DNS. There's no agent to install on a LAN host and no state kept anywhere but UniFi's own config store.

This integration gets you:

  • Your zone's A record following the gateway's WAN IPv4 automatically
  • Setup entirely in the UniFi UI — no SSH, no boot scripts, no packages
  • Survives firmware updates and reboots, because it's native UniFi configuration
What this does not do. IPv6 is out of scope — UniFi's Dynamic DNS form only handles the WAN IPv4, and publishing an AAAA record needs a persistent boot script. See IPv6 support below. This integration also does not use RFC 2136 / TSIG; it's a plain HTTP DDNS client, so none of the TSIG algorithm or DNSSEC preconditions from the FortiGate or Proxmox guides apply here.

What you'll need

  • A UniFi gateway — UDM, UDM Pro, UDM-SE, UDR, or UXG — with admin access to its settings. This guide was validated end-to-end on 2026-08-27 against a UDM-SE running UniFi OS v5.1.19.
  • A DynIP account with a zone provisioned. We'll use home.ddns.dynip.dev throughout; substitute your own.
  • Your zone's key, from the dashboard's Snippets panel.
  • A routable WAN IPv4 on the gateway. If your ISP puts you behind CGNAT, the record will publish your CGNAT-side address — see troubleshooting.
Older UDM hardware. On first-generation UDM hardware running UniFi OS 1.x we previously hit enough friction on the gateway — a stale CA bundle breaking TLS to the update endpoint, URL-parsing quirks in the bundled inadyn — that we recommended running the DynIP Docker container on a LAN host instead. Modern UniFi OS resolves those, and the configuration below is what we now recommend. If you're on UniFi OS 1.x and this doesn't work, the container remains the dependable fallback.

Why “Custom” and not “Nsupdate”

The Service dropdown in UniFi's Dynamic DNS form lists an option called Nsupdate. The name strongly suggests RFC 2136 DNS UPDATE — the TSIG-authenticated protocol that nsupdate(1) speaks, and that DynIP does support on update.dynip.dev. It is not that.

UniFi's “Nsupdate” does not speak RFC 2136

Despite the label, it is another inadyn HTTP-based custom provider — there is no DNS UPDATE, no TSIG, and no way to supply a key name. Selecting it produces a config whose server line ends in :1, and inadyn then tries to open a TCP connection to port 1.

The symptom, in /var/log/messages on the gateway, looks like this:

inadyn[...]: Failed connecting to update.dynip.dev: Operation now in progress

The trailing :1 on the config's server line is the giveaway. Always choose Custom. If you already created an entry with Nsupdate, delete it and recreate it — editing it in place does not always clear the bad server value.

Step-by-step setup

In the DynIP dashboard, click Snippets on your zone and choose UniFi (UDM / UDR / UXG). The snippet is a list of field values to transcribe, not a script to run. Then in your UniFi controller, go to Settings → Internet → Dynamic DNS and click Create New.

Fill in the five fields as follows:

Field Value
Service Custom — never Nsupdate, see above
Hostname home.ddns.dynip.dev — the FQDN whose A record you're updating
Username unused — any non-empty value; DynIP ignores it
Password Your DynIP key, pasted verbatim
Server api.dynip.dev/update?domain=%h&ip=%i&key=%p

Click Save. That's the whole procedure.

The Server URL is the same for everyone

Note that the Server value contains no personal data — it is byte-identical for every DynIP user. The % tokens are inadyn substitutions, filled in at request time from the other fields on the same form:

  • %h — the Hostname field
  • %i — the WAN IPv4 that inadyn detected for the gateway
  • %p — the Password field, i.e. your key

So only Hostname and Password vary between users. That's deliberate: it keeps the longest and most error-prone field a constant you can copy without reading, and confines per-user copy-paste to two short values.

About the Username field

DynIP's /update endpoint authenticates from the query string, so the username is irrelevant to it. UniFi's form, however, validates Username as required and will not save while it's empty. Putting the literal word unused there documents the situation for whoever reads the config next.

Verifying the setup

The direct check is to resolve the zone and compare it with the gateway's WAN IPv4:

dig home.ddns.dynip.dev @1.1.1.1 +short

This should return your current public IPv4.

Forcing an immediate update

inadyn only sends an update when it notices the WAN IP has changed, so a freshly saved entry on a stable connection may not fire for a while. To force one, SSH into the gateway as root and signal the daemon:

kill -USR1 $(pgrep inadyn)

Reading the log

grep -i inadyn /var/log/messages | tail -10

A healthy run logs a line of the form Updating IPv4 cache for home.ddns.dynip.dev. If you see nothing at all from inadyn, the Dynamic DNS entry probably didn't save — re-open the form and confirm it's listed.

Troubleshooting

Failed connecting to update.dynip.dev: Operation now in progress

You selected Nsupdate instead of Custom. The generated config points at port 1, which nothing listens on. Delete the Dynamic DNS entry and recreate it with Custom — editing in place doesn't reliably clear the bad server value. See Why “Custom” and not “Nsupdate”.

Fatal error in DDNS server response: DDNS server response not OK

The request reached DynIP but was rejected — either the Server URL is malformed or the key in Password is wrong. Re-check that Server reads exactly api.dynip.dev/update?domain=%h&ip=%i&key=%p (no https:// prefix, no substituted values), and re-paste the key from the dashboard.

UniFi won't save the form — Username validation error

The Username field must be non-empty even though DynIP ignores it. Put unused in it.

dig returns nothing after saving

inadyn fires on WAN IP change by default. If your address hasn't changed since you saved the entry, no update has been sent yet and the record was never created. Force one with kill -USR1 $(pgrep inadyn) over SSH, then re-check.

The A record shows a 100.64.0.0/10 address

That range is CGNAT space: your ISP is sharing one public IPv4 across many subscribers, and your gateway's WAN address is on the carrier's inside. The published record is accurate but not reachable from the public internet. Ask your ISP for a real public IPv4, or reach the site over IPv6 instead once that's supported here.

Removing the setup

Delete the entry under Settings → Internet → Dynamic DNS. That's all — every piece of state lives in UniFi's own config store, so there are no files to clean up and nothing installed on the gateway to remove. The zone's last-published A record stays as it is until something updates it again; change or clear it from the dashboard if you want.

If the key may have been exposed, rotate it from the dashboard afterwards.

IPv6 support (coming soon)

This integration is IPv4 only. UniFi's Dynamic DNS form has no IPv6 field, and inadyn's %i token resolves to the detected WAN IPv4 — there's no UI-level way to publish an AAAA record.

Doing it anyway means SSHing in and installing a persistent boot script under /data/on_boot.d/ that reads the WAN interface's global IPv6 address and posts it to /update. The obstacle is that the WAN interface name varies across UDM, UDM Pro, UDM-SE, UDR, and UXG hardware, so there's no single snippet we can hand you that's correct on all of them. We'd rather ship nothing than ship a script that silently publishes the wrong address, so it's deferred until we have a clean way to handle that variance.

If you need IPv6 on a UniFi gateway today, the pattern from any of our Debian-based device integrations adapts directly — substitute your own WAN interface name and drive the same /update endpoint. The DynIP Docker container on a dual-stacked LAN host is the simpler route, and handles both families without touching the gateway.

What's next