DNSSEC là gì? Đó là lớp bảo mật được bổ sung vào hệ thống tên miền DNS, cho phép máy phân giải xác minh rằng dữ liệu trả về đúng là do chính tên miền đó ký chứ không phải do kẻ tấn công chèn vào. Bài viết này giải thích DNSSEC theo đúng đặc tả kỹ thuật: chuỗi tin cậy đi từ đâu, các bản ghi DNSKEY, DS, RRSIG, NSEC nói lên điều gì, và những lỗi cấu hình nào khiến cả tên miền biến thành trạng thái Bogus khiến người dùng không truy cập được.
DNS vốn dùng UDP không mã hóa và không xác thực, nên một kẻ trung gian có thể sửa câu trả lời của trình phân giải và đưa người dùng tới trang giả mạo mà không đổi lại địa chỉ nào trong thanh địa chỉ. DNSSEC không sửa cách tra cứu tên miền, mà gắn thêm chữ ký số vào dữ liệu trả lời để bên nhận tự kiểm chứng nguồn gốc.
DNSSEC bảo vệ được gì và không bảo vệ được gì
Theo RFC 4033, các mở rộng bảo mật của DNS bổ sung data origin authentication (xác thực nguồn gốc dữ liệu) và data integrity (tính toàn vẹn dữ liệu) cho hệ thống DNS. Đặc tả nhấn mạnh DNSSEC không được thiết kế để cung cấp tính bảo mật nội dung hay phân quyền truy cập.
- Có bảo vệ: phát hiện dữ liệu DNS bị sửa trên đường truyền, chống giả mạo tên miền bằng cách thay đổi bản ghi trả về.
- Không bảo vệ: nội dung website sau khi đã tới đúng máy chủ, và cũng không cung cấp tính bảo mật nội dung DNS — vì vậy DNSSEC phải đi cùng HTTPS chứ không thay thế cho nó.
- Không chống DoS: RFC 4033 ghi rõ DNSSEC không bảo vệ chống từ chối dịch vụ, thậm chí còn tạo ra một lớp tấn công mới dựa trên thao tác mã hóa tốn kém nhắm vào các trình phân giải có xác thực.
- Không ký dữ liệu glue: các bản ghi không thuộc thẩm quyền tại điểm chuyển vùng (glue và NS trong vùng cha) không được ký, nên không thể xác thực chúng.
Chuỗi tin cậy bắt đầu từ đâu
Toàn bộ cơ chế dựa trên một ý tưởng đơn giản: mỗi vùng cha ký một bản ghi chứng thực (DS) trỏ tới khóa của vùng con. Bắt đầu từ khóa gốc được cài sẵn trong trình phân giải, mỗi bước xuống vùng con lại lặp lại nguyên tắc ký rồi chuyển khóa, tạo thành một chuỗi tin cậy không cần chứng thư trung ương.
- Khóa gốc từ IANA. Danh sách khóa công khai hiện hành nằm trong tệp root-anchors.xml của IANA. Tệp này liệt kê nhiều mục theo dõi để hỗ trợ quá trình chuyển khóa; khóa KSK đang hoạt động có KeyTag 38696, hiệu lực từ ngày 18-07-2024, thay cho KeyTag 20326 dùng từ năm 2017.
- Bản ghi DS ở vùng cha. Theo RFC 4034, bản ghi DS (mã loại 43) tham chiếu một bản ghi DNSKEY bằng cách lưu key tag, số thuật toán và một giá trị băm của chính DNSKEY. DS cho
example.comđược lưu trong vùngcom, tức là phía cha. - Vùng con chứng minh mình đúng. Vùng con công bố bản ghi DNSKEY tương ứng; trình phân giải băm nó và so với giá trị trong DS. Khớp thì chuỗi tin cậy được nối tiếp.
- Kiểm tra chữ ký trên dữ liệu. Mỗi tập bản ghi được bảo vệ bằng một bản ghi RRSIG (mã loại 46) chứa chữ ký số cho tên, lớp và loại của tập bản ghi đó.
Bốn loại bản ghi cốt lõi của DNSSEC
Đọc hiểu DNSSEC gần như không cần thuật toán mật mã, chỉ cần biết bốn loại bản ghi sau và vai trò của từng loại trong chuỗi xác thực.
| Bản ghi | Mã loại | Vai trò | Điều kiện cần nhớ |
|---|---|---|---|
| DNSKEY | 48 | Công bố khóa công khai của vùng, kèm cờ Zone Key và cờ SEP | Trường Protocol phải bằng 3 |
| DS | 43 | Liên kết vùng cha với khóa của vùng con | Chỉ tồn tại ở phía cha |
| RRSIG | 46 | Chữ ký số của một tập bản ghi | TTL phải khớp tập bản ghi được phủ |
| NSEC / NSEC3 | 47 / 50 | Chứng minh có chủ đích rằng một tên không tồn tại | NSEC3 băm tên để chống dò tên miền |
Cờ SEP (Secure Entry Point) là gợi ý cho phần mềm ký vùng: bản ghi DNSKEY mang cờ SEP nhưng không có cờ Zone Key thì không được dùng để xác minh RRSIG. Riêng cơ chế chứng minh sự vắng mặt, RFC 5155 bổ sung NSEC3 với tên được băm nhằm chống việc kẻ xấu lần theo chuỗi NSEC để dựng lại toàn bộ danh sách tên miền trong vùng.
Quyền kiểm chứng nằm ở trình phân giải, không nằm ở trình duyệt
Một chi tiết gây hiểu nhầm nhiều người: trình duyệt của bạn thường không tự kiểm tra chữ ký. Trình phân giải đệ quy (recursive resolver) của nhà mạng hoặc dịch vụ DNS công cộng là nơi thực hiện xác thực, rồi gắn cờ Authenticated Data (AD) vào câu trả lời. Ứng dụng chạy trên máy bạn chỉ đọc cờ AD để biết kết quả đó có được kiểm chứng hay không, theo đúng mô tả stub resolver trong RFC 4033.
Hệ quả thực tế: nếu bạn dùng một trình phân giải không xác thực, việc bật DNSSEC trên tên miền không tạo ra khác biệt nào với bạn, dù nó vẫn bảo vệ người dùng đi qua cùng đường mạng đó. Nếu bạn muốn kiểm tra thực tế thay vì tin lời kết quả tra cứu, hãy dùng một trình phân giải có xác thực, ví dụ chương trình DNSSEC của ICANN có công cụ kiểm tra theo tên miền.
Những lỗi cấu hình gây giảm tiếp truy cập
Nguy hiểm nhất của DNSSEC không phải là thiếu ký, mà là ký sai. RFC 6781 định nghĩa trạng thái security lameness: vùng cha có bản ghi DS trỏ tới một DNSKEY không tồn tại, khiến vùng con bị đánh dấu là Bogus. Khi chữ ký hết hạn vì máy chủ thẩm quyền không tới được máy chủ chính để gia hạn, trình phân giải thường trả lỗi SERVFAIL cho người dùng trong khi bạn vẫn thấy website mở bình thường trên máy tính của mình.
- DS không khớp DNSKEY: hay do nhầm khi chuyển khóa KSK mà không đợi đủ thời gian cache quay vòng.
- Chữ ký hết hạn: ký theo lịch không đều hoặc máy chủ mất liên kết tới máy chủ chính làm chuỗi ký đứt.
- Chuỗi ký quá phức tạp: tạo tải bất thường lên trình phân giải có xác thực, biến DNSSEC thành điểm nghẽn.
- Chuyển KSK sai quy trình: RFC 6781 nói rõ việc xoay khóa KSK bắt buộc phải có tương tác với vùng cha, khác hẳn việc xoay ZSK chỉ nằm trong nội bộ vùng.
- NSEC3 dùng tham số không chuẩn: RFC 9276 khuyến nghị không dùng opt-out cho vùng nhỏ và chọn NSEC3PARAM dạng
1 0 0 -, tức SHA-1, không lặp thêm, không salt.
Triển khai DNSSEC theo đúng thứ tự
- Chuẩn bị khóa. Tạo cặp KSK và ZSK cho vùng, lưu khoá riêng tư ngoài máy chủ. KSK là khóa chỉ dùng để ký các bản ghi DNSKEY, ZSK ký toàn bộ dữ liệu còn lại.
- Ký vùng và công bố DNSKEY. Dùng chữ ký có thời hạn ngắn để giảm thiểu rủi ro nếu chuỗi bị đứt, thường vài ngày thay vì vài tháng.
- Bàn giao DS cho vùng cha. Gửi key tag, thuật toán và giá trị băm tới nhà đăng ký tên miền, rồi chờ DS xuất hiện ở vùng cha.
- Theo dõi tình trạng xác thực. Dùng công cụ kiểm tra để xác nhận chuỗi từ gốc tới tên miền của bạn đều hợp lệ, và cài giám sát cảnh báo khi chữ ký sắp hết hạn.
- Có kế hoạch thu hồi. Trước khi xoay khóa, giữ chữ ký chồng lấn trong một khoảng thời gian đủ dài để trình phân giải ở xa cập nhật hết, rồi mới gỡ khóa cũ.
Nguồn tham khảo: đặc tả gốc RFC 4033, RFC 4034, RFC 5155, RFC 9276, RFC 6781, khóa gốc công khai tại IANA và tài liệu triển khai của ICANN.
