Multi-Domain DNS Management
5 min read
## Multi-Domain DNS Management
Managing one or two domains is straightforward — point and click in a control panel. Managing ten, fifty, or a hundred domains is an entirely different challenge. Configuration drift sets in. Records go stale. Email breaks on a domain nobody noticed. DNS becomes the source of mysterious, hard-to-trace outages.
This guide covers strategies, tools, and patterns for managing DNS at scale without losing your sanity.
## Consolidate onto One DNS Provider
The first rule of multi-domain DNS management: **use a single DNS provider for all domains.** Managing records across five different registrar control panels — GoDaddy, Namecheap, Google Domains, HostGator, and a random WHMCS install — is a recipe for disaster.
**Recommended approach:**
1. Choose a primary DNS provider with a good API (Cloudflare, Route 53, NS1, DNSimple)
2. Migrate all domain zones to that provider
3. Update nameservers at each registrar to point to the new provider
4. Manage all records from one interface or API
Cloudflare's free tier supports unlimited domains with full API access — a compelling option for most use cases. Route 53 charges per zone ($0.50/zone/month) but integrates tightly with AWS infrastructure.
## Naming and Documentation Conventions
Establish consistent naming conventions across all domains:
| Convention | Example |
|------------|---------|
| Root A record | `@` → server IP or load balancer |
| WWW | `www` CNAME to `@`, or matching A record |
| Mail | `mail` A record for SMTP server |
| Staging | `staging` CNAME or A to staging server |
| API | `api` CNAME or A to API server |
| Admin | `admin` CNAME or A to admin interface |
Consistent naming makes it obvious when a domain is missing a standard record. When `mail.newdomain.com` has no A record, it jumps out immediately.
Keep a DNS inventory — even a simple spreadsheet — listing:
- Domain name
- DNS provider
- Registrar
- Nameservers
- Key records (root IP, MX target)
- Owner/team
- Renewal date
## Use a Shared Record Template
For domains that serve the same infrastructure (all pointing to the same web servers, same mail provider), create a template of standard records:
```
; Standard template for example.com group
@ A 203.0.113.10 3600
www CNAME @ 3600
mail A 203.0.113.20 3600
@ MX 10 mail 3600
@ TXT "v=spf1 ip4:203.0.113.20 -all" 3600
_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" 3600
```
When adding a new domain, apply the template and customize only the domain-specific parts (DKIM selector, any unique subdomains).
## DNS as Code
For teams managing many domains programmatically, DNS-as-code tools maintain DNS configuration in version-controlled files and apply changes via CI/CD pipelines:
**Terraform with Cloudflare provider:**
```hcl
resource "cloudflare_record" "root" {
zone_id = var.zone_id
name = "@"
value = "203.0.113.10"
type = "A"
ttl = 3600
}
resource "cloudflare_record" "www" {
zone_id = var.zone_id
name = "www"
value = "example.com"
type = "CNAME"
proxied = true
}
```
**OctoDNS:** A Python tool that manages DNS records across providers from YAML files. Particularly useful when maintaining identical records across multiple providers (for redundancy).
**DNSControl:** A Go-based tool by Stack Overflow. Define DNS zones in a JavaScript-like DSL and push to multiple providers simultaneously.
Benefits of DNS-as-code:
- Version history in git (who changed what, when, why)
- Code review before DNS changes go live
- Automated drift detection — compare live records to desired state
- Bulk changes across many domains in one commit
## Handling Email Authentication at Scale
SPF, DKIM, and DMARC records need to be configured per domain. At scale, this creates two challenges:
**1. SPF record sprawl.** As you add sending services (transactional email, newsletter tools, CRM), the 10-lookup limit becomes a real constraint. Flatten SPF records periodically and consolidate sending to fewer services.
**2. DKIM key rotation.** DKIM private keys should be rotated periodically (annually or after a breach). With many domains, this requires updating DKIM TXT records in bulk. Provider-managed DKIM (Google Workspace, Microsoft 365) handles rotation automatically. Self-managed DKIM requires scripting the key rotation.
## Monitoring for DNS Issues at Scale
**Uptime monitoring with DNS checks.** Services like UptimeRobot, Pingdom, or StatusCake monitor URLs and alert on failures — but not specifically on DNS changes. Add DNS-specific monitors that alert when:
- An A record changes unexpectedly
- MX records disappear
- TTL on critical records drops to abnormally low values (possible prelude to a takeover)
**Certificate expiry monitoring.** SSL certificate expirations become a DNS-adjacent problem at scale — domains that lost valid certificates often have DNS issues too. Tools like [cert-tracker.io](https://cert-tracker.io) or custom scripts using `openssl s_client` can alert before certificates expire.
**Subdomain enumeration audits.** Periodically audit all subdomains for:
- Dangling CNAME records pointing at deprovisioned services (subdomain takeover risk)
- Stale records for decommissioned servers
- Unexpected records that may have been added without documentation
## Subdomain Takeover Prevention
A dangling CNAME is a subdomain that CNAMEs to a third-party service that no longer exists:
```
app.example.com CNAME myapp.s3.amazonaws.com.
```
If the S3 bucket `myapp` was deleted, an attacker can create a new bucket with that name and serve content from `app.example.com` — with your domain's branding and cookies.
At scale, track all CNAME records and their targets. When deprovisioning any service, remove its CNAME record from DNS before (or simultaneously with) deprovisioning. Automated tools scan your DNS zone and alert on unresolvable CNAME targets.
## Bulk Operations via API
All major DNS providers offer APIs for bulk operations. Common patterns:
**Bulk TTL reduction before a scheduled maintenance window:**
```python
import requests
# Cloudflare API: list all A records and lower TTL
headers = {"Authorization": "Bearer YOUR_TOKEN"}
response = requests.get(
f"https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records?type=A",
headers=headers
)
for record in response.json()["result"]:
requests.patch(
f"https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record['id']}",
headers=headers,
json={"ttl": 300}
)
```
**Applying a new MX record across all domains after switching email providers.** One script to update all zones beats clicking through fifty control panels.
## Next Steps
- Cloudflare DNS Setup Guide — migrate all domains to Cloudflare for centralized management
- DNS During Domain Migration — TTL strategy for migrating individual domains
- Wildcard DNS Records — reduce per-subdomain record count with wildcards
- Setting Up DNS for Your Domain — ensure each domain starts with a correct baseline configuration