Status: resolved at 03:45 UTC (10:45 +07), 22 Oct 2026. Resolution update: VNNIC began publishing a corrected zone (serial 2031364721, with KSK 16196 and the NSEC3 chain back) at 03:32 UTC. It did not reach the servers at once: b, c, f and h first, then g, a and d, and e last at 03:45 UTC. For those 13 minutes, a resolver that happened to query a lagging server still got a bogus answer. The broken zone was served for about 1 h 50 min (01:55–03:45 UTC). How long users were actually affected was shorter and varied by resolver, because it depended on caches.
Summary
On the morning of 22 October 2026, sites under .vn became unreachable for anyone behind a validating
resolver: Google Public DNS, Cloudflare 1.1.1.1 and Quad9. APNIC measures roughly 45% of Vietnamese
users behind validating resolvers, plus most international users. The fault is in the vn. zone
itself: it was re-signed at about 01:55 UTC, and afterwards the KSK the root's DS points at was no
longer published.
What broke
Measured on all eight a…h.dns-servers.vn servers, over UDP and TCP, from Vietnam, Singapore and Europe:
the root's DS for vn. names key tag 16196; the vn. DNSKEY set contains only the ZSK, 52956,
signed only by itself; NSEC3PARAM vn. is empty, and DS queries for delegated names return NODATA with
no NSEC/NSEC3 proof. Validators see vn. as bogus — Google reports
Invalid denial of existence of <name>/ds, Cloudflare EDE(10): RRSIGs Missing … vn. SOA. The pattern
matches a failed key rollover.
Why it looked like "only my site"
At 10:20 most large .vn sites still resolved; smaller ones failed. Resolvers keep answers validated before
the break until their TTL expires. High-traffic, long-TTL names survive on cache; short-TTL or rarely
visited names are re-fetched, and every re-fetch fails. The vn. DNSKEY set has a 12-hour TTL, so
resolver nodes lose the old key at different times — the outage looks intermittent and differs between
8.8.8.8 and 1.1.1.1.
Why monitoring stayed green
All our uptime monitors for .vn names stayed green, because the prober uses a non-validating resolver. A monitor answers "can my prober reach it", not "can a user resolve it". Add a validating probe, with a non-.vn control that must stay green.
Check it yourself
curl -s 'https://dns.google/resolve?name=vnnic.vn&type=A' | jq '{Status, extended_dns_errors}'
dig +short DS vn. @a.root-servers.net
dig +norec +multi DNSKEY vn. @a.dns-servers.vn | grep "key id"
dig +dnssec +norec DS <name>.vn @a.dns-servers.vn
Compare the root's DS key tags with tags computed from the published DNSKEYs (RFC 4034 Appendix B — see the pseudo-code above). An empty intersection means the TLD chain is broken. Always run a non-.vn control in the same check.
What a domain holder can and cannot do
Nothing in your own zone helps: the chain breaks above you. What helps: report to the registry (VNNIC)
with evidence and ask your registrar to escalate; report to the public resolver operators, who can apply a
negative trust anchor for vn.; tell your users this is a national-infrastructure fault. Precedents
this year: .de (May 2026), about 3 hours, with Cloudflare treating the TLD as insecure after about
2 h 47 min; .al (July 2026), a failed rollover ended when the operator removed its DS from the root,
with a Cloudflare NTA live about 3 hours in.
Lessons
Probe the way users resolve. Read extended errors rather than counting successes. One working name is not an all-clear. And a TLD is a dependency: for critical services, keep a fallback name under another TLD.