Skip to content
RU

DNSSEC in 2026: widely validated, almost never signed

TL;DR. As of 24 August 2026, APNIC data shows the resolvers used by Russian users validate DNSSEC signatures more often than the world average — 47.6% against 38.2%.

As of 24 August 2026, APNIC data shows the resolvers used by Russian users validate DNSSEC signatures more often than the world average — 47.6% against 38.2%. Yet in our own check of 27 August 2026, exactly one .ru domain in 126 was signed, against 8.8% for .com and 19.3% for .org.

Hence the asymmetry: DNSSEC protects a Russian user more often than average, while a Russian site protects its visitor least of all. Signing and validation are different things and should not be conflated.

Check your domain's DNS →

Two different things that keep getting confused

DNSSEC has two sides, and different numbers belong to each.

Signing is the domain owner’s job: the zone is signed and a DS record is published in the parent zone. Without it there is nothing to protect.

Validation is the resolver’s job — the ISP or public DNS the visitor happens to use. Without it nobody checks the signature.

The two cannot be mixed: a country can validate signatures widely and barely sign its own domains. That is exactly what we observe.

Validation: Russia runs above the world average

APNIC Labs measures the share of users whose resolver validates signatures, updated daily. As of 24 August 2026, 30-day window:

WhereValidatingPartialSample
Russia47.6%37.9%51,599
World38.2%594,884,345

Russian users get signature validation more often than the world average — by more than nine percentage points. That is the doing of ISPs and public resolvers, not of websites.

An important caveat about trends. The Russian figure swings year to year:

August202120222023202420252026
Validating32.0%60.6%45.2%33.8%59.5%47.6%

A two-fold spread. The reason lies in what is measured: users, not networks. When one large ISP switches validation on or off, the national share moves at once. Year-over-year "trends" on this series are meaningless — pick two points and you can show growth or decline at will.

Signing: one domain in a hundred and twenty-six

On 27 August 2026 we checked for a DS record on domains users had brought to our tools — a dig DS query against a public resolver, on the registrable name:

ZoneCheckedSignedShare
.org1352619.3%
.net1091110.1%
.com137128.8%
.ru12610.8%

Russian domains are signed roughly ten times less often than .com and twenty-four times less often than .org. In our sample exactly one domain of a hundred and twenty-six carries a signature.

Sampling caveat: these are domains somebody brought to our tools, not a random slice of the zone. Comparing zones to each other is sound — they were collected the same way — but the .ru level cannot stand in for "the Russian web". Not a single query failed, so "unsigned" here means an absent DS record rather than a failed lookup.

The asymmetry that follows

Put the two tables together. DNSSEC protects a Russian user more often than the average person on the planet. A Russian website protects its visitor less often than a site in any zone we compared.

The practical meaning: nearly half of Russian users reach the web through a resolver that will check a signature if one exists. For a domain owner that makes signing not a forward-looking gesture — the validating side is already in place and waiting.

And the converse: until the domain is signed, those 47.6% do nothing for it. There is nothing to check.

Why .ru signs so rarely

The data says how much, not why. Here we step past what was measured, so these are factors rather than a cause:

  • Registrar support. Signing requires the registrar to accept a DS record and pass it to the registry. Where the control panel offers no such field, the owner simply cannot finish the job.
  • The cost of a mistake is high and one-sided. A bad signature or a missed key rollover makes the domain unreachable for everyone who validates — in Russia, for nearly half the visitors. Not deploying DNSSEC never breaks anything.
  • Changing DNS hosting gets harder. Moving a signed zone needs a coordinated key change; without one the domain goes dark while the two sides disagree.
  • The benefit is invisible. Unlike a certificate, DNSSEC draws no padlock, affects no ranking and shows up in no analytics dashboard.

Check your own domain with the DNS lookup tool; what the records are and why each exists — what a domain is.

A / AAAAIPv4 and IPv6 host addresses
MX RecordsDomain mail servers
TXT / SPFVerification & anti-spoofing
NS / SOAName servers & zone authority

Why teams trust us

12
DNS record types
SPF+DKIM
email protection
<1s
DNS response
3
check regions

How it works

1

Enter domain

2

Select record type

3

Get DNS response

What are DNS Records?

DNS (Domain Name System) translates domain names into IP addresses. DNS records are instructions that define where to route traffic, email, and how to verify domainownership.

Complete Lookup

Query all record types — A, AAAA, MX, NS, TXT, CNAME, SOA — in a single request.

Instant Results

Direct queries to authoritative servers. Results in milliseconds, no caching.

Security Checks

SPF, DKIM, and DMARC analysis to evaluate email protection against spoofing and phishing.

Export & History

Save check results. Compare DNS records before and after registrar changes.

Who uses this

DevOps

DNS check after deploy

Email marketers

SPF/DKIM/DMARC audit

SEO

DNS config audit

Sysadmins

DNS zone control

Common Mistakes

Missing SPF recordWithout SPF, emails may land in spam. Add a v=spf1 TXT record.
Single NS serverIf the only NS fails, the domain becomes unreachable. Use at least 2 NS servers.
CNAME conflicting with other recordsCNAME cannot coexist with MX or TXT on the same name — this violates RFC.
TTL set too highWith 86400s TTL, DNS changes take a full day. Lower TTL to 300 before migrations.
Missing PTR recordMail servers check PTR. Without it, emails may be rejected.

Best Practices

Set up SPF + DKIM + DMARCThe trio of records that protects your email from spoofing and improves deliverability.
Use 2+ NS serversDistribute NS servers across different networks for redundancy.
Lower TTL before migrationSet TTL to 300 at least 24-48 hours before an IP change for fast propagation.
Verify DNS after changesAfter updating records, confirm changes propagated correctly and no errors remain.
Add a CAA recordCAA restricts which Certificate Authorities can issue SSL certificates for your domain.

Get more with a free account

DNS check history, API keys and DNS change monitoring.

Sign up free

Learn more

Frequently Asked Questions

Why is Runet DNSSEC adoption below global average?

Three factors: (1) registrars (REG.RU, Timeweb) charge 500-2000₽/year for DNSSEC instead of offering it free; (2) FSB requires GOST R 34.10-2012, and most DNSKEY clients do not validate it — incompatible; (3) mass Bitrix hosting has no UI for DS updates.

.cz has 52% DNSSEC — how?

The Czech registry CZ.NIC has been offering DNSSEC free and automatic since 2010. It is enabled by default at domain registration.

How do I check DNSSEC for my domain?

Enterno DNS Checker shows DNSKEY/DS/RRSIG and validation status. Or at the terminal: dig +dnssec +trace example.ru.

What breaks on a bad key rollover?

The domain becomes unresolvable for validating resolvers (1.1.1.1, 9.9.9.9) — clients get SERVFAIL. That is 25-40% of traffic for large sites. Fixed by committing the new DS to the TLD via your registrar.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.