Global DNSSEC Rate
5.2%
Domains with DNSSEC
13,429,484
Domains without DNSSEC
244,949,796
| TLD | Domains | DNSSEC % |
|---|
DNSSEC (DNS Security Extensions) is a suite of specifications defined in RFC 4033, RFC 4034, and RFC 4035 that add cryptographic authentication to DNS responses. When DNSSEC is enabled, every DNS response includes digital signatures that allow resolvers to verify the response hasn’t been tampered with in transit. Without DNSSEC, DNS responses are unauthenticated — a resolver has no way to confirm that the IP address it received actually came from the domain’s authoritative nameserver.
This lack of authentication enables cache poisoning attacks (also known as Kaminsky attacks, after Dan Kaminsky’s 2008 disclosure). In a cache poisoning attack, an attacker injects forged DNS responses into a resolver’s cache, redirecting users to attacker-controlled servers. Mitigations described in RFC 5452 (source port randomization) reduce the attack surface but do not eliminate it — only DNSSEC provides cryptographic proof of DNS response authenticity.
Despite being standardized since 2005, DNSSEC adoption remains low across most gTLDs. DNSChkr tracks DNSSEC adoption by checking for DS (Delegation Signer) records in zone files — the presence of a DS record indicates that the domain has DNSSEC enabled and the parent zone has a trust anchor for validation.
DNSSEC adoption is measured by checking for DS (Delegation Signer) records in gTLD zone files. A DS record in a zone file indicates that the domain owner has configured DNSSEC signing at their DNS provider and the registry has published the trust anchor. DNSChkr counts DS records per TLD and computes adoption rates as a percentage of total domains in each zone.
The analysis distinguishes between TLDs with high DNSSEC adoption (often driven by registry policies or ccTLD mandates) and those with low adoption (typically gTLDs where DNSSEC is optional). Global adoption is computed across all domains in the dataset to provide an aggregate view of DNSSEC deployment in the gTLD namespace.
| .bank | 2,383 | 100.00% |
| .insurance | 160 | 100.00% |
| .crs | 562 | 95.73% |
| .sbi | 119 | 93.28% |
| .fox | 300 | 68.33% |
| .garden | 46,021 | 62.33% |
| .se | 1,414,566 | 60.36% |
| .nu | 197,313 | 56.59% |
| .ch | 2,582,495 | 52.95% |
| .gent | 3,761 | 46.34% |
| .ovh | 86,978 | 37.72% |
| .frl | 10,153 | 35.26% |
| .christmas | 11,774 | 34.44% |
| .page | 37,208 | 34.23% |
| .li | 70,655 | 32.40% |
| .coupons | 7,477 | 31.86% |
| .surf | 12,104 | 31.71% |
| .corsica | 2,356 | 30.98% |
| .vlaanderen | 5,240 | 28.91% |
| .esq | 2,289 | 27.57% |
| TLD | Domains | DNSSEC % |
|---|---|---|
| .企业 (.xn--vhquv) | 2,798 | 0.00% |
| .kred | 1,646 | 0.00% |
| .kyoto | 986 | 0.00% |
| .cn | 852 | 0.00% |
| .lundbeck | 272 | 0.00% |
| .toyota | 249 | 0.00% |
| .weir | 191 | 0.00% |
| .cc | 181 | 0.00% |
| .中信 (.xn--fiq64b) | 170 | 0.00% |
| .citic | 157 | 0.00% |
| .餐厅 (.xn--imr513n) | 149 | 0.00% |
| .com.cn | 130 | 0.00% |
| .gmo | 120 | 0.00% |
| .protection | 102 | 0.00% |
| .在线 (.xn--3ds443g) | 35,110 | 0.01% |
| .realtor | 28,341 | 0.01% |
| .公司 (.xn--55qx5d) | 21,515 | 0.01% |
| .рус (.xn--p1acf) | 19,114 | 0.01% |
| .网络 (.xn--io0a7i) | 15,707 | 0.01% |
| .dvag | 9,135 | 0.01% |
A cache poisoning attack (Kaminsky attack) involves an attacker injecting forged DNS responses into a resolver’s cache. When successful, the resolver serves the forged response to all users, redirecting them to attacker-controlled servers. This can be used for phishing, malware distribution, or traffic interception — all without any visible change to the domain name in the user’s browser.
DNSSEC adoption remains low due to several factors: added complexity in DNS management, risk of making a domain unreachable if misconfigured, lack of visible user-facing benefit (no browser indicator), registrar/provider support gaps, and the perception that source port randomization (RFC 5452) is sufficient protection. However, source port randomization only raises the bar for attacks — it does not provide cryptographic proof of authenticity.
Yes, misconfigured DNSSEC can make your domain unreachable to validating resolvers (which include all major public resolvers like Google 8.8.8.8 and Cloudflare 1.1.1.1). Common issues include expired RRSIG signatures, mismatched DS records after provider migrations, and failed key rollovers. This is why monitoring DNSSEC validation status is critical.
A DS (Delegation Signer) record is published in the parent zone (e.g., the .com zone for a .com domain) and creates a chain of trust between the parent and child zone. It contains a hash of the child zone’s DNSKEY, allowing resolvers to verify that the child zone’s DNSSEC signatures are authentic. Without a DS record in the parent zone, DNSSEC validation cannot occur.