Tiêu chuẩn quốc gia TCVN 11818:2017 quy định về An toàn hệ thống bảo mật DNS (DNSSEC) đối với các thay đổi trong giao thức. Tiêu chuẩn này tập trung vào việc chuẩn hóa các phần mở rộng bảo mật cho hệ thống tên miền (DNS), xác định rõ vai trò, chức năng và cơ chế hoạt động của các thực thể trong hệ thống bảo mật DNS nhằm đảm bảo tính toàn vẹn và xác thực dữ liệu trong không gian tên miền liên tục và riêng biệt.

- Vai trò và hoạt động của Máy chủ Tên miền Bảo mật (Security-Aware Name Server)

Tiêu chuẩn quy định chi tiết về hoạt động của các phần tử có chức năng của một máy chủ tên miền bảo mật-nhận biết (Security-Aware Name Server) như sau:

• Đóng vai trò của một máy chủ tên miền theo quy định tại mục 2.4 của tài liệu [RFC 1034].
• Thực hiện tiếp nhận các truy vấn DNS và gửi các phản hồi DNS tương ứng đến các thực thể yêu cầu.
• Hỗ trợ đầy đủ phần mở rộng kích thước thông báo EDNS0 và bít DO (DNSSEC OK).
• Hỗ trợ các loại bản ghi tài nguyên (RR) và các bít tiêu đề thông báo được quy định cụ thể trong tài liệu [RFC 4033].
• Các chức năng của máy chủ tên miền bảo mật thường thuộc về một Máy chủ tên miền đệ quy bảo mật (Security-Aware Recursive Name Server), tuy nhiên máy chủ tên miền có thẩm quyền có bảo mật cũng có một số yêu cầu tương tự. Quy định chi tiết đối với máy chủ có thẩm quyền được trình bày tại mục 5.1 và đối với máy chủ đệ quy bảo mật tại mục 5.2.

- Vai trò và hành vi của Bộ phân giải Bảo mật (Security-Aware Resolver)

Bộ phân giải bảo mật-nhận biết đóng vai trò quan trọng trong việc gửi truy vấn và xác thực phản hồi trong hệ thống DNSSEC:

• Hoạt động trong vai trò của một bộ phân giải (Resolver) theo quy định tại mục 2.4 của tài liệu [RFC 1034].
• Thực hiện gửi các truy vấn DNS, nhận các phản hồi DNS và hỗ trợ phần mở rộng kích thước thông báo EDNS0 cùng bít DO.
• Sử dụng các loại bản ghi tài nguyên (RR) và bít tiêu đề thông báo quy định trong [RFC 4033] để cung cấp các máy chủ DNSSEC.
• Hành vi của các thực thể bao hàm chức năng của Security-Aware Resolver thường thuộc về Security-Aware Recursive Name Server, nhưng một bộ phân giải độc lập cũng có nhiều yêu cầu tương tự. Các chức năng dành cho máy chủ đệ quy bảo mật được quy định chi tiết tại mục 5.2.

- Cơ chế xác thực bản ghi tài nguyên bằng RRSIG và DNSKEY

Quy trình xác thực được thực hiện chặt chẽ thông qua các bước kiểm tra chữ ký số và khóa công khai:

• Bộ phân giải (Resolver) có thể sử dụng các bản ghi tài nguyên DNSKEY trong tập bản ghi tài nguyên DNSKEY của zone apex và các bản ghi tài nguyên RRSIG từ zone này để xác thực bất kỳ tập bản ghi tài nguyên nào khác trong zone, sau khi đã xác thực thành công tập bản ghi tài nguyên DNSKEY của zone apex (theo mục 7.3).
• Để xác thực các tập bản ghi tài nguyên, phần xác nhận sử dụng một bản ghi tài nguyên RRSIG và bản ghi tài nguyên DNSKEY tương ứng của nó để tiến hành xác thực.
• Bước 1: Resolver kiểm tra bản ghi tài nguyên RRSIG để đảm bảo chữ ký bao trùm tập bản ghi tài nguyên cần xác thực, nằm trong khoảng thời gian hợp lệ và xác định được một bản ghi tài nguyên DNSKEY hợp lệ.
• Bước 2: Phần xác nhận xây dựng dạng chính tắc của dữ liệu được ký bằng cách thêm RRSIG RDATA (ngoại trừ trường Signature) vào dạng chính tắc của tập bản ghi tài nguyên được bao trùm.
• Bước 3: Sử dụng khóa công khai và chữ ký số để tiến hành xác thực dữ liệu đã được ký. Chi tiết các bước này được quy định tại các mục 7.3.1, 7.3.2 và 7.3.3.

- Xác thực sự không tồn tại của bản ghi và xử lý phản hồi dựa trên CNAME

Tiêu chuẩn làm rõ các quy tắc xác thực đối với trường hợp bản ghi không tồn tại hoặc phản hồi chứa CNAME:

• Mục 7.4 (tương ứng mục 5.4 của RFC 4035) chưa quy định cụ thể một thuật toán để kiểm tra các bằng chứng không tồn tại. Thuật toán hiện tại cho phép phần xác nhận dịch một bản ghi tài nguyên NSEC hoặc NSEC3 từ zone nhóm cấp cao (zone cha) để chứng minh sự không tồn tại của một bản ghi tài nguyên trong một zone con.
• Resolver có thể sử dụng các tập bản ghi tài nguyên NSEC được xác thực từ zone để chỉ ra rằng một tập bản ghi tài nguyên không tồn tại trong zone đó (theo mục 7.4).
• Đối với việc xác nhận các trả lời dựa trên hoặc nên được dựa trên CNAME (mục 7, tương ứng mục 5 của RFC 4035): Khi xác nhận một trả lời NOERROR/NODATA, các phần xác nhận bắt buộc phải kiểm tra bit CNAME trong ánh xạ loại của bản ghi tài nguyên NSEC hoặc NSEC3, bên cạnh việc kiểm tra bit dành cho loại truy vấn.

- Quy tắc xử lý chuyển giao và các thuật toán khóa công khai không hỗ trợ

Việc xử lý các chuyển giao không bảo mật và các thuật toán chưa được hỗ trợ được quy định như sau:

• Khi chứng minh một chuyển giao là không bảo mật (mục 7.2, tương ứng mục 5.2 của RFC 4035), phần xác nhận cần kiểm tra sự thiếu vắng của các bit DS và SOA trong ánh xạ loại của NSEC hoặc NSEC3.
• Phần xác nhận cũng phải kiểm tra sự thiếu vắng của bit NS trong bản ghi tài nguyên NSEC hoặc NSEC3 phù hợp để chứng minh thực sự có một chuyển giao, hoặc đảm bảo rằng chuyển giao này được bao trùm bởi một bản ghi tài nguyên NSEC3 có thiết lập cờ Opt-Out.
• Đối với các chuyển giao đến các Zone được ký có thuật toán khóa (KEY) công khai không được hỗ trợ hoàn toàn (được chỉ ra trong các tập bản ghi tài nguyên DS của các zone này): Tiêu chuẩn đưa ra nguyên tắc xử lý nhưng chưa giải quyết rõ ràng cách xử lý các bản ghi tài nguyên DS sử dụng thuật toán tóm tắt bản tin (digest) không được hỗ trợ.
• Nguyên tắc chung: Các bản ghi tài nguyên DS sử dụng thuật toán tóm tắt bản tin không được hỗ trợ hoặc mới lạ phải được đối xử tương tự như các bản ghi tài nguyên DS tham chiếu đến các bản ghi tài nguyên DNSKEY của các thuật toán khóa công khai không được hỗ trợ hoặc mới lạ.

- Quy định về thiết lập bit AD và định vị máy chủ truy vấn DS

Tiêu chuẩn tối ưu hóa khả năng tương thích ngược và hướng dẫn truy vấn hệ thống:

• Về việc thiết lập hoặc xóa bit AD (Authentic Data) trong phản hồi (mục 5.2.3, tương ứng mục 3.2.3 của RFC 4035): Để đảm bảo tính tương thích với các phần xử lý cụt (stub resolver) cũ và các thiết bị trung gian không hiểu hoặc không quan tâm đến bit AD, các phần xử lý xác nhận chỉ nên thiết lập bit AD khi phản hồi thỏa mãn đồng thời các điều kiện tại mục 5.2.3 và yêu cầu truy vấn có chứa bit DO được thiết lập hoặc bit AD được thiết lập.
• Về việc gửi các truy vấn DS đến các máy chủ đối với một zone cha (mục C.8, tương ứng mục C.8 của RFC 4035): Mặc dù mục này thảo luận về việc gửi truy vấn nhưng chưa đưa ra cách thức cụ thể để tìm kiếm các máy chủ này. Các hướng dẫn chi tiết và cụ thể hơn để định vị máy chủ có thể được tham chiếu và trình bày trong mục 6.2 (tương ứng mục 4.2 của RFC 4035).