DynIP – Dynamic DNS with RFC 2136, IPv6, DNSSEC, and BYOD
DynIP feature set and goals
- Positioned as a “modern” DDNS: first-class RFC 2136/TSIG updates, robust IPv6 (including IPv6-only clients), optional DNSSEC, and “bring your own domain” via subdomain delegation.
- Supports private/RFC1918 and CGNAT addresses so private APN / cellular fleets can use public DNS for stable hostnames pointing to internal IPs.
- Provides Docker-based updater, HTTP API for non-RFC2136 clients, and LetsEncrypt DNS-01 integration with certificate retrieval via API/dashboard.
- Target users include homelabs, fleets, FortiGate/MikroTik environments, and Kubernetes setups via
external-dns.
Architecture & infrastructure
- Built on PowerDNS authoritative servers, FastAPI, Postgres, Postfix; Cloudflare fronts the external surface and API tunnel.
- Hidden-primary design: two geo-distributed secondaries (Sweden, Switzerland) validate TSIG, then forward updates to a non-public primary.
- Secondaries sync TSIG/updates via PowerDNS API and distributed keys; no anycast yet but considered for the future.
- Backups/snapshots and a passive primary node are mentioned; single Postgres backend for the primary.
Security and private-address DNS
- Concern raised that allowing RFC1918/CGNAT records could enable DNS rebinding or expose internal topology.
- Response: most DNS providers allow this; mitigations should live in the application/browser (host header checks, CSRF protection, cookies). Internal topology disclosure is real but seen as an operator risk tradeoff.
Tokens, free tier, and update model
- Confusion over “long-lived tokens” on pricing:
- TSIG keys are per-zone and used for DNS updates; they don’t expire unless the zone is deleted.
- JWT/bearer tokens are for account and management API (creating/deleting/listing zones).
- Free tier: up to 5 zones, TSIG-based updates, but no long-lived management API tokens; configuration primarily via dashboard. Multiple commenters suggest clarifying this on the pricing page.
Comparisons and alternatives
- Comparisons to desec.io (IPv6, DNSSEC, BYOD, IPv6 prefix delegation), registrar-hosted DDNS, BIND9 self-hosting, and router scripts updating Route53/Cloudflare.
- Some argue VPN + reverse proxy (Tailscale, Netbird, WireGuard) reduces the need for DDNS; others still want DDNS for public-facing services, dev/test, or where VPN is unnecessary.
UX, design, and AI-related criticism
- Several commenters find the landing page “generic” or “vibe-coded” and assume AI-generated copy; others push back that such accusations are overused.
- Suggestions: simplify the design, write more personal copy (even in native language), reduce third-party includes, and consider EU-native CDN/edge alternatives to Cloudflare.
- Minor UX issues reported (password reset flow, Firefox Focus tracking protection) and acknowledged as fixed or queued.