Automated SSL/TLS Certificates with RFC 2136 & TSIG

Automated Wildcard Certificates

Wildcard certificates (e.g. *.example.com) strictly require ACME DNS-01 challenges. RFC 2136 allows clients to dynamically provision and remove validation TXT records without manual DNS editing.

Private Servers & Firewalled Environments

Issue public trusted certificates on internal staging hosts, private VPN endpoints, or behind strict NAT firewalls. The ACME CA verifies your authoritative Anycast DNS — your web nodes never need public inbound ports.

Least-Privilege Subdomain Scoping

Avoid giving broad account or zone-wide permissions to web servers. Restrict the TSIG key specifically to _acme_challenge.example.com so ACME scripts cannot modify other DNS records.

Rapid Challenge Verification

OnlyDNS propagates RFC 2136 dynamic updates to all 23 global Anycast PoPs in 0.2 to 5 seconds. No 120-second sleep timeouts — certificate renewals complete swiftly.

Zero Vendor Lock-In

RFC 2136 is an open IETF standard supported by BIND, PowerDNS, and Knot DNS. You don't need third-party proprietary plugins that break on software updates.

Works with All ACME CAs

Fully compatible with Let's Encrypt, ZeroSSL, Google Trust Services, Buypass, Sectigo, DigiCert, and internal CAs (Smallstep, HashiCorp Vault).

Create TSIG Key in Portal or CLI

Log into the OnlyDNS Portal > DNS Management > TSIG Keys or use the CLI. Generating a TSIG key automatically assigns a unique key name along with its algorithm and secret:

Standard Connection Parameters

Use the following standardized connection parameters across all client configuration files or environment variables:

• Server: ns1.onlydns.com (Port 53 UDP/TCP)
• Key Name: Your generated TSIG key name
• Algorithm: HMAC-SHA256 / hmac-sha256
• Secret: Your base64 TSIG secret key

Issue & Verify Propagation

Run your ACME client. It will automatically submit an RFC 2136 update to create _acme-challenge.example.com TXT, verify it with the CA, and immediately delete the record upon success.

🛡️ Restrict Keys to _acme_challenge

In the OnlyDNS Portal or REST API, restrict the TSIG key's allowed subdomains to _acme_challenge. Even if a web server is compromised, the attacker cannot alter root records, MX records, or other services.

🔐 Scope TSIG Keys per Host

Never share a single TSIG key across multiple production servers. Generate dedicated TSIG keys for each individual server or Kubernetes cluster and configure permissions per domain so compromise is strictly isolated.

⏱️ Ensure Accurate Server Time (NTP)

TSIG packets use timestamps to prevent replay attacks (RFC 2845). Ensure your servers synchronize with NTP (e.g. chrony or systemd-timesyncd). Clocks offset by more than 300 seconds will be rejected by authoritative nameservers.

🔒 Secure File Permissions (0600)

Ensure TSIG credential files (e.g. /etc/letsencrypt/rfc2136.ini) are owned by root:root with permissions set strictly to chmod 600 to prevent unprivileged users from reading cryptographic secrets.

Why use RFC 2136 instead of proprietary HTTP API tokens?

RFC 2136 is an open IETF internet standard supported natively across all major ACME clients and operating systems. Unlike proprietary HTTP REST APIs, RFC 2136 uses cryptographically signed TSIG packets (RFC 2845), works without vendor-specific plugins, supports domain-level TSIG key authentication, and propagates across OnlyDNS Anycast edge nodes rapidly (typically 0.2 to 5 seconds).

Can I issue wildcard SSL certificates (*.example.com)?

Yes. Wildcard certificates strictly require the ACME DNS-01 challenge because HTTP-01 challenges cannot prove ownership of arbitrary subdomains. RFC 2136 allows automated creation and deletion of the required TXT validation records on _acme-challenge.example.com instantly.

Do my servers need open inbound HTTP/HTTPS ports to issue certificates?

No. Because DNS-01 challenge validation queries OnlyDNS authoritative Anycast nameservers directly, your web servers can be entirely private, firewalled, behind NAT, or running inside internal Kubernetes clusters without opening port 80 or 443 to the public internet.

What is the propagation delay with OnlyDNS during ACME challenges?

Updates sent via RFC 2136 synchronize across all 23 OnlyDNS global Anycast edge nodes in typically 0.2 to 5 seconds. You can safely configure your ACME client propagation sleep to 5-10 seconds instead of the typical 60-120 seconds required by legacy DNS providers.

Can I restrict TSIG keys to only update _acme_challenge?

Yes. In the OnlyDNS Portal or REST API, you can restrict TSIG keys to only update designated subdomains (such as _acme_challenge). This enforces true least-privilege isolation, ensuring automated SSL renewal daemons or compromised web servers cannot alter your root records, MX records, or other production subdomains.