DNS Management

DNS Management is the end-to-end administration of domains, nameservers, and zone files so users and services can reliably resolve your website (and email, APIs, CDNs) to the right IPs—quickly, securely, and with controlled failover during incidents and deployments.

What it includes

  • Domain & registrar control: Renewals, WHOIS privacy, contact data, DNSSEC DS records.
  • Authoritative hosting: Nameserver delegation, zone creation, access control, audit logs.
  • Record lifecycle: Add/modify/remove A/AAAA, CNAME/ALIAS, MX, TXT (SPF/DKIM/DMARC), SRV, CAA, NS, SOA.
  • TTL strategy & caching: Balancing fast propagation vs. resolver cache efficiency; negative caching (NXDOMAIN) considerations.
  • Performance & resilience: Anycast NS, health-checked failover, GeoDNS/latency routing, multi-provider DNS.
  • Security & compliance: DNSSEC signing, CAA to restrict certificate issuance, change approvals, least privilege.
  • Monitoring & alerting: Resolution success, nameserver consistency, DS/NS/glue mismatches, propagation checks, query latency.

Key records (when to use them)

  • A / AAAA: Point hostnames to IPv4/IPv6. Prefer dual-stack for reach.
  • CNAME: Alias one hostname to another (not allowed at the zone apex). Use ALIAS/ANAME at apex if your provider supports it.
  • MX: Mail routing; pair with SPF (TXT), DKIM (TXT), DMARC (TXT) to prevent spoofing.
  • TXT: Verification (e.g., Google, CDN), SPF, ownership proofs.
  • SRV: Service discovery (e.g., SIP, XMPP).
  • CAA: Limit which CAs can issue certificates for your domain.
  • NS / SOA: Delegation and zone authority; watch serial increments and refresh/retry timers.

Architecture (how lookups actually resolve)
Recursive resolvers cache answers according to TTLs. A query walks root → TLD → your authoritative NS (using glue records from the parent zone). Good management ensures your NS set is healthy, consistent, and Anycast-backed for low latency worldwide.

Best practices for website support teams

  • TTLs by purpose:
    • Stable records (MX, NS) → 1–24h.
    • CDN/front-door records → 5–30m (shorten to 60–300s before a cutover).
  • Cutover playbook: Lower TTL 24–48h ahead, validate new target, switch, verify, then restore normal TTLs.
  • Failover: Use health-checked records or load balancer/CNAMEs to reroute on origin failure.
  • Security: Enable DNSSEC where supported; set CAA for your chosen CA; lock registrar changes.
  • Separation: Keep prod and non-prod in separate zones or subdomains; restrict who can edit prod.
  • Auditability: Require code-reviewed zone changes (GitOps or provider templates).
  • Monitoring: Alert on DS/NS drift, serial mismatches, sudden NXDOMAIN spikes, or query latency outliers.

WordPress/WooCommerce specifics

  • Canonical hostnames: Decide on www vs apex; redirect the other at the edge. If using a CDN, map www to the CDN CNAME and use ALIAS/ANAME at apex if you need it.
  • Behind CDN/Proxy (e.g., Cloudflare): Ensure real IPs reach WordPress; set HTTP_X_FORWARDED_PROTO=https so WordPress detects HTTPS.
  • Email deliverability: If the site sends order/notification emails, maintain correct MX, SPF, DKIM, and DMARC for your sending domain (don’t break it during DNS moves).
  • Multi-region: Consider GeoDNS only if your app and data are replication-ready; otherwise keep routing simple and use the CDN.

Common pitfalls

  • CNAME at zone apex (breaks) instead of ALIAS/ANAME.
  • Not lowering TTL before migrations, causing long propagation delays.
  • DS/NS mismatches after registrar or DNS host changes (DNSSEC breaks resolution).
  • Removing verification TXT records too early (CDN/email/domain verifications fail).
  • Over-aggressive wildcards capturing unintended subdomains and masking real issues.

KPIs

  • Authoritative DNS availability and p95 lookup latency.
  • Propagation time for planned changes.
  • NXDOMAIN rate (unexpected spikes indicate broken links or typos).
  • Zone change failure rate and mean time to repair (MTTR) for DNS incidents.