Đổi khóa DNS gốc ngày 11/10: việc cần kiểm tra với DNSSEC
Ngày 11/10/2026, DNS root dự kiến chuyển khóa ký khóa mới, KSK-2024. Đây là mắt xích đầu tiên của chuỗi tin cậy DNSSEC: resolver dùng khóa này để xác minh bộ khóa của root, rồi lần lượt kiểm tra các bản ghi phía dưới như .com và tên miền cụ thể. Bài viết của Cloudflare không nói rằng mọi website phải thay đổi cấu hình. Thông điệp chính là các đơn vị tự vận hành DNS resolver có xác thực DNSSEC cần chắc chắn resolver đã tin cậy khóa mới, nếu không người dùng của họ có thể không truy cập được cả những website vốn vẫn hoạt động bình thường.
Điều gì đang thay đổi?
KSK-2024 có key tag 38696 sẽ thay KSK-2017, key tag 20326, để ký tập DNSKEY của root. KSK và ZSK có vai trò khác nhau: KSK xác minh danh sách khóa công khai; ZSK ký các bản ghi DNS còn lại của root, bao gồm DS record của các tên miền cấp cao. Vì root không có miền cha, resolver phải bắt đầu từ một trust anchor cài sẵn hoặc đã học được. Nếu trust anchor sai hoặc thiếu, việc xác thực có thể thất bại dù máy chủ web, zone DNS và đường truyền không có lỗi.
Năm điểm cần nắm từ nguồn gốc
- Không phải ai cũng phải can thiệp. Cloudflare nêu rõ người dùng DNS của Cloudflare, 1.1.1.1 hoặc Gateway DNS không cần làm gì; hệ thống của họ đã tin KSK-2024.
- Resolver có thể tự học khóa. RFC 5011 cho phép học trust anchor mới khi khóa cũ vẫn ký bộ DNSKEY. Resolver chờ tối thiểu 30 ngày và tiếp tục kiểm tra trước khi chấp nhận.
- Thời gian đã được chuẩn bị từ trước. KSK-2024 đã xuất hiện trong root DNSKEY từ 11/01/2025. Tuy vậy, máy mới, restore image cũ hoặc nâng cấp phần mềm có thể mất trạng thái đã học.
- Rollover không đổi thuật toán. Cả KSK-2017 và KSK-2024 đều dùng RSA/SHA-256; đây là thay key pair, không phải đổi thuật toán ký.
- Có cách kiểm tra thực tế. RFC 8509 trust-anchor sentinel cho phép hỏi resolver có tin khóa hay không. Cloudflare cung cấp dnstest.dev/ksk-2024; kết quả phải được hiểu cùng các kiểm tra DNSSEC đi kèm.
Vì sao đội vận hành cần quan tâm?
Đây là rủi ro tập trung: một resolver validating bị thiếu trust anchor có thể làm người dùng không phân giải được tên miền trên nhiều TLD, không chỉ một domain. Sự cố dễ bị chẩn đoán nhầm thành lỗi ISP hoặc website vì đích vẫn online. Các môi trường cần rà soát gồm recursive resolver nội bộ, appliance bảo mật có DNS proxy, resolver trong chi nhánh, lab dùng image cũ và dịch vụ có bật DNSSEC validation. Forwarder không tự xác thực có thể không phải điểm cần sửa, nhưng phải xác định chính xác nơi validation diễn ra.
Checklist trước ngày chuyển đổi
- Lập danh sách resolver đang validating DNSSEC, phiên bản phần mềm, owner và đường đi truy vấn.
- Kiểm tra vendor documentation về KSK-2024; cập nhật trust anchor theo hướng dẫn nếu resolver chưa có khóa.
- Chạy readiness test bằng đúng mạng người dùng và qua VPN/Secure DNS nếu các lớp đó làm đổi resolver.
- Với sentinel, kiểm tra cả truy vấn is-ta-38696 và not-ta-38696. Khi khóa được tin cậy, truy vấn “not trusted” trả SERVFAIL là hành vi dự kiến, không tự động là sự cố.
- Kiểm tra đồng thời một tên miền ký DNSSEC hợp lệ, một tên miền lỗi DNSSEC có chủ ý và truy vấn thông thường để tránh kết luận từ một lỗi mạng.
- Chuẩn bị giám sát SERVFAIL, tỷ lệ lỗi phân giải và phương án rollback/chuyển resolver tạm thời.
Kết luận
Rollover KSK root là thay đổi hạ tầng ít thấy nhưng có phạm vi ảnh hưởng lớn nếu trust anchor ở resolver bị bỏ quên. Phần lớn người dùng DNS công cộng không cần hành động. Với tổ chức vận hành DNSSEC-validating resolver, việc cần làm là kiểm kê, kiểm tra KSK-2024 bằng test phù hợp và xử lý theo hướng dẫn nhà cung cấp trước 11/10, thay vì đợi đến khi truy vấn của người dùng bắt đầu thất bại.
Nguồn
Cloudflare Blog: The keys to the Internet change on October 11, 2026.