DNSSEC: Hiểu chuỗi tin cậy DS, DNSKEY và RRSIG

DNSSEC không mã hóa truy vấn DNS; nó giúp resolver phát hiện dữ liệu bị giả mạo hoặc sửa đổi. Cơ chế này ký các tập bản ghi của zone và nối khóa của zone con với zone cha, tạo chuỗi tin cậy từ root tới tên miền cần phân giải.

Giá trị bảo mật đi kèm rủi ro vận hành: một bản ghi DS cũ tại registrar, chữ ký hết hạn hoặc key rollover sai thứ tự có thể khiến validating resolver đánh dấu zone là Bogus. Vì vậy cần hiểu từng mắt xích trước khi bật DNSSEC hoặc chuyển nhà cung cấp DNS.

1. DNSSEC cung cấp và không cung cấp điều gì?

RFC 4033 xác định DNSSEC cung cấp xác thực nguồn gốc, bảo vệ toàn vẹn dữ liệu DNS và phân phối khóa công khai. Nó không cung cấp tính bí mật, kiểm soát truy cập hay phòng chống từ chối dịch vụ.

2. DNSSEC ký RRset, không ký từng packet

DNS nhóm các record cùng tên và cùng type thành RRset. Authoritative zone tạo chữ ký số cho RRset; chữ ký được công bố trong record RRSIG. Resolver lấy dữ liệu, RRSIG và public key để kiểm tra nội dung có đúng với dữ liệu đã được ký hay không.

Đây là object security, không phải channel security. Dữ liệu có thể đi qua cache hoặc transport khác nhau mà vẫn được xác minh, miễn resolver nhận đủ material và chuỗi tin cậy còn hợp lệ.

3. Bốn loại record cốt lõi

RFC 4034 định nghĩa DNSKEY, RRSIG, DS và NSEC. Private key không xuất hiện trong DNS; nó phải được bảo vệ bởi nhà vận hành signing service.

4. Chuỗi tin cậy từ root tới tên miền

1. Validating resolver có trust anchor cho DNS root.
2. Root ký RRset DS trỏ tới khóa của TLD, chẳng hạn .com.
3. TLD ký DS trỏ tới DNSKEY của zone con.
4. DNSKEY của zone con xác minh RRSIG trên A, AAAA, MX, TXT và các RRset khác.
5. Nếu mọi chữ ký, digest, thuật toán và thời gian đều hợp lệ, kết quả là Secure.

DS là mắt xích giao giữa hai bên vận hành: DNS provider quản lý khóa và ký zone; registrar/registry đưa DS vào parent. Bật signing ở provider nhưng chưa có DS tạo một island of security mà resolver không thể nối từ root. Đưa DS sai vào parent nguy hiểm hơn: resolver kỳ vọng zone có thể xác minh nhưng validation thất bại.

5. Trạng thái Secure, Insecure, Bogus và Indeterminate

Với người dùng, Bogus thường biểu hiện như SERVFAIL, không phải một trang cảnh báo đẹp. Một resolver không validate có thể vẫn trả lời bình thường, khiến lỗi chỉ xuất hiện với một phần mạng và khó chẩn đoán.

6. Xác thực “không tồn tại” bằng NSEC và NSEC3

Chữ ký trên record tồn tại chưa chứng minh được NXDOMAIN là thật. NSEC tạo chuỗi có thứ tự giữa các tên và chỉ ra khoảng không có tên; mỗi NSEC được ký. Cách này cho phép zone walking, vì người hỏi có thể lần theo chuỗi để liệt kê tên.

NSEC3 dùng hash tên nhằm làm việc liệt kê khó hơn, nhưng không biến DNS thành bí mật và không chống được mọi suy đoán từ dictionary. NSEC3 còn tăng độ phức tạp cùng chi phí tính toán. Chọn NSEC hay NSEC3 theo threat model và khả năng của provider, không bật NSEC3 chỉ vì “số 3 mới hơn”.

7. KSK, ZSK và mô hình signing

Trong mô hình tách khóa truyền thống, Zone Signing Key (ZSK) ký phần lớn RRset, còn Key Signing Key (KSK) ký DNSKEY RRset và được DS ở parent tham chiếu. ZSK có thể rollover mà không thay DS; KSK rollover cần phối hợp với parent.

Một số dịch vụ dùng Combined Signing Key hoặc single-type scheme để giảm vận hành. RFC 6781 thảo luận cả hai mô hình. Lựa chọn nên theo automation, provider và chính sách, không dựa trên tên gọi. Điều bắt buộc là resolver luôn tìm được ít nhất một đường xác minh xuyên suốt cache trong giai đoạn rollover.

8. TTL, thời hạn chữ ký và đồng hồ

RRSIG có thời điểm bắt đầu và hết hạn. Hệ thống signing phải tái ký trước hạn, còn clock sai có thể khiến chữ ký trông như chưa hiệu lực hoặc đã hết hạn. TTL lại quyết định dữ liệu cũ sống trong cache bao lâu.

• Giám sát thời gian còn lại của RRSIG, không chờ tới hạn mới cảnh báo.
• Duy trì đồng bộ thời gian đáng tin cậy cho signer và authoritative infrastructure.
• Trong rollover, giữ overlap đủ cho TTL của DNSKEY, DS và chữ ký liên quan.
• Không giảm TTL ngay lúc sự cố rồi kỳ vọng cache cũ biến mất.

9. Cách bật DNSSEC an toàn

1. Kiểm kê registrar, registry, authoritative provider và quyền quản trị từng nơi.
2. Xác nhận TLD/registrar hỗ trợ DNSSEC cùng thuật toán provider dùng.
3. Bật signing tại authoritative provider trước.
4. Kiểm tra DNSKEY, RRSIG và negative answer từ mọi authoritative nameserver.
5. Lấy DS chính xác từ provider; đối chiếu key tag, algorithm, digest type và digest.
6. Đưa DS vào parent qua registrar.
7. Chờ propagation rồi kiểm tra từ nhiều validating resolver.
8. Thiết lập cảnh báo chữ ký, DS/DNSKEY mismatch và SERVFAIL.

Trình tự cốt lõi là ký zone và kiểm tra trước, công bố DS sau. Đừng tạo DS từ một khóa chưa hiện diện ổn định trên tất cả authoritative server.

10. Kiểm tra bằng dig

dig example.com A +dnssec
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec
dig nonexistent-name.example.com A +dnssec
dig example.com A @1.1.1.1 +dnssec
dig example.com A @8.8.8.8 +dnssec

Cờ +dnssec yêu cầu DNSSEC records nhưng không tự chứng minh máy đang thực hiện validation. Khi hỏi validating resolver, cờ AD trong response có thể biểu thị dữ liệu đã được xác thực, tùy trust boundary của kết nối tới resolver. Dùng thêm công cụ phân tích chain và truy vấn authoritative trực tiếp để tách lỗi signer, delegation, cache và recursive validation.

11. Chẩn đoán SERVFAIL do DNSSEC

1. Xác nhận lỗi chỉ xảy ra ở validating resolver hay ở mọi resolver.
2. Đọc DS tại parent và DNSKEY tại child; so sánh key tag, algorithm và digest.
3. Kiểm tra RRSIG có hết hạn, chưa hiệu lực hoặc thiếu cho RRset không.
4. Truy vấn từng authoritative nameserver để phát hiện node chưa đồng bộ.
5. Kiểm tra delegation, glue, packet truncation, TCP/UDP 53 và EDNS.
6. Xem NSEC/NSEC3 cho negative response.
7. Ghi lại bằng chứng trước khi thay đổi để tránh che mất nguyên nhân.

Không tắt validation toàn hệ thống như một “cách sửa”. Nếu phải rollback DNSSEC, cần xử lý DS ở parent và chờ cache theo quy trình, chứ chỉ tắt signing ở child trong khi DS còn tồn tại sẽ làm zone Bogus chắc chắn hơn.

12. Chuyển nhà cung cấp DNS khi DNSSEC đang bật

Đây là thay đổi có hai mặt phẳng: nameserver delegation và chain of trust. Phương án tốt nhất phụ thuộc hai provider có hỗ trợ multi-signer, giữ key hay automation DS hay không.

Với migration phổ thông không hỗ trợ multi-signer, cần dùng quy trình được cả hai provider tài liệu hóa. Một hướng an toàn có thể là gỡ DS ở parent, chờ delegation trở thành Insecure sau TTL, chuyển nameserver, bật signing ở provider mới, kiểm tra, rồi đăng DS mới. Điều này tạo khoảng thời gian không DNSSEC nhưng tránh Bogus. Không dùng công thức này máy móc nếu provider hỗ trợ chuyển khóa/DS không gián đoạn.

Không đổi nameserver trong khi DS cũ vẫn trỏ vào khóa chỉ provider cũ có. ICANN nhấn mạnh parent cần material của child để hoàn tất chuỗi tin cậy; registrar là điểm phối hợp cập nhật này.

13. Key rollover đúng tư duy

Rollover phải chấp nhận nhiều trạng thái cache cùng tồn tại. Với ZSK, pre-publish khóa mới trước khi dùng nó ký giúp resolver có cơ hội nhận key. Với KSK, cần giai đoạn mà DS/DNSKEY cũ và mới tạo được đường xác minh phù hợp trước khi loại bỏ khóa cũ.

• Automation phải có health check và dừng khi publication không đồng nhất.
• Không xóa khóa cũ ngay sau khi thấy khóa mới ở một resolver.
• Diễn tập emergency rollover và lưu kênh liên hệ registrar ngoài DNS đang lỗi.
• Theo dõi thuật toán được registry, signer và validator hỗ trợ trước algorithm rollover.

14. Những anti-pattern phổ biến

• Thêm DS trước khi zone mới được ký ổn định.
• Copy nhầm DS giữa staging và production hoặc giữa hai tên miền.
• Tắt signing nhưng quên xóa DS tại parent.
• Đổi provider/nameserver mà không lập kế hoạch DNSSEC riêng.
• Không giám sát RRSIG expiry vì tin provider luôn tự động đúng.
• Cho rằng DNSSEC mã hóa truy vấn hoặc thay thế HTTPS.
• Chỉ kiểm tra bằng resolver nội bộ không validate.
• Rollover khóa mà bỏ qua TTL và dữ liệu cache.

Checklist production

• Tất cả authoritative server trả DNSKEY và RRSIG nhất quán.
• DS tại parent khớp DNSKEY đang được công bố.
• Positive và negative response đều validate.
• Chữ ký còn đủ thời gian và có cảnh báo trước hạn.
• Signer có clock, key protection, backup và audit phù hợp.
• Đã kiểm tra qua nhiều validating resolver bên ngoài.
• Có runbook KSK/ZSK rollover và emergency rollback.
• Mọi migration DNS đều có bước quản lý DS riêng.
• Đội vận hành phân biệt Secure, Insecure và Bogus.
• DNSSEC được kết hợp với HTTPS và bảo vệ kênh DNS khi cần riêng tư.

Kết luận

DNSSEC tạo niềm tin bằng cách ký RRset và nối DNSKEY của zone con với DS ở zone cha. Công nghệ này phát hiện dữ liệu giả mạo nhưng không mã hóa DNS, không thay thế TLS và không tự chống DDoS. Triển khai tốt phụ thuộc vào đúng trình tự: ký và kiểm tra child, công bố DS, giám sát chữ ký, rồi rollover với thời gian overlap đủ cho cache. Khi hiểu chuỗi tin cậy, DNSSEC trở thành kiểm soát có thể vận hành thay vì một hộp chọn dễ gây SERVFAIL.