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.