Defaults.Exposed › Reports

The DNS Landlords: How GoDaddy and Cloudflare Control Nameservers for 94 Million Domains

Published 2026-08-20

Figures as of 2026-08-16, methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: two companies answer DNS for one in four domains on the internet

Across the 376,928,750 domains graded in our August 2026 census, 52,445,186 delegate their DNS to GoDaddy’s domaincontrol.com nameservers and a further 42,255,941 delegate to Cloudflare’s ns.cloudflare.com nameservers. Combined: approximately 94.7 million domains, 25.1% of the entire graded population, resolve through one of two providers.

That figure warrants stopping on. DNS is the naming layer of the internet. Before a browser loads a page, before a mail server routes a message, before a payment processor validates a webhook, a resolver has to ask a nameserver: where is this domain? For one in four domains, that question ends up at GoDaddy or Cloudflare. If either organisation has a sustained availability incident, a successful attack on its authoritative infrastructure, or a BGP routing failure that blackholes its address space, the DNS failure is not their customers’ problem. It is the internet’s problem.

This report covers what the August 2026 census found, why the two providers got to these numbers through very different routes, what the concentration means for systemic risk, and what IT teams should know when choosing or auditing a nameserver provider.

Key numbers

GoDaddy at 52 million: the registration artifact

GoDaddy’s 52.4 million is not, in the main, a product story. It is a default story.

When a registrant buys a domain at GoDaddy and does nothing else, the domain’s NS records point to ns09.domaincontrol.com and ns10.domaincontrol.com (the specific pair varies; all sit within the domaincontrol.com zone). The registrant never chose GoDaddy’s DNS. They chose GoDaddy as a registrar, and the DNS came with the registration the way a free webmail address used to come with a broadband subscription. Most of those 52 million registrants have never touched their NS records.

This matters because it means the population is not self-selected for any technical interest in DNS management. It is self-selected for having bought a domain from the world’s largest registrar and not having subsequently migrated. The inference is that most of those 52 million domains have been sitting on domaincontrol.com since registration, which means their DNS configuration reflects whatever GoDaddy’s default provisioning provided at the time of purchase, not any active choice the registrant made.

GoDaddy’s authoritative DNS infrastructure is a large, mature, high-availability service. But “large and mature” carries two-sided implications. Legacy scale means legacy architecture. GoDaddy’s authoritative DNS does not enable DNSSEC signing for registrant zones by default, and while GoDaddy offers DNSSEC for domains it registers, the process requires active operator involvement. The gap between “DNSSEC-capable infrastructure” and “DNSSEC-signed zones” is exactly the kind of gap that fills up with 52 million domains where nobody noticed.

The security incident record is also relevant context. In January 2023, GoDaddy disclosed a multi-year breach affecting its cPanel shared hosting environment, in which attackers had intermittent access beginning in 2020. The breach exposed source code and installed malware on GoDaddy’s hosting network. That was a hosting infrastructure incident, not a nameserver incident, and domaincontrol.com nameserver integrity was not confirmed as compromised. But an organisation running DNS infrastructure of this scale carries a commensurate target on its back. The 2023 disclosure was GoDaddy’s third major security incident in three years. The concentration of 52 million domains on a single provider’s nameservers means the potential blast radius of any future nameserver-layer compromise is substantial.

GoDaddy is a signatory to ICANN’s Registrar Accreditation Agreement (RAA), which sets baseline obligations for registrar conduct and data accuracy but does not mandate specific DNS security configurations. The gap between RAA obligations and a production-ready DNSSEC deployment is entirely the registrant’s to close.

Cloudflare at 42 million: the deliberate adoption story

Cloudflare’s 42.3 million is a different kind of number. It reflects product adoption, not registration default.

Cloudflare offers authoritative DNS as a free, standalone service: a registrant at any other registrar can point their NS records to Cloudflare without registering through Cloudflare’s own registrar. Millions have. The combination of a generous free tier, Cloudflare’s well-known CDN and DDoS protection, and strong word-of-mouth in engineering and operations communities has made Cloudflare’s DNS the most actively-chosen DNS provider in our census dataset.

The population profile differs from GoDaddy’s in a consequential way. A domain on Cloudflare’s DNS almost certainly got there because somebody made a deliberate configuration change. That self-selection means Cloudflare’s 42 million skews toward technically engaged operators: people who know what a nameserver record is, who had a reason to move, and who went through the steps to do it. It also means those domains are more likely to have touched other DNS configuration settings while they were at it.

DNSSEC is where the difference becomes measurable. Cloudflare’s authoritative DNS platform enables DNSSEC signing for customer zones with a single toggle in its dashboard. The DS record required to chain trust from the parent zone is provided as a copy-paste value. The flow is designed to make DNSSEC the path of least resistance, not the advanced option. GoDaddy’s DNS management interface requires more steps, and for the majority of the 52 million domains that have never logged into DNS settings at all, DNSSEC signing will never happen.

DNSSEC, defined by RFC 4033 through RFC 4035, creates a cryptographic chain of trust from the DNS root through TLD registries to individual zones. It does not encrypt DNS responses, but it allows a resolver to verify that a response was signed by the authoritative source and has not been tampered with in transit. Effective deployment requires both the DNS provider to support zone signing and the parent registry to accept and publish the DS (Delegation Signer) record. Cloudflare’s platform reduces the provider-side friction to near zero. The registry-side step still requires the registrant to act, but Cloudflare surfaces it at the same point in the setup flow.

Cloudflare’s DNS also distinguishes between two modes that registrants sometimes conflate: authoritative DNS only (NS delegation to Cloudflare, no proxying) and the “orange-cloud” proxied mode where Cloudflare sits in the HTTP path and hides origin IP addresses. The census NS records reveal only the delegation, not whether proxying is active. The 42.3 million domains delegated to Cloudflare’s nameservers include both populations. The security implications of each differ: proxied domains get Cloudflare’s DDoS mitigation and WAF in the HTTP layer; DNS-only domains get Cloudflare’s nameserver infrastructure but their origin addresses remain publicly resolvable.

The systemic concentration risk

Neither provider needs to do anything wrong for concentration at this scale to become a systemic problem.

The 2016 Dyn incident is the reference point most DNS engineers reach for. A volumetric DDoS attack against Dyn’s resolver infrastructure disrupted DNS resolution for large portions of the internet, taking down major sites including Twitter, Reddit, and Amazon for hours. Dyn was a DNS resolver, not an authoritative nameserver provider, so the failure mechanism differed from what a GoDaddy or Cloudflare authoritative outage would look like. But the lesson is identical: DNS is infrastructure, not a commodity service, and concentration at any layer creates correlated failure risk.

An authoritative nameserver outage propagates differently from a resolver outage. Resolvers cache responses according to TTL values, so an authoritative provider going dark does not immediately affect all resolutions everywhere. Low TTLs (common on CDN and dynamic-content setups) drain cache quickly. High TTLs (common on dormant and low-maintenance domains) extend the grace period. In a sustained outage, domains with low TTLs fail first and hardest; domains with high TTLs degrade in slow motion as caches expire worldwide. After TTL expiry, any domain whose authoritative provider is unreachable becomes unresolvable. That means no email delivery, no website, no API, no certificate validation, no third-party verification — every service that depends on the name, simultaneously.

The BGP threat surface is specific and documented. Authoritative DNS providers operate globally distributed anycast infrastructure, announcing their nameserver addresses from multiple autonomous systems worldwide. BGP hijacking, in which a malicious or misconfigured AS announces more-specific prefixes to attract traffic intended for another operator, has been used in confirmed attacks against DNS infrastructure. A successful BGP hijack against a major authoritative provider’s anycast network would redirect DNS queries for that provider’s zones to attacker-controlled infrastructure. At GoDaddy’s or Cloudflare’s scale, the domain count in the affected population would be in the tens of millions.

Route Origin Authorizations (ROAs) and Resource Public Key Infrastructure (RPKI) validation reduce this risk by allowing operators to cryptographically assert which ASes are authorised to announce their prefixes, and allowing routers to reject invalid announcements. Cloudflare has been an active participant in RPKI deployment, both for its own network and as an advocate for adoption across the internet. GoDaddy’s public RPKI posture is less prominently documented. Neither eliminates the risk entirely, because RPKI adoption among transit providers is not universal.

The concentration risk extends beyond the two companies’ own customers. An organisation that does not use GoDaddy or Cloudflare for DNS still depends on the domains of its partners, vendors, certificate authorities, and upstream services. If a supplier’s payment portal is among the 52 million domains on domaincontrol.com and that infrastructure has an outage, the procurement team cannot reach the portal regardless of how well the buying organisation’s own DNS is managed. Concentration risk is not symmetric: you inherit the risk of your dependencies’ NS provider choices.

DNSSEC adoption across the NS provider landscape

DNSSEC deployment is uneven across the NS provider landscape, and NS provider choice is one of the largest single predictors of whether a domain is signed.

The mechanism is straightforward: a domain cannot have DNSSEC without a DNS provider that supports zone signing. For the 52.4 million domains on GoDaddy’s default nameservers, signing requires an active configuration step by an operator who, if they have never touched their DNS settings, may not know the option exists. For the 42.3 million domains on Cloudflare, the path to a signed zone is a dashboard toggle.

RFC 4033 defines the DNS Security Extensions architecture. RFC 4034 defines the resource record types (DNSKEY, RRSIG, NSEC, DS). RFC 4035 defines the validation protocol. Taken together, DNSSEC provides data origin authentication for DNS responses, protecting against cache poisoning attacks (of the type exploited by the Kaminsky vulnerability discovered in 2008) and reducing the effectiveness of on-path tampering. The protocol is widely implemented in resolvers: Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and the majority of ISP recursive resolvers perform DNSSEC validation. The deployment gap is on the authoritative side, in zones that have not been signed.

The DANE (DNS-based Authentication of Named Entities, RFC 6698) use case gives DNSSEC deployment a second motivation beyond query integrity. DANE allows a zone owner to publish certificate trust information in DNS, enabling applications to validate TLS certificates against DNS records rather than relying solely on the CA public key infrastructure. DANE requires DNSSEC. For organisations interested in reducing dependency on the CA PKI, NS provider support for DNSSEC is a prerequisite, not an optional extra.

What IT teams need to know

If your organisation’s domains sit on a major provider’s default nameservers and you have not reviewed the configuration, you are carrying risk that predates your current threat model.

The questions to answer are:

Who actually holds your NS delegation? Run dig NS yourdomain.com or query an online DNS resolver. If the answer is domaincontrol.com and you have not actively chosen GoDaddy DNS, you are on the registration default. If the answer surprises anyone in the room, the DNS configuration has been unmanaged.

Is DNSSEC signing active? Check whether a DNSKEY record exists at your zone apex and whether the parent zone publishes a DS record. Tools including Verisign’s DNSSEC debugger and DNSViz provide a visual chain-of-trust audit. An unsigned zone is not a configuration error in isolation, but it is a posture choice that should be made consciously rather than by omission.

What is your provider’s stated SLA and incident history? Large providers publish status pages and post-incident reports. Read them. The relevant question is not whether the provider has had incidents (all large infrastructure operators have) but whether their incident response, communication, and remediation patterns match what your risk posture requires.

Is your NS provider also your registrar? Co-locating registration and DNS at the same provider creates a single point of control: an account compromise, a registrar-side incident, or an ICANN enforcement action against the registrar potentially affects both the delegation and the underlying zone data simultaneously. Separating the registrar from the authoritative DNS provider adds a layer of independence.

If you are not a GoDaddy or Cloudflare customer, have you audited your vendor DNS posture? For services where DNS availability directly affects your operations — payment processors, SaaS tools, identity providers, CDNs — identifying which NS provider they use is a third-party risk assessment question as much as it is a technical one.

Assessing NS provider posture

For security teams conducting a DNS provider assessment, the criteria that matter most are: DNSSEC support and default enablement, RPKI participation, anycast footprint and AS diversity, incident transparency, and contractual SLA terms including notification obligations.

Cloudflare’s public commitments on all five are well-documented. GoDaddy operates infrastructure of comparable scale but with less public technical documentation on security architecture. Both carry concentration risk by virtue of scale: no single provider at 40+ million domains is a zero-risk choice from a systemic standpoint. Diversification across NS providers for different parts of an estate reduces correlated failure risk and limits blast radius in the event of a provider-level incident.

The August 2026 census establishes the baseline. One in four domains on the internet delegates DNS to two companies. That concentration is the product of market dynamics, registration defaults, and product adoption, not of any coordinated infrastructure strategy. The risk it creates is real whether or not the registrants involved are aware of it, and whether or not any incident ever materialises. Understanding that your name resolution depends on the health of other organisations’ infrastructure is the first step toward managing it.

What this means

For IT managers, the practical implication of DNS concentration at this scale is third-party risk management. If your organisation’s operations depend on suppliers, SaaS tools, payment processors, or identity providers, some of those vendors’ domains resolve through GoDaddy’s or Cloudflare’s infrastructure. That is not a reason to panic — both are large, well-resourced operators — but it is a reason to include DNS provider diversity in your supply chain risk assessments. A simultaneous outage affecting 25% of internet domains is not a theoretical scenario; it is the documented consequence of a successful attack or failure at provider scale, as the 2016 Dyn incident demonstrated for resolver infrastructure.

For security teams, the DNSSEC gap is the most actionable finding. Cloudflare’s default-enabling design has produced measurably better signing rates among its 42 million domains than GoDaddy’s more manual approach has among its 52 million. If your organisation’s domains sit on GoDaddy’s default nameservers and DNSSEC is not configured, it is almost certainly because nobody has logged in to configure it — not because there was a considered decision against signing. Treating DNSSEC signing as a default-off option that requires a ticket means it never gets done. Auditing your NS delegation and DNSSEC status takes under five minutes per domain.

For business owners and IT generalists, the most important takeaway is simpler: do you know who actually answers DNS for your domain, and did you choose them? If the answer to either part is “not sure,” running a quick NS lookup is the first step. Discovering that your domain has sat on a registration-default nameserver since purchase — and that you have never reviewed its configuration — is a common finding. The configuration may be fine. But it should be a decision, not an accident of onboarding.

Data to cite

• “GoDaddy and Cloudflare together hold authoritative DNS for approximately 94.7 million domains — 25.1% of the 376.9 million graded in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “52,445,186 domains delegate DNS to GoDaddy’s domaincontrol.com nameservers — 13.9% of the graded web — mostly via registration default, not active choice.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “42,255,941 domains delegate DNS to Cloudflare’s ns.cloudflare.com nameservers — 11.2% of the graded web — reflecting deliberate product adoption rather than default provisioning.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “For one in four domains on the internet, DNS resolution depends entirely on the health and availability of just two organisations.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Cloudflare enables DNSSEC via a single dashboard toggle; GoDaddy requires active operator involvement — a design difference that explains measurably different signing rates across 94 million combined domains.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Concentration risk is not symmetric: an organisation inherits the DNS provider risk of every vendor, supplier, and SaaS tool it depends on, regardless of its own NS choices.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

The August 2026 census establishes the baseline for DNS concentration, DNSSEC signing rates, and provider risk. Our domain check shows your NS delegation, DNSSEC status, and 32 other externally observable security checks — privately, free, in under a minute.

Check your domain free at defaults.exposed — find out who actually answers DNS for your domain, whether DNSSEC is signed, and whether your configuration reflects deliberate choices or inherited defaults. Takes 30 seconds. No account needed.

All census figures are drawn from the August 2026 defaults.exposed census (asOf: 2026-08-16, methodology v9), covering 376,928,750 graded domains. NS provider attribution is derived from NS record delegation targets observed during active DNS resolution at census time. References: RFC 1034 (Mockapetris, 1987), RFC 1035 (Mockapetris, 1987), RFC 2182 (Elz et al., 1997), RFC 4033 (Arends et al., 2005), RFC 4034 (Arends et al., 2005), RFC 4035 (Arends et al., 2005), RFC 6698 (Hoffman and Schlyter, 2012). ICANN Registrar Accreditation Agreement (2013, as amended). GoDaddy Inc., Security Incident Disclosure, January 2023. Dyn DDoS incident analysis, October 2016.

How to cite this report

Press / blog: defaults.exposed (2026). The DNS Landlords: How GoDaddy and Cloudflare Control Nameservers for 94 Million Domains. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/dns-landlords-godaddy-cloudflare-94-million-domains

Academic: defaults.exposed. (2026, August 20). The DNS Landlords: How GoDaddy and Cloudflare Control Nameservers for 94 Million Domains. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/dns-landlords-godaddy-cloudflare-94-million-domains

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Aggregate data only. Data stored and processed in the EU.