DNS is the one layer of your infrastructure that can silently break everything else. Get it wrong and your website goes offline, your email bounces, and your SSL certificates fail to renew — all at once, all because of a single misconfigured record or an expired domain. Most website owners treat DNS as a one-time setup task and never revisit it. That is exactly how disasters happen. The twelve rules below cover what experienced network engineers actually do to keep DNS running cleanly, securely, and predictably for years at a time.
Rule 1: Use at Least Two Authoritative Name Servers on Different Networks
Every domain should have a minimum of two authoritative name servers, and those servers must sit on separate networks and ideally separate geographic locations. If both name servers share the same data center and that facility loses power or network connectivity, your domain becomes completely unresolvable. Most managed DNS providers handle this automatically, but if you are running your own BIND or PowerDNS setup, confirm your secondary is not on the same /24 subnet as your primary. ICANN and RFC 1034 both require at least two name servers for this exact reason.
Rule 2: Set TTLs Deliberately, Not by Default
Time-to-live values control how long resolvers cache your DNS records. The wrong TTL in the wrong situation costs you hours of downtime. The standard approach used by experienced engineers is:
- Normal operations: Set A, AAAA, and CNAME records to 3600 seconds (1 hour). This balances caching efficiency against flexibility.
- Before a planned change (migration, IP swap): Drop the TTL to 300 seconds (5 minutes) at least 48 hours before the change. That way the old value has already expired from resolver caches before you flip the record.
- After the change is stable: Raise the TTL back to 3600 or higher.
- MX and NS records: Keep these at 3600 to 86400. They rarely change and high TTLs reduce query load.
Never leave TTLs at provider defaults without checking them. Some registrars default to 14400 or even 86400, which means a botched record update lingers for an entire day.
Rule 3: Enable DNSSEC on Every Domain You Control
DNSSEC signs your DNS responses cryptographically so that resolvers can verify the data has not been tampered with in transit. Without it, an attacker performing cache poisoning can redirect your visitors to a malicious server and your users would have no way to know. Enabling DNSSEC requires generating a key signing key (KSK) and zone signing key (ZSK), signing your zone, and publishing a DS record at your registrar. Most major DNS providers — Cloudflare, Route 53, Google Cloud DNS — handle the signing automatically. You just need to copy the DS record value into your registrar's control panel.
After enabling DNSSEC, verify the chain of trust is intact. Use our DNS Lookup tool to query the DS and DNSKEY records for your domain and confirm they match.
Rule 4: Lock Your Domain at the Registrar
Domain hijacking is real and happens more often than it should. The attack vector is usually the registrar account, not the DNS provider. Enable every lock your registrar offers:
- Registrar Lock (Transfer Lock): Prevents unauthorized domain transfers to another registrar. Enable this unless you are actively transferring.
- Registry Lock: A higher-security lock available for critical domains. Requires manual intervention from the registry and your registrar to remove. Worth it for high-value domains.
- Two-factor authentication on the registrar account: Non-negotiable. Use an authenticator app, not SMS if possible.
Rule 5: Keep Your Registrar and DNS Provider Separate
When your domain registrar is also your DNS provider, a single account breach or billing lapse can take down both your domain registration and your DNS records simultaneously. Keeping them separate limits the blast radius. A common and reliable setup is to register the domain at a registrar like Namecheap or Gandi, then delegate DNS to Cloudflare or a dedicated DNS provider by pointing the NS records there. The registrar account only needs to be accessed when you renew or transfer — far less attack surface.
Rule 6: Audit Your DNS Records Every Quarter
DNS zones accumulate cruft over years. Old A records pointing at decommissioned servers, dangling CNAMEs pointing at subdomains that no longer exist on third-party platforms, forgotten TXT records from marketing tools nobody uses anymore — all of these are either security risks or simply misleading. A dangling CNAME pointing at an unclaimed Heroku or GitHub Pages subdomain can be hijacked by anyone who claims that subdomain on the platform.
Set a calendar reminder every three months to export your full zone file and review every record. Remove anything you cannot explain. If you use a managed DNS provider, most have an API or export function. For BIND-based setups:
This validates the zone file syntax and will catch obvious errors before they reach production.
Rule 7: Implement SPF, DKIM, and DMARC for Every Domain That Sends Email
Email authentication is configured entirely through DNS records and is one of the most commonly skipped steps. Without SPF, DKIM, and DMARC, anyone can send email that appears to come from your domain. This enables phishing attacks against your customers and damages your sender reputation.
- SPF: A TXT record on your root domain that lists which mail servers are authorized to send on your behalf.
- DKIM: A TXT record containing a public key that your mail server uses to sign outgoing messages. The receiving server verifies the signature.
- DMARC: A TXT record at _dmarc.yourdomain.com that tells receiving servers what to do when SPF or DKIM fails, and where to send reports.
Start your DMARC policy at p=none to collect reports without affecting deliverability, then graduate to p=quarantine and eventually p=reject once you have confirmed all your legitimate sending sources are covered.
Rule 8: Monitor DNS Resolution Continuously
You should not be the last person to find out your DNS is broken. Set up external monitoring that queries your authoritative name servers and critical records on a schedule — at minimum every five minutes. Tools like UptimeRobot, Datadog, or StatusCake support DNS monitoring. What to monitor:
- Your root A or AAAA record resolves to the expected IP
- Your MX records are present and return the correct priority and hostname
- Your name servers are authoritative and responding
- DNSSEC validation succeeds if enabled
Alert on any deviation. A DNS record that silently changes is almost always either a misconfiguration or a compromise.
Rule 9: Use a Low-Latency, Anycast DNS Provider for Public-Facing Domains
Self-hosted DNS on a single VM in one region means that visitors in Tokyo querying your name server in Frankfurt wait for a round-trip across half the planet before they even start loading your site. Anycast DNS providers route queries to the nearest point of presence automatically. Cloudflare, NS1, Amazon Route 53, and Google Cloud DNS all operate large anycast networks. The performance difference is measurable — often 50 to 200 milliseconds per page load just from faster DNS resolution. For a website with global traffic, this is not optional.
Rule 10: Never Use Your Production Domain for Testing
A common mistake is creating test records like test.yourdomain.com or dev.yourdomain.com that point at internal or unprotected servers and then forgetting about them. These subdomains are publicly resolvable and discoverable through certificate transparency logs and DNS enumeration tools. Anyone scanning your domain will find them. Use a completely separate domain for development and staging — something like yourcompany-staging.com — and keep it out of public DNS entirely where possible, or at minimum restrict access with authentication at the application layer.
Rule 11: Document Every DNS Change With a Reason and a Timestamp
When something breaks at 2 AM and you are trying to diagnose whether a recent DNS change caused it, the absence of documentation is crippling. Treat your DNS zone like infrastructure code. Maintain a changelog — even a simple text file or a shared spreadsheet — that records:
- Date and time of the change
- Who made it
- What record was changed, from what value, to what value
- Why it was changed
- The TTL at the time of the change
Better yet, store your zone files in a Git repository. Every commit becomes an auditable record of exactly what changed and when. If you use Terraform or Pulumi to manage your DNS provider, your records are automatically version-controlled and reviewable through pull requests before any change goes live.
Rule 12: Plan for DNS Failover Before You Need It
DNS-based failover routes traffic away from a failed server automatically by changing which IP a hostname resolves to. Most enterprise DNS providers support health-check-based failover out of the box. Route 53 calls it routing policies with health checks. Cloudflare handles it through Load Balancers. Even if your site runs on a single server today, planning your failover architecture now means you can execute it under pressure when the server actually fails — instead of figuring it out while the site is down.
A minimal failover setup looks like this:
- Create a secondary server or a static maintenance page on a CDN like Cloudflare Pages or Netlify
- Configure a health check against your primary server's IP on port 80 or 443
- Set the DNS provider to automatically switch the A record to the backup IP if the primary health check fails
- Test the failover by intentionally blocking the health check and confirming the record flips within the expected time window
Combined with a low TTL (300 seconds) on your A record, DNS failover can restore basic availability within minutes of a server failure rather than hours.
Putting It All Together
None of these rules require enterprise budgets or a dedicated network team. Most of them require thirty minutes of careful configuration done once, followed by brief quarterly reviews. The domains that go down for hours during a crisis are almost always the ones where nobody thought about DNS until something broke. Implement these twelve practices now — before your registrar account gets phished, before your CNAME gets hijacked, before your IP changes with a 24-hour TTL still in place — and you will have a DNS setup that survives the kind of events that regularly bring other sites to their knees.