DynIP – Dynamic DNS with RFC 2136, IPv6, DNSSEC, and BYOD
107 points
2 hours ago
| 14 comments
| dynip.dev
| HN
dynip
2 hours ago
[-]
I'm Daniel, network engineer in Sweden. Built DynIP because every DDNS service I tried was designed around 2010-era networks: proprietary HTTP-only update protocols, poor IPv6, no DNSSEC, little support for actuallymodern devices.

What's in it:

- RFC 2136 / TSIG updates as a first-class path. FortiGate genericDDNS and MikroTik's /tool dns-update work natively — no custom client needed. HTTP API is also available for everything else.

- IPv6 end-to-end. Authoritative nameservers reachable over IPv6 (with AAAA glue published at the parent .dev zone), customer zones publish A and AAAA, and the platform works for IPv6-only clients.

- DNSSEC available on selected zones. With a single toggle.

- Bring your own domain via subdomain delegation. Point subdomain.yourcompany.com at our nameservers, manage normally.

- Hidden primary architecture: two geographically distributed secondaries (Sweden + Switzerland) verify TSIG locally and forward updates to a primary that doesn't take public traffic.

- Private-APN-friendly: we accept RFC 1918 and CGNAT addresses in records, which means cellular fleets on private APNs can use public DNS for stable hostnames pointing at internal IPs. Described in the fleet ops guide.

- A small Docker container (ghcr.io/33k-org/dynip-updater) for any docker-compose / Kubernetes / Coolify / Dokploy setup.

Background: 25 years of managed networking. DDNS was the part that broke or required tricks. Wanted one that didn't.

Stack: PowerDNS 4.8 authoritative, FastAPI backend, Postgres, Postfix for transactional mail, Cloudflare for the external surface and as a tunnel for the API. Live on dynip.dev. Paddle for billing. Free tier exists.

Happy to dig into architecture, the TSIG sync mechanism, per-zone DNSSEC handling, the hidden primary approach, or anything else.

reply
ghoshbishakh
11 minutes ago
[-]
How do the geo distributed secondaries work? How do they sync?

Also, is there anycasting?

reply
dynip
8 minutes ago
[-]
The geo sync updates are handled with distributed keys over internal api, here is the documentation for powerdns around it: https://doc.powerdns.com/authoritative/dnsupdate.html#dnsupd... so the updates are pushed and updated to primaries if the update is done over DNS and if done via API there is a normal replication function.

right now there is no anycast available, possible in the future

reply
bflesch
7 minutes ago
[-]
Well done. Would be nice to remove a bit more five eyes tracking from your stack, e.g. remove includes from 3rd party domains such as unpkg / tailwindcss.com and of course get rid of cloudflare.
reply
hfristedt
36 minutes ago
[-]
Thanks for sharing!

How did you set up PowerDNS? Single/multiple instances? One DB shared by many or multiple authoritative with one hidden primary?

reply
dynip
19 minutes ago
[-]
There are multiple multiples :) both (hidden) primary and secondaries are multiple, snapshots every 20 minutes and forward-update functionality from the secondaries with replicated tsig over powerdns api every 120 seconds. since they are static they only need to replicate once.

if you register a zone and open the snippets quickly, there is a green notification saying tsig replication underway for x amount of seconds and until that happens RFC 2136 updates are not possible but the ones that use api are available right off the bat.

reply
lmm
1 hour ago
[-]
> we accept RFC 1918 and CGNAT addresses in records

Doesn't that cause security issues by making it possible to put other people's private servers (that you want to do XSS-type attacks against) into your domains or something? I have a vague memory of it being a security no-no somehow.

reply
dynip
1 hour ago
[-]
There are a few things to think about yes, I actually post in the fleet guide parts of it that it should be considered before posting. the dns rebind issue but that should be controlled by host header validation, CSRF, same-site cookies etc. Internal topology disclosure — real. but we dont post it. You can do the same in Cloudflare for example.
reply
tapland
1 hour ago
[-]
Skål! Looks like a huge effort-reliever, excited to try it out.
reply
dynip
1 hour ago
[-]
Skål!
reply
yuvadam
16 minutes ago
[-]
I used to set up my own OpenWrt DDNS scripts that update AWS Route 53 or Cloudflare DNS which solved enough of that problem for me.

Then Tailscale came out and I stopped caring about DDNS or CGNAT ever since.

reply
dynip
2 minutes ago
[-]
Tailscale is awesome, and Netbird is awesome, and Wireguard is awesome. It is a great time to be alive for sure. I have a guide that I wrote https://dynip.dev/guides/tailscale where I explain how and why they can exist

Agree that the OpenWrt DDNS scripts are a bit of a pain with keys secrets but the snippets function actually take the guess / how-does-it-work work out of the equation so I am pretty happy with that

reply
hbogert
1 hour ago
[-]
Bonus points for rfc 2136, works easily with [external-dns](https://github.com/kubernetes-sigs/external-dns). I've been using k8s+external-dns on-prem with a selfhosted minimal BIND server on a public host for years now.
reply
dynip
1 hour ago
[-]
Thanks — external-dns + RFC 2136 is a great call. Honestly that's a guide we should write; we already have one for fleet operations and the k8s pattern is the natural extension.
reply
jmusall
34 minutes ago
[-]
Refreshing to see competition entering this space.

However, if you want to self-host, not caring for reliability or ease of use: bind9 supports RFC 2136 DNS UPDATE and DNSSEC, too (haven't figured that out yet, though). For my setup I also wrote a small Go executable that translates HTTP requests, because my home router does not talk DNS UPDATE.

reply
dynip
11 minutes ago
[-]
Thanks! Hope there is room for something fresh and flexible!

And yes, BIND allows for a lot of different things, RFC 2136 being one of them and I have been looking at multiple options before settling down on the current structure. I built a few test cases from my Fortigate (dynip came to be initially fortigate only with simple copy paste over dns internally)

And there are a few code examples that can be used internally on various hosts, windows or linux, there is even an arduino example if you have any iOT devcices lying around in your home lab. and Writing a Go executable is a good idea, look out under /docs for updates :)

reply
secret-noun
33 minutes ago
[-]
Is it right that the free-tier auth tokens expire in 24 hours (saw the JWT exp claim)? I would like to know this before investing too much time in migrating, even just to try it out. Trying to answer: is the free tier sustainable?
reply
dynip
28 minutes ago
[-]
"Long-lived token" means API tokens for the management API (creating/ deleting zones, listing them, automating via Terraform-style flows), not the TSIG keys for actual DNS updates. Every zone on every tier gets its TSIG key — that's what powers the updates themselves. Free tier manages zones via the dashboard; paid tiers add API tokens for programmatic management.

So no. the auth token is just for the API and can be used as a bearer for the api, the TSIG are always valid unless the domain is deleted

the free tier allows for 5 zones and all get individual tsig keys and they are always active. no need to pay unless you start handling 100s of new zones, updates, delete etc. so there is a split between the two types of tokens. hope it is clear

reply
SadTrombone
12 minutes ago
[-]
I would maybe amend that to the pricing page, I also thought "long-lived API tokens" referred to the DNS updater functionality, not the management API.
reply
dizhn
39 minutes ago
[-]
I like the 2000 era HTTP(S) only updates. All you need is curl/wget/fetch and it works. Add a token if you like. I think duckdns can still do this. No client needed, works almost anywhere. --
reply
dynip
37 minutes ago
[-]
Yep, this is also true for dyndns curl/wget/fetch, have a look at the /docs on other special things that we can do except those. there is a larger functionality base here that I try to cover and not only (but including) curl/wget/fetch.
reply
tcfhgj
48 minutes ago
[-]
Free tier says without long lived token - how would you use dyndns without one?
reply
dynip
31 minutes ago
[-]
"Long-lived token" means API tokens for the management API (creating/ deleting zones, listing them, automating via Terraform-style flows), not the TSIG keys for actual DNS updates. Every zone on every tier gets its TSIG key — that's what powers the updates themselves. Free tier manages zones via the dashboard; paid tiers add API tokens for programmatic management.
reply
arianvanp
1 hour ago
[-]
This will be great for my homelab. Currently I have some hacky scripts to update he.net records whenever my ISP sends me a new ipv6 prefix but I'd prefer to reuse existing tooling.

Looking into switching today :D

reply
dynip
1 hour ago
[-]
Best use case!

Check the snippets after you create a zone, hopefully less hacky scripts :D

reply
fcpk
1 hour ago
[-]
This is great! and and amazing idea.

Just as a warning however the vibe coded website doesn't inspire confidence this isn't low quality auto generated AI slop and/or AI managed infra.

Looking into it of course this seems to not be the case, but just wanted to say, don't use generic looking theming that is default of all LLM-generating websites :)

reply
dynip
1 hour ago
[-]
One of my things are that I am an engineer and I build functionality for engineers, this has always been the case. I am bad with visualizing this so the vue framework has helped tremendously with that.

With that said, I hope as well that it is a amazing idea, I am really happy with how it works and performs.

reply
justassimplex
1 hour ago
[-]
I usually set up a wireguard tunnel from my home box serving content on nginx to my linux server hosted on a virtual cloud server and have that virtual cloud server pass traffic via the wireguard tunnel back to my home box when people view my content.
reply
dynip
49 minutes ago
[-]
yep sounds valid, keeps the internet traffic nice and secure
reply
neals
1 hour ago
[-]
Would love to know what it is and what it is doing that others are doing wrong. I don't touch dns for anything other then pointing a domain to a server.
reply
dynip
1 hour ago
[-]
But you do touch DNS :) and the idea here is to create as little friction or easy setup as possible with either fixed, dynamic or unknown ips.

One example I used it for just a few days ago was to set up dual ipsec tunnels for redundancy in fortigate in a remote warehouse. with the snippets I can just add a byod domain and paste the config into the cli and ship the devices. when they connect it it dials up, updates the ip in the dashboard (with notification that it has changed) and the vpn tunnels comes up automatically. it is available as road warriors as well, or dialup ipsec tunnels but I want dual initiator functionality.

Maybe this reply isnt really what the site is for but rather a subset of what can be done.

have a look at https://dynip.dev/guides/ I tried to add substantial information on what can be done

reply
sam_lowry_
1 hour ago
[-]
If only OVH supported RFC 2136 / TSIG updates...
reply
dynip
1 hour ago
[-]
lol, we can probably figure something out :)
reply
znpy
1 hour ago
[-]
I have fond memories of playing with dyndns and having cool domains like <mynick>.homeunix.net … and having downtime because my home dns connection went down and came back up with a different ip address.

Fun times :)

reply
dynip
1 hour ago
[-]
I did the same! back when DNS was new and exciting and not a full on requirement for everyhing you touch nowadays. I have been thinking about that since then really and finally thought I would bring some of that back!

Thanks for being awwesome!

reply
fuzzfactor
2 hours ago
[-]
Looks interesting.
reply
dynip
2 hours ago
[-]
Thanks, I am very happy with it. Reading the /guides or /docs myself actually feels good. inside the dashboard I have built a "snippets" javascript that creates the config for you. I mostly live in the cli myself so most is based on that.
reply