Appendix D: Best Practices Checklist

Organized by role. Use this as an audit tool when setting up a new domain or reviewing an existing infrastructure. Not every item applies to every situation — mark items N/A with a reason when they're genuinely not applicable.

Developer Checklist

DNS Behavior in Applications

Application does not cache DNS resolutions indefinitely (respects TTL)
HTTP client library is configured to re-resolve hostnames after TTL expiry
No hardcoded IP addresses in application configuration that should be hostnames
Application handles DNS failures gracefully (appropriate timeout + retry logic)
Application logs DNS errors distinctly from connection errors

Container and Kubernetes DNS

ndots setting reviewed for pod DNS config (default of 5 is usually too high for external queries)
External service URLs use FQDNs (trailing dot) or ndots: 1 is configured
CoreDNS metrics are being collected
NXDOMAIN rate from CoreDNS is monitored and baselined
Services using internal DNS discovery tested after DNS configuration changes

Email Authentication (For Domains You Send From)

DNS Records for New Deployments

A/AAAA records created for all services
Apex domain uses ALIAS/ANAME (not bare CNAME)
www subdomain configured
No wildcard records created accidentally
Deprecated subdomains removed when infrastructure is decommissioned
DNS changes are part of deployment runbooks

Ops/SRE Checklist

Authoritative DNS Architecture

Two or more DNS providers serve authoritative answers for primary domains
Zone transfers configured and tested between primary and secondary
SOA serial consistency verified between providers after each zone change
Automated check runs to detect SOA serial drift between providers
NS records at parent (registrar delegation) match NS records in zone
Glue records published correctly for nameservers within the delegated zone

TTL Strategy

TTLs documented for each record type and operational state
Process exists for pre-lowering TTLs before planned changes
No static records set to TTL > 86400s without documented reason
After changes are confirmed, TTLs raised back to normal operational values
TTL values reviewed annually as part of DNS audit

Registrar and Registry Security

2FA enabled on all registrar accounts
Registrar accounts use shared/service email addresses (not individual personal email)
clientTransferProhibited (EPP transfer lock) enabled on all active domains
Registry lock (server-side lock) enabled on Tier 1 critical domains
Auth codes documented in a secure password manager
Auth codes verified as current (not expired) for critical domains
Registrar account has minimum necessary user access
No shared credentials for registrar accounts

DNSSEC

DNSSEC status decision documented for each zone (enabled / not applicable / known risk accepted)
If DNSSEC enabled: DS records published at parent registry
If DNSSEC enabled: RRSIG expiry monitoring in place
If DNSSEC enabled: key rollover schedule documented and tested
If DNSSEC enabled: DNSSEC validation can be tested (dig +dnssec)

Monitoring

External DNS health checks running for primary domain A record
External DNS health checks running for MX records
NXDOMAIN rate alert configured on resolvers
SERVFAIL rate alert configured
Resolution latency P95 monitored
SOA serial consistency check between providers automated
Certificate Transparency monitoring configured for unexpected cert issuance
Passive DNS monitoring for new domain registrations matching brand patterns
Monitoring coverage verified from multiple geographic locations

Change Management

DNS changes go through a documented review process
DNS zone configuration stored in version control
Drift detection runs periodically (IaC plan or equivalent)
Runbooks include DNS change steps for all deployment types
Post-change validation is documented and executed

Incident Response

DNS incident runbook exists
Team knows how to initiate emergency TTL lowering
Contact information for DNS providers' emergency support is documented
DNS failover to secondary provider has been tested (not just configured)
Registry/registrar emergency contact procedures documented

Domain Manager Checklist

Portfolio Inventory

Complete inventory of all registered domains maintained and current
Each domain has a documented owner (person or team responsible)
Each domain has a classification (active brand / active redirect / defensive / unknown)
Expiry dates are tracked with 60-day advance reminders
Registrant contact email addresses are active and monitored for all domains

Registration Strategy

Tiered registration strategy documented (Tier 1, Tier 2, Tier 3)
Strategy reviewed when entering new markets or launching new products
New domain registrations include rationale in the portfolio record
Renewal decisions are made actively, not by default auto-renewal
"Unknown" classified domains are resolved (drop or reclassify) at next audit

Registrar Hygiene

All critical domains consolidated at a registrar with API access
Secondary registrar relationship exists for resilience
Registrar has been evaluated against technical requirements (API, EPP status visibility, support quality)
Registrar account contact information current

Security and Monitoring

Passive DNS monitoring active for newly registered domains matching brand
Monitoring covers known typosquat patterns
Certificate Transparency monitoring for unexpected cert issuance on brand domains
UDRP response process documented (who decides, who files, which provider)
Key typosquat variants not in portfolio are monitored rather than registered
High-risk typosquat variants (Tier 2) are owned and pointed to a redirect

Audit Process

Annual domain portfolio audit scheduled and owned
Audit covers: expiry status, technical health, classification review, renewal decisions
Post-audit remediation backlog created and tracked
Date of last audit documented
Next audit date scheduled before closing current audit

New Domain Launch Checklist

When adding a new domain to production, work through this sequence: