DynIP: Dynamic DNS for Infrastructure
Dynamic DNS sounds like a homelab convenience until a real service depends on an ISP address, a remote edge site, or a small customer appliance. The hard part is not just updating an A record. The hard part is doing it securely, quickly, and in a way operators can monitor.
DynIP is a dynamic DNS control plane built around familiar DNS primitives. Its public pricing page lists REST API support, RFC 2136 TSIG updates over UDP/53, DNSSEC where available, free Let's Encrypt certificate issuance, 2FA, and replication across multiple geographic nameservers.
What Is DynIP?
DynIP is a hosted dynamic DNS service for homelabs and infrastructure teams. Users create zones, copy generated router snippets, and let devices update DNS records as their public address changes. The service detects IPv4 and IPv6 based on the incoming connection, which matters for dual-stack networks where the useful address can differ by path.
The interesting part for operators is RFC 2136. Instead of treating DDNS as a custom webhook bolted onto DNS, DynIP supports the standard dynamic update mechanism secured with TSIG keys. That makes the update path easier to reason about and easier to fit into existing router and DNS tooling.
Key Features
- RFC 2136 TSIG updates: use a standard DNS update flow instead of only provider-specific HTTP calls.
- IPv4 and IPv6 support: keep dual-stack endpoints reachable as upstream addresses change.
- DNSSEC where available: reduce the gap between dynamic records and modern DNS integrity expectations.
- Bring your own domain: delegate custom namespaces instead of forcing every endpoint under a shared provider zone.
- API automation: use the REST API for provisioning, monitoring scripts, and MSP workflows.
Quick Workflow
A typical setup starts in the DynIP console:
# Operator workflow
# 1. Create a zone for the router, edge node, or appliance.
# 2. Copy the generated RFC 2136 or device-specific snippet.
# 3. Store the TSIG secret in the router or host secret store.
# 4. Monitor the hostname from outside the network.
dig +short edge.example.net A
dig +short edge.example.net AAAA
That last step matters. DDNS is only useful if the new record resolves from the places users or automation actually connect from.
Operational Tips
Treat DDNS update credentials like production secrets. Scope them per zone when possible, rotate them after device compromise, and avoid sharing one key across unrelated sites.
Set a low but sane TTL. Very low TTLs can increase resolver traffic, while high TTLs make failover and address changes feel broken. Also monitor more than one thing: the router's detected public IP, authoritative DNS answers, recursive resolver answers, and certificate renewal status.
For incident response, document the ownership chain. Operators should know who controls the parent domain, where DNSSEC is enabled, how the dynamic zone is delegated, and which device is allowed to update each record.
Conclusion
DynIP is useful because it brings dynamic DNS back to standard DNS mechanisms: RFC 2136, TSIG, IPv6, DNSSEC, and delegation. That makes it more interesting than a simple "what is my IP" updater for teams running edge infrastructure or small customer-managed environments.
If you are building reliability workflows around edge services, network automation, and production DNS, Akmatori helps SRE teams connect infrastructure signals to guided investigation and remediation. Akmatori runs on Gcore, giving teams a fast global foundation for production infrastructure.