Sự cố DNSSEC tên miền .vn ngày 22/10/2026: vì sao website 'chỉ mình tôi' không truy cập được

Trạng thái: đã khắc phục lúc 10:45 giờ Việt Nam (03:45 UTC) ngày 22/10/2026. Cập nhật khắc phục: VNNIC bắt đầu phát hành zone đã sửa (serial 2031364721: có lại KSK 16196 và chuỗi NSEC3) lúc 10:32 giờ VN. Zone mới tới các máy chủ không cùng lúc: b, c, f, h trước, rồi g, a, d, và e cuối cùng lúc 10:45. Trong 13 phút đó, resolver nào hỏi trúng máy chủ chưa cập nhật vẫn nhận câu trả lời lỗi. Zone lỗi được phục vụ khoảng 1 giờ 50 phút (08:55–10:45). Thời gian người dùng thực sự bị ảnh hưởng ngắn hơn và khác nhau theo từng resolver, vì phụ thuộc vào cache.

Tóm tắt

Sáng 22/10/2026, các website dùng tên miền .vn bắt đầu không truy cập được với người dùng có resolver kiểm tra DNSSEC: Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9). Theo số liệu APNIC, khoảng 45% người dùng tại Việt Nam đứng sau resolver có kiểm tra DNSSEC, chưa kể người dùng quốc tế.

Nguyên nhân không nằm ở website hay nhà cung cấp DNS của từng tên miền. Nó nằm ở zone vn. do VNNIC vận hành: zone được ký lại vào khoảng 01:55 UTC (08:55 giờ VN), và sau lần ký đó khóa KSK mà vùng gốc (root) trỏ tới không còn được công bố. Chuỗi tin cậy DNSSEC đứt ngay ở cấp TLD.

Chuyện gì đã xảy ra — về mặt kỹ thuật

DNSSEC hoạt động như một chuỗi chữ ký: root ký bản ghi DS của vn., bản ghi DS đó chỉ tới một khóa KSK trong tập DNSKEY của vn., KSK ký tập DNSKEY, và khóa ZSK trong tập đó ký phần còn lại của zone.

Đo trực tiếp trên cả 8 máy chủ a…h.dns-servers.vn, qua UDP lẫn TCP, từ Việt Nam, Singapore và châu Âu:

Root vẫn công bố DS cho vn. với key tag 16196 (thuật toán 8, RSASHA256).
Tập DNSKEY của vn. chỉ còn khóa ZSK (key tag 52956), và tập này chỉ được ký bởi chính 52956. Khóa 16196 không còn.
NSEC3PARAM vn. trả về rỗng. Truy vấn DS cho một tên miền con (ví dụ một tên miền .vn bất kỳ) nhận NOERROR/NODATA với phần AUTHORITY chỉ có SOA + RRSIG — không có NSEC/NSEC3 để chứng minh "không có DS".
Chữ ký SOA của vn. có thời điểm hiệu lực 20261022015500 — zone vừa được ký lại sáng nay.

Với resolver kiểm tra DNSSEC, vn. trở thành bogus. Thông báo lỗi mở rộng (EDE) mà người vận hành thấy:

Google: Invalid denial of existence of <tên-miền>/ds, và sau đó DNSSEC validation failure cho chính vn. SOA.
Cloudflare: EDE(10): RRSIGs Missing … failed to verify vn. SOA.

Mẫu hình này giống một lần thay khóa (key rollover) thất bại: khóa mới hoặc cách ký mới được đưa vào nhưng khóa cũ mà root đang tham chiếu bị gỡ trước khi DS ở root được cập nhật.

Vì sao trông như "chỉ website của tôi bị lỗi"

Đây là phần dễ gây hiểu lầm nhất. Lúc 10:20, phần lớn website .vn lớn (cổng thông tin, ngân hàng, báo) vẫn truy cập được trên Google và Cloudflare, trong khi các website nhỏ hơn đã lỗi hoàn toàn. Lý do là bộ nhớ đệm (cache):

Resolver giữ câu trả lời đã được xác thực trước 08:55 cho tới khi TTL hết. Website lớn có lưu lượng cao và TTL dài sống nhờ cache.
Website có TTL ngắn (300 giây là phổ biến khi dùng CDN) hoặc ít truy cập phải được phân giải lại — và mỗi lần phân giải lại đều thất bại.
Bản thân tập DNSKEY của vn. có TTL 12 giờ, nên từng node resolver mất khóa cũ vào những thời điểm khác nhau. Kết quả: lỗi chập chờn, có lúc được có lúc không, khác nhau giữa 8.8.8.8 và 1.1.1.1.

Nếu bạn chỉ thử một tên miền rồi thấy nó chạy, đó không phải bằng chứng mọi thứ ổn.

Vì sao monitor vẫn báo xanh

Toàn bộ monitor uptime của chúng tôi cho các tên miền .vn đều xanh suốt thời gian đó. Lý do đơn giản: máy chạy monitor dùng một resolver không kiểm tra DNSSEC. Nó vẫn phân giải được tên miền, nên nó báo "lên". Monitor trả lời câu hỏi "máy giám sát có tới được website không", không phải "người dùng có phân giải được tên miền không".

Bài học: cần ít nhất một đầu dò dùng resolver có kiểm tra DNSSEC, và đầu dò đó phải có đối chứng (một tên miền ngoài .vn luôn phải xanh), để phân biệt "TLD hỏng" với "đầu dò hỏng".

Tự kiểm tra

1. Hỏi một resolver biết nói lý do. DoH dạng JSON của Google trả về Status và lỗi mở rộng:

curl -s 'https://dns.google/resolve?name=vnnic.vn&type=A' | jq '{Status, extended_dns_errors}'
# Status 0 = NOERROR, 2 = SERVFAIL. Thêm &cd=1 để tắt kiểm tra: nếu cd=1 thì được mà
# không có cd thì SERVFAIL, lỗi nằm ở DNSSEC chứ không phải ở máy chủ tên miền.

2. So khóa của TLD với DS ở root.

dig +short DS vn. @a.root-servers.net                         # key tag root mong đợi
dig +norec +multi DNSKEY vn. @a.dns-servers.vn | grep "key id"  # key tag đang được công bố
dig +dnssec +norec DS <tên-miền>.vn @a.dns-servers.vn          # có NSEC3 trong AUTHORITY không?

3. Tính key tag từ DNSKEY (RFC 4034, phụ lục B) để so tự động:

function keyTag(flags, protocol, algorithm, publicKeyBase64):
    rdata = [flags >> 8, flags & 0xFF, protocol, algorithm] + base64decode(publicKeyBase64)
    acc = 0
    for i, byte in rdata:
        acc += (i is odd) ? byte : byte << 8
    acc += (acc >> 16) & 0xFFFF
    return acc & 0xFFFF

expected = { keyTag of each DS record for "vn." at the root }
published = { keyTag(k) for k in DNSKEY("vn.") }
if expected ∩ published is empty: TLD chain is broken

4. Luôn chạy đối chứng. Cùng lúc đó, một tên miền ngoài .vn (ví dụ .com) phải trả Status 0. Nếu đối chứng cũng lỗi, đầu dò của bạn mới là thứ hỏng.

Chủ tên miền làm được gì — và không làm được gì

Không làm được trong zone của mình. Chuỗi tin cậy đứt phía trên tên miền của bạn. Ký zone của bạn, thêm hay bỏ DS, đổi nhà cung cấp DNS — không thay đổi gì, vì resolver không đi tới được zone của bạn bằng một chuỗi hợp lệ.

Làm được:

Báo cho cơ quan quản lý TLD (VNNIC) kèm bằng chứng kỹ thuật, và nhờ nhà đăng ký tên miền (registrar) chuyển tiếp — registrar có kênh làm việc trực tiếp. Hướng khắc phục chỉ VNNIC làm được: công bố lại KSK 16196 và ký lại zone, hoặc đề nghị IANA gỡ DS của vn. khỏi root.
Báo cho các nhà vận hành resolver công cộng (Google Public DNS, Cloudflare, Quad9). Họ có thể đặt negative trust anchor (NTA) — tạm coi vn. là không ký — để người dùng truy cập lại được trong lúc chờ TLD sửa.
Gửi thông tin cho khách hàng/người dùng: đây là lỗi hạ tầng quốc gia, tạm thời có thể dùng resolver của nhà mạng (thường không kiểm tra DNSSEC). Không khuyến nghị tắt DNSSEC lâu dài.

Tiền lệ trong năm 2026:

.de (05/2026): lỗi trong quá trình thay khóa ZSK khiến khoảng một phần ba chữ ký không hợp lệ. Khoảng 3 giờ ảnh hưởng nặng; Cloudflare áp dụng cơ chế tương đương NTA sau khoảng 2 giờ 47 phút, các nhà vận hành khác trong vòng khoảng một giờ.
.al (07/2026): thay khóa thất bại — khóa mới được công bố trong khi DS ở root vẫn trỏ khóa cũ, rồi khóa cũ bị gỡ. Cloudflare đặt NTA khoảng 3 giờ sau sự cố; sự cố kết thúc khi nhà quản lý TLD gỡ DS khỏi root.

Hai tiền lệ này cho thấy các resolver lớn có hành động ở cấp TLD, thường tự quyết dựa trên bằng chứng và lượng phản ánh. Báo cáo sớm, rõ ràng có giá trị.

Bài học

Monitor của bạn phải phân giải giống người dùng. Thêm một đầu dò dùng resolver có kiểm tra DNSSEC.
Đọc lỗi mở rộng, đừng đếm tỷ lệ thành công. Một timeout và một SERVFAIL trông như nhau trong thống kê, nhưng EDE nói chính xác chỗ đứt.
Một tên miền chạy được không phải là "đã hết lỗi". Cache che lỗi tới hết TTL.
Phụ thuộc cấp trên là rủi ro thật. Khi TLD hỏng, mọi tên miền bên dưới hỏng theo. Với dịch vụ quan trọng, cân nhắc có tên miền dự phòng ở một TLD khác.