What your board doesn’t know about DNS could cost them their seats
Picture a board meeting. The CISO is presenting the annual security budget. Firewalls, endpoint detection, a 24/7 SOC, penetration testing, cyber insurance. The numbers add up to seven figures. The board nods approvingly.
Nobody asks about the $12/year domain name holding it all together.
This is the blind spot I’ve watched organizations stumble into for over 25 years. They’ll spend hundreds of thousands on redundancy, high availability, and disaster recovery. Meanwhile, their entire digital presence hangs on a couple of nameservers managed by whoever offered the cheapest domain registration.
According to the Cybersecurity and Infrastructure Security Agency (CISA), over 90% of successful cyberattacks involve DNS at some stage [1]. That statistic alone should earn DNS a permanent seat at the security table. Instead, it gets treated like office furniture.
You know your board will eventually ask about DNS security. Here are the answers for when they do.
This checklist gives you those answers.
Why Boards Are Starting to Pay Attention
Three forces are pushing DNS security onto the board agenda.
The regulatory environment has shifted.
The SEC’s 2023 cybersecurity disclosure rules require companies to report material incidents and describe their risk management processes [2]. The EU’s Digital Operational Resilience Act (DORA) explicitly includes DNS infrastructure in its scope [3]. Insurance carriers are asking pointed questions about DNS during renewals. “We don’t manage that internally” is no longer an acceptable answer.
High-profile incidents are making headlines.
The AWS Route53 outage in October 2025 lasted 14 hours and affected over 16 million users [4]. The Squarespace migration debacle compromised multiple DeFi platforms when 2FA was disabled system-wide during the acquisition process [5]. These are front-page news board members read over breakfast.
Personal liability is on the table.
The SolarWinds case established that executives can face individual SEC charges for inadequate cyber oversight [6]. “We didn’t know” is not a defense when the threat was foreseeable and the controls were available.
The board conversation about DNS is coming. Here’s how to be ready for it.
The DNS Security Audit Checklist
I’ve organized this into five categories. Each item is a yes-or-no question. If you can’t answer “yes” with confidence, you’ve found a gap that needs closing.
Domain Registration Security
1. Do you have an accurate, complete inventory of all domains your organization owns or controls?
Shadow IT is real. Acquisitions leave orphaned domains. Departed employees registered domains for projects that never launched. Marketing bought a dozen variations for a campaign three years ago.
Good looks like: a centralized registry, audited quarterly, with clear ownership assigned to each domain.
2. Are registry locks enabled on your mission-critical domains?
A registry lock prevents unauthorized transfers at the TLD registry level. This is distinct from a registrar lock, which only prevents transfers at your registrar. Registry locks require multi-step authentication (often including verbal confirmation) to modify nameserver delegations.
Good looks like: registry locks on your primary domains, with a documented process for making authorized changes.
3. Is multi-factor authentication enabled on all registrar accounts?
The Squarespace vulnerability that compromised multiple DeFi platforms in 2024 was possible because 2FA was disabled system-wide as part of the Google acquisition [5]. App-based authentication (Google Authenticator, Authy) is the minimum. Hardware tokens are better for critical domains.
Good looks like: hardware tokens for critical domain accounts, app-based MFA everywhere else, and a policy prohibiting SMS-only authentication.
4. Do you know who at your registrar can make changes to your domains, and who at your organization can authorize those changes?
Social engineering attacks don’t hack systems. They hack processes. An attacker who knows your registrar’s procedures and can impersonate an authorized contact has everything they need.
Good looks like: named contacts at both ends, verbal confirmation protocols, and a documented authorization chain that gets reviewed when personnel change.
5. When did you last verify your Whois/RDAP contact information is accurate?
ICANN’s WHOIS Accuracy Program can suspend domains with outdated or inaccurate data [7]. More practically, if your contact information is wrong, you won’t receive legitimate notifications about expiration, disputes, or security issues.
Good looks like: quarterly verification, role-based email addresses (not personal accounts), and current phone numbers for verbal confirmations.
DNS Infrastructure Resilience
6. Do you use multiple DNS providers with independent infrastructure?
Every provider is a single point of failure. Cloudflare has had multiple large-scale outages caused by internal failures like routing table corruption [8]. AWS Route53 took down countless services during its October 2025 incident. If your DNS runs on one provider, your uptime is capped by their uptime.
Good looks like: at least two DNS providers with different anycast networks and different geographic footprints.
7. Is DNSSEC enabled and automatically managed on your domains?
DNSSEC provides cryptographic authentication of DNS responses, preventing cache poisoning and spoofed answers. The specification has been around for decades, but it remains underutilized because manual key management is error-prone.
Good looks like: DNSSEC enabled with automated key rollover. Manual key management will eventually fail. Set it and forget it is the only approach that works long-term.
8. What is your DNS provider’s uptime SLA, and have you verified their historical performance?
“100% uptime” in marketing materials means nothing. Actual performance is measurable through third-party monitoring.
Good looks like: a 99.99% or better SLA with financial penalties, plus independent monitoring data showing they actually meet it.
9. Do you have a tested failover plan if your primary DNS provider goes down?
The AWS outage lasted 14 hours. Most businesses cannot survive that kind of downtime. A failover plan that hasn’t been tested is just a document.
Good looks like: pre-configured secondary providers, automated or rapid-manual failover capability, and quarterly testing.
10. Are your DNS zones backed up independently of your provider?
Provider failures, account lockouts, billing disputes, and terminated relationships all happen. If your zone data exists only in your provider’s systems, you’re one bad day away from starting over.
Good looks like: automated zone exports stored in separate infrastructure, with tested restore procedures.
Threat Intelligence and Monitoring
11. Do you monitor for lookalike domains targeting your brand?
Phishing domains go live in minutes. Your users don’t carefully inspect URLs before clicking. By the time you discover an impersonation site through customer complaints, the damage is done.
Good looks like: continuous monitoring for new domain registrations similar to yours, automated alerting, and established takedown procedures.
12. Are you subscribed to threat intelligence feeds that flag malicious domains before they reach your users?
Real-time blocklists (RBLs) and Response Policy Zones (RPZs) can block threats at the DNS layer, before they ever reach endpoints. This is defense at the infrastructure level, not the device level.
Good looks like: RBL/RPZ integration with your recursive resolvers, real-time updates, and (if you operate in digital assets) crypto-specific threat feeds.
13. Do you receive real-time alerts for DNS changes, Whois modifications, and login events?
Early detection matters. Many successful hijacking operations involve multiple steps. Awareness at the early stages can often stop an attack before it succeeds.
Good looks like: multi-channel alerts (not just email, which can be intercepted if the inbox is compromised), integrated with your SOC workflows.
14. Have you implemented CAA records to control which certificate authorities can issue certificates for your domains?
Certificate Authority Authorization (CAA) records specify which CAs are permitted to issue certificates for your domain. Without them, any CA can issue a certificate, and attackers have used this to obtain fraudulent certificates for impersonation attacks.
Good looks like: CAA records published for all domains, with monitoring for unauthorized certificate issuance.
Email Authentication
15. Are SPF, DKIM, and DMARC properly configured, with DMARC in enforcement mode?
Business Email Compromise costs organizations $2.7 billion annually according to the FBI [9]. SPF, DKIM, and DMARC are the technical controls that prevent attackers from spoofing your domain in email.
Good looks like: DMARC policy set to p=reject or p=quarantine. A policy of p=none means you’re monitoring but not protecting.
16. Do you monitor DMARC reports for unauthorized use of your domain?
DMARC generates reports showing who is sending email claiming to be from your domain. Legitimate senders (your marketing platform, your CRM) should appear. Unknown senders are either misconfigurations or attackers.
Good looks like: aggregated DMARC reporting with anomaly alerts and quarterly reviews.
17. Are your email authentication records surviving after migrations and DNS changes?
SPF, DKIM, and DMARC records get accidentally deleted during DNS migrations. The result is email deliverability problems that can take days to diagnose.
Good looks like: pre-migration audits that inventory all TXT records, post-migration verification, and ongoing monitoring.
Governance and Documentation
18. Is there a documented DNS change management process with appropriate approvals?
Unauthorized or accidental DNS changes cause outages. A developer testing something in production, an admin fat-fingering a TTL, a vendor making changes without notification.
Good looks like: change requests, approval workflows, and rollback procedures that actually get followed.
19. Do you have a DNS incident response playbook, and has it been tested?
When your DNS is down, you need a plan, not a meeting to create one. Panic is not a strategy.
Good looks like: documented escalation paths, current contact lists for all relevant vendors and personnel, recovery procedures, and tabletop exercises at least annually.
20. Can you produce a DNS security posture report for your board within 24 hours?
When the board asks, and they will, you need answers.
Good looks like: dashboards showing current status, automated reporting on key metrics, and executive summaries that translate technical findings into business risk.
Translating for the Boardroom
Technical accuracy matters, but boards don’t speak DNS. Here’s how to translate:
| What You Know | What the Board Needs to Hear |
|---|---|
| DNS is a single point of failure | Our entire online presence depends on infrastructure we don’t fully control |
| We don’t have registry locks | An attacker could transfer our domain with a forged email |
| Our DNS provider had 99.9% uptime | We were offline for 8.7 hours last year due to DNS alone |
| DNSSEC isn’t enabled | Attackers could redirect our customers to fake sites without detection |
| We use one DNS provider | When that provider goes down, we go down with them |
The conversation should focus on three points. First, DNS security is infrastructure security. It deserves the same attention as data centers and network architecture. Second, the cost of hardening DNS is trivial compared to the cost of an incident. Third, this is a governance issue, not just a technical issue. Regulatory requirements and insurance questionnaires are making that explicit.
The Uncomfortable Part
Most organizations fail at least half of this checklist. I don’t say that to be harsh. I say it because I’ve spent 25 years watching it happen.
The gap exists because DNS has been treated as a commodity. The mentality is that domain registration should be cheap and DNS should just work. That’s fine until it doesn’t work, and then it’s catastrophic.
The companies that take DNS security seriously tend to be the ones that learned the hard way. A hijack, an outage, a near-miss that scared someone enough to demand changes. You don’t want to be that company.
Your board doesn’t need to understand DNSSEC key rollovers or anycast routing. They need to know that you do, and that you’ve got it handled. This checklist gives you the framework to prove it.
The board meeting where they ask about DNS is coming. With this checklist, your answers will become part of the solution.
References
[1] Cybersecurity and Infrastructure Security Agency (CISA), “DNS Security Best Practices,” https://www.cisa.gov/dns-security
[2] U.S. Securities and Exchange Commission, “SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies,” July 2023, https://www.sec.gov/news/press-release/2023-139
[3] European Commission, “Digital Operational Resilience Act (DORA),” Regulation (EU) 2022/2554
[4] Amazon Web Services, “Summary of the October 19, 2025 AWS DNS Event in the US-EAST-1 Region”
[5] Squarespace/Google Domains Migration Security Incident, July 2024, documented in multiple security advisories including reports from affected DeFi platforms
[6] U.S. Securities and Exchange Commission, “SEC Charges SolarWinds and Chief Information Security Officer with Fraud, Internal Control Failures,” October 2023
[7] ICANN, “WHOIS Accuracy Program Specification,” https://www.icann.org/resources/pages/whois-accuracy-program
[8] Cloudflare Incident Reports, multiple outages documented at https://www.cloudflarestatus.com/
[9] Federal Bureau of Investigation, “Business Email Compromise: The $50 Billion Scam,” Internet Crime Complaint Center (IC3), 2023 Report
Apply for a Domainsure Invite
Get a Free Domain Health Check
Due to high demand: allow up to 24 hours for report delivery.
