Tin tức

Cloudflare's 1.1.1.1 xác thực DNSSEC ML-DSA-44, và chữ ký dài 2.420 byte

Cloudflare đã bật xác thực DNSSEC hậu lượng tử tại 1.1.1.1, buộc hệ sinh thái DNS phải đối mặt với chữ ký 2.420 byte và một đường hạ cấp mà RFC 6840 âm thầm cho phép.

September 10, 2026· 5 min read· Nguồn: Cloudflare Blog
Cloudflare's 1.1.1.1 xác thực DNSSEC ML-DSA-44, và chữ ký dài 2.420 byte

Trình phân giải công cộng của Cloudflare giờ đây xác thực các chữ ký DNSSEC được tạo bằng ML-DSA-44, thuật toán chữ ký hậu lượng tử mà NIST chuẩn hóa năm 2024. Đây là trình phân giải sản xuất đầu tiên làm được điều này, và đó là một bài kiểm tra căng thẳng có chủ đích: công ty muốn tìm ra các lỗi về kích thước gói và hạ cấp ngay bây giờ, chứ không phải vào năm 2030.

Động lực là sự phối hợp, không phải mối đe dọa tức thời. Không có máy tính lượng tử nào có thể phá vỡ RSA hay ECDSA ngày hôm nay. Nhưng những thay đổi DNSSEC đòi hỏi sự đồng thuận giữa các máy chủ có thẩm quyền, cơ quan đăng ký, nhà đăng ký và trình phân giải xác thực — và quá trình di chuyển cuối cùng phải chạm tới vùng gốc, nơi chỉ một khóa ký bị thu hồi sẽ cho phép kẻ tấn công giả mạo đường xác thực tới mọi vùng bên dưới nó. Cách diễn đạt của Cloudflare rất thẳng thắn: phá một lần, giả mạo mọi nơi.

Vì sao kích thước chữ ký là toàn bộ câu chuyện

ECDSA P-256 ký một bản ghi DNSSEC trong 64 byte. Một chữ ký ML-DSA-44 là 2.420 byte — lớn hơn khoảng 38 lần. Khóa công khai là 1.312 byte. Cả hai đều không vừa vặn thoải mái trong một phản hồi DNS-over-UDP.

DNS ban đầu giới hạn thông điệp UDP ở 512 byte. EDNS(0) cho phép trình phân giải quảng bá bộ đệm lớn hơn, và nhiều triển khai đã chọn mức tải trọng thận trọng 1.232 byte để nằm trong MTU tối thiểu 1.280 byte của IPv6. RFC 9715 sau đó khuyến nghị giới hạn 1.400 byte. Một chữ ký ML-DSA-44 duy nhất vượt qua tất cả những con số đó trước khi bạn thêm RRset được ký, tên miền, tiêu đề, hay các bản ghi DNSSEC khác.

UDP phân mảnh là câu trả lời sai — Cloudflare đã ghi nhận nó là không đáng tin cậy. Hành vi đúng là máy chủ có thẩm quyền trả về phản hồi bị cắt ngắn, buộc trình phân giải thử lại qua TCP, DoT, hoặc DoH. Cloudflare cho biết khoảng 85% truy vấn tới 1.1.1.1 đến qua UDP, và khoảng 60% trên tất cả dịch vụ trên nền tảng Big Pineapple DNS của họ. Phần còn lại đã dùng các giao vận hướng kết nối, nên đường thử lại không hề xa lạ — nhưng nó sẽ nhận thêm lưu lượng.

Phản hồi DNSKEY là trường hợp tệ nhất. Chúng mang các khóa mà trình phân giải cần để xác thực vùng, nên trong giai đoạn chuyển tiếp chúng có thể chứa cả khóa và chữ ký thông thường lẫn hậu lượng tử. Thêm một lần luân chuyển khóa và phản hồi lại phình to hơn nữa.

Vấn đề hạ cấp mà không ai muốn nói tới

Các vùng không thể chỉ công bố ML-DSA-44; các trình phân giải cũ sẽ đơn giản là không xác thực được chúng. Con đường thực tế là công bố cả hai thuật toán song song. Điều đó bảo toàn khả năng tương thích, nhưng tự nó không mang lại bảo mật hậu lượng tử.

RFC 6840 nói rằng trình xác thực NÊN chấp nhận bất kỳ một đường hợp lệ nào. Quy tắc đó là thứ cho phép trình phân giải chọn thuật toán mà nó hỗ trợ. Nó cũng là, một khi ECDSA bị phá vỡ, một vector hạ cấp: kẻ tấn công giả mạo một câu trả lời chỉ có ECDSA, và một trình phân giải có khả năng hậu lượng tử vẫn chấp nhận nó.

Cách khắc phục của Cloudflare là một chính sách cục bộ nghiêm ngặt hơn mức RFC yêu cầu. Nếu RRset DS đã được xác thực từ vùng cha chứa một thuật toán hậu lượng tử được hỗ trợ, 1.1.1.1 yêu cầu ít nhất một đường ML-DSA-44 hợp lệ. Một đường thông thường không còn đủ. Nếu không có đường hậu lượng tử nào xác thực được, việc xác thực thất bại. RFC 4035 cho phép trình phân giải đặt chính sách cục bộ về việc phải kiểm tra những chữ ký nào, nên điều này là hợp lệ — nhưng nó không phải hành vi DNSSEC thông thường, và nó chỉ hoạt động nếu tín hiệu hạ cấp kéo dài từ neo tin cậy xuyên qua mọi ủy quyền trong chuỗi.

Luân chuyển khóa vùng thường xuyên hơn không giúp ích gì. Kẻ tấn công có thể nhắm vào một khóa dễ tổn thương ở bất kỳ đâu cao hơn trong hệ thống phân cấp và giả mạo mọi thứ bên dưới nó.

Điều này thực sự chứng minh gì

Lộ trình hậu lượng tử năm 2029 của Cloudflare chủ yếu xoay quanh TLS. DNSSEC là mục tiêu khó hơn vì các giả định về kích thước gói của giao thức đã ăn sâu vào hàng thập kỷ phần mềm mạng, và vì câu chuyện tương thích tạo ra một lỗ hổng bảo mật phải được bịt lại bằng chính sách thay vì giao thức. Chạy xác thực ML-DSA-44 ở quy mô 1.1.1.1 là cách hệ sinh thái phát hiện ra trình phân giải, hộp trung gian và máy chủ có thẩm quyền nào bị hỏng.

Một chữ ký ML-DSA-44 duy nhất lớn hơn toàn bộ ngân sách tải trọng UDP mà DNSSEC được thiết kế xoay quanh — và đường tương thích giữ cho các trình phân giải cũ hoạt động cũng chính là đường mà kẻ tấn công dùng để hạ cấp những trình phân giải mới.
Ban biên tập Manul X
Kích thước thuật toán chữ ký DNSSEC (số thuật toán IANA)
So sánh nhanh
Thuật toánSốKích thước khóa công khaiKích thước chữ ký
RSA-2048/SHA-2568260 byte256 byte
ECDSA P-2561364 byte64 byte
ML-DSA-44181.312 byte2.420 byte