DNS Security Checklist: 40+ Steps to Lock Down Your Domain

The registrar account is the master key to your domain. If an attacker compromises it, they can repoint your nameservers, transfer the domain away, and hijack every service that depends on it.

• ✓ Enable multi-factor authentication (MFA) — prefer hardware security keys (FIDO2 / WebAuthn) over SMS, which is vulnerable to SIM swap attacks.
• ✓ Use a unique, password-manager-generated password (24+ characters) for the registrar account; never reuse it elsewhere.
• ✓ Set the EPP transfer status to clientTransferProhibited (and serverTransferProhibited at the registry for high-value domains).
• ✓ Subscribe to Registry Lock for premium domains — requires out-of-band verification before any change.
• ✓ Review and minimize the list of authorized contacts; remove ex-employees and old admin emails immediately.
• ✓ Verify auto-renewal is enabled and the billing card is current. An expired card has caused more outages than any cyberattack.
• ✓ Periodically run a WHOIS lookup on your own domain to confirm registrant, nameservers, and expiry haven't changed without authorization.

Your authoritative DNS publishes the ground truth for your domain. Stale or misconfigured records are the entry point for subdomain takeover, MX-record spoofing, and certificate misissuance.

• ✓ Inventory every published record with our DNS Lookup tool — A, AAAA, CNAME, MX, NS, TXT, SOA — and document the business owner of each.
• ✓ Delete CNAMEs pointing to deprovisioned cloud resources (S3 buckets, Heroku apps, Azure endpoints). Dangling CNAMEs are the #1 cause of subdomain takeover.
• ✓ Add CAA records listing only the CAs you authorize to issue certificates (e.g. 0 issue "letsencrypt.org"). Browsers and CAs honor this; everyone else gets a hard refusal.
• ✓ Set TTLs intentionally: 300–3600 seconds for records that change, 86400+ for stable infrastructure. Lower TTLs before any planned cutover — see DNS propagation for timing.
• ✓ Avoid wildcard records (*.example.com) unless absolutely required — they catch typosquats and accidentally route nonexistent subdomains to live infrastructure.
• ✓ Confirm the NS records published in your zone match the delegation at the registrar; mismatches cause silent resolution failures.
• ✓ Use at least two geographically and operationally diverse authoritative nameservers (different ASNs) to survive provider outages — verify each with ASN Lookup.
• ✓ Increment the SOA serial number on every zone change and monitor for unexpected serial jumps as an unauthorized-change tripwire.

DNSSEC adds cryptographic signatures so resolvers can verify a DNS answer hasn't been tampered with in transit. Without it, on-path attackers can forge responses (the Kaminsky attack and its descendants).

• ✓ Sign the zone with DNSSEC at the authoritative DNS provider — most managed providers (Cloudflare, Route 53, NS1, Google Cloud DNS) make this a one-click operation.
• ✓ Publish the corresponding DS record at the registrar so the trust chain links back to the TLD. Verify with the DS field shown in DNS Lookup.
• ✓ Choose modern algorithms: ECDSA P-256 (algorithm 13) or Ed25519 (algorithm 15). Avoid RSA-SHA1 (algorithm 5/7) and other deprecated suites.
• ✓ Document the rotation schedule for KSK (Key Signing Key) and ZSK (Zone Signing Key). Automated rollover beats manual rollover every time.
• ✓ Monitor signature expiration — an expired RRSIG will make DNSSEC-validating resolvers return SERVFAIL and your domain effectively disappears.
• ✓ After enabling, validate end-to-end with dig +dnssec from a resolver that supports validation (1.1.1.1, 9.9.9.9).

Plain DNS over port 53 is fully readable to anyone on the network path — ISPs, public Wi-Fi operators, and middleboxes. Encrypted DNS hides queries from observers and prevents in-flight tampering.

• ✓ Configure DNS-over-HTTPS (DoH, RFC 8484) or DNS-over-TLS (DoT, RFC 7858) on every device — browsers, OS, mobile, routers — see DNS ports for the protocol mapping.
• ✓ Pick a privacy-respecting resolver: Cloudflare 1.1.1.1, Quad9 9.9.9.9 (malware filtering), NextDNS (customizable filtering), Mullvad DNS, or AdGuard DNS. The DNS server list includes endpoints for each.
• ✓ Disable plaintext UDP/53 fallback where the OS allows it; otherwise an attacker can downgrade by blocking port 853/443 and forcing your stack back to cleartext.
• ✓ Run a DNS leak test while connected to your VPN — Chrome/Firefox secure-DNS settings and IPv6 stacks frequently leak around tunnels.
• ✓ For mobile fleets and Android 9+, enable Private DNS (DoT) at the OS level so every app honors it, not just the browser.
• ✓ On Windows 11 and macOS Ventura+, configure encrypted DNS in Network settings instead of relying on app-level overrides.

Email is the most-spoofed channel in existence, and the entire defense lives in DNS. Without SPF, DKIM, and DMARC, anyone in the world can send mail "From: you@yourdomain.com" and the receiving server will deliver it.

• ✓ Publish a strict SPF record (v=spf1 include:_spf.yourprovider.com -all) listing every legitimate sender — and only those. Avoid +all, ?all, or more than 10 DNS lookups in the chain.
• ✓ Generate a unique DKIM keypair per sending service. Rotate keys at least annually and after any provider compromise.
• ✓ Deploy DMARC in three phases: start with p=none rua=mailto:... to gather reports, advance to p=quarantine pct=25, end at p=reject once aligned senders are confirmed.
• ✓ Enforce identifier alignment (both DKIM and SPF) — DMARC only validates if the authenticated domain matches the From: header.
• ✓ Publish MTA-STS and TLS-RPT records to require TLS between mail servers and receive reports on negotiation failures.
• ✓ Add a BIMI record + Verified Mark Certificate (VMC) so Gmail, Yahoo, and Apple Mail display your logo next to authenticated mail — a deliverability and brand signal.

Whether you run your own BIND/Unbound/Knot/PowerDNS or rely on a managed provider, the infrastructure layer must be locked down against transfer leaks, amplification abuse, and software vulnerabilities.

• ✓ Restrict zone transfers (AXFR/IXFR) to known secondary IPs only — allow-transfer { 192.0.2.10; }; in BIND, equivalent ACLs elsewhere. Open AXFR leaks every record in your zone.
• ✓ Enable Response Rate Limiting (RRL) on authoritative servers to make reflection/amplification DDoS far less effective against third parties.
• ✓ Never run an open recursive resolver on the public Internet — limit recursion to internal subnets only (validate with our Port Scanner against UDP/53 from outside).
• ✓ Use Anycast for authoritative DNS to distribute load and absorb DDoS — most managed DNS providers ship this by default.
• ✓ Patch DNS software promptly. BIND, Unbound, Knot, and PowerDNS all publish CVEs regularly; subscribe to their security mailing lists.
• ✓ Audit reverse DNS / PTR records with our Reverse DNS Lookup — missing or mismatched PTR for outbound mail relays directly causes deliverability problems.

A locked-down zone today is a misconfigured zone tomorrow if no one watches it. Monitoring closes the gap between "we set it up correctly" and "we still have it set up correctly."

• ✓ Schedule weekly automated audits against a known-good baseline using DNS Lookup or a dig script in CI; alert on any diff.
• ✓ Track domain expiration and registrar changes monthly via WHOIS Lookup — losing the domain is the worst DNS outage possible.
• ✓ Monitor the hosting and ASN behind every record with IP WHOIS Lookup; unexpected provider changes are an exfiltration tell.
• ✓ Set SSL/TLS expiration alarms 30 / 14 / 3 days out with our SSL Checker — a healthy DNS record pointing at an expired cert is still a broken site.
• ✓ Log all DNS queries at the resolver where legally and ethically appropriate; queries are a high-signal source for compromise detection (C2 callbacks, DGA traffic).
• ✓ Trace reachability and path with Trace Route and Ping when a record resolves but the service is unreachable.

When something goes wrong — and it will — the time to write the runbook is now, not at 3am during the incident.

• ✓ Maintain offline backups of every zone file (one per provider, signed and timestamped). A registrar takeover is unrecoverable without a clean copy.
• ✓ Practice DNS failover quarterly: swap to a secondary provider in a staging window and confirm TTLs and propagation behave as expected.
• ✓ Write a cache-flush runbook for desktop, mobile, router, and major OS — start with our Flush DNS guide.
• ✓ Document the diagnostic sequence for the most common user-facing failure: see DNS Server Not Responding for the standard playbook.
• ✓ Keep up-to-date emergency contacts for your registrar, your authoritative DNS provider, and the TLD operator. Have the customer-ID numbers ready.