DNSSEC và DNS over HTTPS bảo vệ hai phần khác nhau của DNS

DNSSEC và DNS over HTTPS không phải hai tên gọi cho cùng một lớp bảo vệ. DNSSEC giúp kiểm tra dữ liệu DNS có đúng nguồn và không bị sửa trái phép; DNS over HTTPS, hay DoH, bảo vệ việc trao đổi truy vấn với một bộ phân giải bằng HTTPS. Một cơ chế tập trung vào dữ liệu, cơ chế kia tập trung vào đường truyền.

Phân biệt này hữu ích khi một trình duyệt thông báo đã dùng “DNS an toàn”, nhưng người quản trị vẫn cần kiểm tra chữ ký của tên miền. Không thể chỉ nhìn nhãn trên giao diện rồi kết luận toàn bộ chuỗi phân giải đã được bảo vệ theo cùng cách.

DNSSEC ký dữ liệu, không giấu tên miền được hỏi

RFC 4033 xác định DNSSEC cung cấp xác thực nguồn và bảo vệ tính toàn vẹn cho dữ liệu DNS, đồng thời nói rõ nó không cung cấp tính bí mật. Điều đó có nghĩa câu trả lời có thể được kiểm chứng mà nội dung truy vấn không vì thế được mã hóa.

DNS là bước chuyển từ tên mà con người sử dụng sang thông tin máy cần, chẳng hạn địa chỉ IP. Nếu trả lời bị giả mạo, máy có thể nhận một đích khác. DNSSEC bổ sung cơ sở mật mã để bộ phân giải nhận biết dữ liệu hợp lệ thay vì chỉ tin nội dung nhận được qua mạng.

Tuy nhiên, chữ ký hợp lệ chỉ chứng minh dữ liệu tương ứng với khóa được tin cậy. Nó không xác nhận một website có nội dung đáng tin, cửa hàng có uy tín hay dịch vụ phía sau không có lỗ hổng. Đây là xác thực dữ liệu hạ tầng, không phải chứng nhận mọi hoạt động của tên miền.

Chuỗi tin cậy nối các vùng DNS như thế nào?

Tài liệu kỹ thuật Cloudflare giải thích các bản ghi cùng tên và cùng loại được tập hợp thành RRset để ký. RRSIG chứa chữ ký, DNSKEY cung cấp khóa công khai, còn DS ở vùng cha giúp liên kết đến khóa của vùng con.

Việc công bố một khóa trên cùng máy chủ trả lời chưa đủ: người nhận còn cần biết vì sao nên tin khóa ấy. Chuỗi xác thực nối các liên kết qua vùng cha và vùng con, cuối cùng dựa trên một điểm tin cậy đã được thiết lập.

Điểm thực tế là bật ký tại nhà cung cấp DNS mới chỉ giải quyết một phần công việc. Nếu liên kết ở vùng cha không tương ứng với khóa đang dùng, bộ phân giải có kiểm chứng có thể không chấp nhận dữ liệu. Vì vậy, chuyển nhà cung cấp hoặc đổi khóa cần được xem như thay đổi cả chuỗi, không chỉ thay một giá trị trên bảng điều khiển.

DoH bảo vệ đoạn trao đổi với resolver

RFC 8484 định nghĩa cách gửi truy vấn và nhận phản hồi DNS qua HTTPS. Resolver là dịch vụ phân giải thay mặt ứng dụng tìm câu trả lời; HTTPS bảo vệ kết nối giữa ứng dụng DoH và dịch vụ đó.

Kết nối được mã hóa giúp giảm khả năng người quan sát đường truyền đọc hoặc sửa trực tiếp nội dung trao đổi. Nhưng điểm cuối vẫn cần xử lý truy vấn để trả lời. Mã hóa đường đi không làm nhà vận hành resolver biến mất khỏi mô hình tin cậy.

Đặc tả cũng bàn riêng về quyền riêng tư trên đường truyền và tại máy chủ. Đó là hai nơi có nguy cơ khác nhau: che nội dung khỏi một bên trung gian không đồng nghĩa không còn bên nào có thể thấy tên miền được hỏi.

Vì sao có thể cần cả hai?

Cloudflare phân biệt DNSSEC với các cơ chế mã hóa DNS: DNSSEC không mã hóa trao đổi, trong khi DoH bảo vệ truy vấn trên kết nối HTTPS. Hai lớp có thể bổ sung cho nhau vì chúng trả lời hai câu hỏi khác nhau.

Một kết nối được mã hóa tới resolver chưa tự chứng minh câu trả lời bắt nguồn từ chuỗi DNSSEC hợp lệ. Ngược lại, một RRset có chữ ký kiểm chứng được vẫn có thể đi qua đường truyền không mã hóa. Khi đánh giá một cấu hình, cần hỏi riêng bộ phân giải có thực hiện kiểm chứng hay không và ứng dụng đang dùng đường truyền nào.

Ngay cả khi cả hai hoạt động, người dùng cũng không tự nhiên trở nên vô danh. Dịch vụ đích, tài khoản đăng nhập và các lớp mạng khác vẫn tạo ra dấu vết của riêng chúng. Nên mô tả lợi ích theo đúng phạm vi để tránh kỳ vọng sai.

Kiểm tra theo từng lớp thay vì theo tên tính năng

Với người quản trị tên miền, trọng tâm là trạng thái ký, khóa, DS và kết quả kiểm chứng từ resolver. Với ứng dụng người dùng, trọng tâm còn có endpoint DoH thực sự được chọn và chính sách vận hành của dịch vụ phân giải. Hai nhóm kiểm tra không thay thế nhau.

Một kế hoạch thay đổi tốt cần biết cấu hình trước và sau, cùng dấu hiệu cho thấy việc phân giải còn hoạt động đúng. Bài viết này giải thích cơ chế, không đưa lệnh thay khóa trực tiếp trên hệ thống đang chạy. Thay đổi DNSSEC thiếu phối hợp có thể làm ảnh hưởng truy cập dù máy chủ web vẫn bình thường.

Cách hiểu hữu ích nhất là tách tính xác thực, tính toàn vẹn và tính bí mật. Khi biết mỗi lớp chịu trách nhiệm điều gì, người dùng có thể đánh giá “DNS an toàn” bằng hành vi thực tế thay vì chỉ bằng một nhãn cài đặt.

Nguồn và sơ đồ

Nguồn: IETF, RFC 4033, tháng 3/2005; RFC 8484, tháng 10/2018; Cloudflare, cơ chế DNSSEC; phân biệt mã hóa DNS. Đây là bài kiến thức, không phải tin phát hành giao thức mới.

Sơ đồ xác thực DNSKEY/DS: Kaaa, Wikimedia Commons, CC0 1.0, sử dụng nguyên bản. Các giá trị trong hình minh họa năm 2011 không phải cấu hình để sao chép vào hệ thống.