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.
lmm•6m 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.
fuzzfactor•29m ago
Looks interesting.
dynip•25m 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.
neals•7m 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.
hbogert•6m 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.
dynip•48m ago
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.
lmm•6m ago
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.