DNS provisioning

DNS provisioning is the process of programmatically adding, updating, or removing DNS records through an API rather than by hand in a DNS panel. For a SaaS, it's the layer that turns "customer added a domain in the dashboard" into "the right records exist in the right DNS zone."

The phrase is most often used in two contexts:

1. Your DNS, where you control the zone (your own product domain). Provisioning happens through your DNS host's API: Route53, Cloudflare, GoDaddy DNS, etc.
2. Customer DNS, where they control the zone. You can either provide instructions for them to add records manually, use Domain Connect to write records via the DNS provider's consent flow, or do nothing (and just wait for them to point at you).

What a provisioning flow looks like

For a custom-domain platform onboarding a new customer:

1. Customer enters app.customer.com in your UI.
2. Your backend records the request, generates a unique CNAME target on your edge (abc-customer.yoursaas-edge.com).
3. Your backend tells the customer the records to add: app.customer.com CNAME abc-customer.yoursaas-edge.com and an ACME validation CNAME.
4. Provisioning step: depending on the customer's DNS provider:
   • Manual. You email instructions or show them in the dashboard. Customer adds records by hand at their DNS panel.
   • Domain Connect. You redirect them through the consent flow; their DNS provider writes the records.
   • You manage their DNS too. Less common, but some products own DNS hosting end-to-end. You write the records via your DNS host's API.
5. Your backend polls until the records resolve correctly.
6. Once verified, you request a TLS cert and put the hostname into routing.

Pitfalls

• TTL too long. If the customer sets TTL to 86400 (1 day) and then changes the record, propagation is slow. Recommend 300 or 60 in the instructions.
• DNS provider stripping or rewriting records. Some providers (mainly Cloudflare with "proxied" mode) auto-proxy CNAME records, which breaks ACME validation. You have to instruct customers to use "DNS only" mode for the relevant records.
• Provider API rate limits. Bulk operations hit them. AWS Route53 limits are roughly 5 requests/sec/zone; Cloudflare around 1200/5min for free accounts. Plan for backoff.
• Auth churn. API keys rotate, get revoked, lose scopes. Your provisioning service should monitor itself and alert when API calls start failing for an obvious reason.

In a custom-domain SaaS

The provisioning layer is internal infrastructure. Customers don't see it; they see "your domain is connected." Behind that label sits the verification poller, the cert issuer, the routing config push. Treat provisioning as a state machine: pending verification → verified → cert issuing → cert ready → live. Surface state to support and observability dashboards so failures are obvious before customers notice.