Tiêu chuẩn Quốc gia TCVN 11818:2017 An toàn hệ thống bảo mật DNS (DNSSEC)-Thay đổi giao thức

TIÊU CHUẨN QUỐC GIA

TCVN 11818:2017

AN TOÀN HỆ THỐNG BẢO MẬT DNS (DNSSEC) THAY ĐỔI TRONG GIAO THỨC

The DNS security extensions - Protocol modifications

Lời nói đầu

TCVN 11818:2017 được xây dựng trên cơ sở tham khảo tiêu chuẩn IETF RFC 4035 (03-2005).

TCVN 11818:2017 do Viện Khoa học Kỹ thuật Bưu Điện biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

AN TOÀN HỆ THỐNG BẢO MẬT DNS (DNSSEC) THAY ĐỔI TRONG GIAO THỨC

The DNS security extensions - Protocol modifications

1  Phạm vi áp dụng

Tiêu chuẩn này đưa ra các thay đổi trong giao thức đối với phần mở rộng bảo mật hệ thống tên miền (DNSSEC).

2  Tài liệu viện dẫn

Tài liệu viện dẫn sau là cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả sửa đổi, bổ sung (nếu có).

RFC1034, Domain names - Concepts and facilities (11-1987) (Tên miền - Các khái niệm và tính năng).

RFC1035, Domain names - Implementation and specification (11-1987) (Tên miền - Cài đặt và đặc tính).

RFC 1122, Requirements for Internet Hosts - Communication Layers (10-1989) (Yêu cầu đối với các máy chủ Internet - Lớp truyền tin).

RFC2181, Clarifications to the DNS Specification (07-1997) (Làm rõ đặc tính DNS).

RFC2460, Internet Protocol, Version 6 (IPv6) Specification (12-1998) (Giao thức Internet, Đặc tính IPv6).

RFC2671, Extension Mechanisms for DNS (EDNS0) (08-1999) (Cơ chế mở rộng cho DNS (EDNS0)).

RFC2672, Non-Terminal DNS Name Redirection (08-1999) (Đổi hướng tên DNS không kết cuối).

RFC 3225, Indicating Resolver Support of DNSSEC (12-2001) (Hỗ trợ Resolver chỉ thị của DNSSEC).

RFC3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements (12-2001), (DNSSEC và Các yêu cầu kích thước thông báo sever/resolver aware).

RFC4033, DNS Security Introduction and Requirements (03-2005) (Yêu cầu và giới thiệu bảo mật DNS).

RFC4034, Resource Records for DNS Security Extensions (03-2005) (Bản ghi tài nguyên cho phần mở rộng bảo mật DNS).

RFC2535, Domain Name System Security Extensions (03-1999) (Phần mở rộng bảo mật hệ thống tên miền).

RFC3655, Redefinition of DNS Authenticated Data (AD) bit (11-2003) (Xác định lại bít Dữ liệu được xác thực DNS (AD)).

3  Thuật ngữ, ký hiệu và chữ viết tắt

3.1  Thuật ngữ

Tiêu chuẩn này sử dụng các thuật ngữ sau:

3.1.1  BAD cache

Bộ nhớ dữ liệu có các chữ ký không hợp lệ.

3.1.2  Cô lập bảo mật (Island of Security)

Zone được ký, được ủy quyền nhưng không có chuỗi xác thực từ zonecha của nó, không có bản ghi DS chứa mã Hash của một bản ghi DNSKEY cho phần riêng biệt được zonecha ủy quyền (xem [RFC 4034]). Một cô lập bảo mật được cấp phát bởi các Security-Aware Name Server, có thể cung cấp các chuỗi xác thực cho các zone con bất kỳ được ủy quyền. Hồi đáp từ một cô lập bảo mật hoặc phần con của nó chỉ được xác thực nếu có một phương pháp đáng tin cậy ngoài băng từ giao thức DNS xác thực các khóa xác thực của nó.

3.1.3  Bộ phân giải gốc bảo mật - nhận biết không hiệu lực (Non-Validating Security-Aware Stub Resolver)

Một bộ phân giải gốc bảo mật-nhận biết tin tưởng một hoặc nhiều máy chủ tên miền đệ quy bảo mật-nhận biết thực hiện hầu hết các công việc được nói đến trong tiêu chuẩn này thiết lập trên đại diện của nó. Nói chung, bộ phân giải gốc bảo mật-nhận biết không hiệu lực sẽ gửi câu hỏi DNS, nhận phản hồi DNS và thiết lập phù hợp với bảo mật kênh cho một máy chủ tên miền đệ quy bảo mật-nhận biết được cung cấp các dịch vụ thay thế cho bộ phân giải bảo mật-nhận biết.

3.1.4  Bộ phân giải gốc không hiệu lực (Non-Validating stub Resolver)

Một thuật ngữ dùng để mô tả bộ phân giải gốc bảo mật-nhận biết không hiệu lực.

3.1.5  Phần mở rộng bảo mật hệ thống tên miền (DNSSEC)

Tập hợp các bản ghi tài nguyên mới và các thay đổi trong giao thức để bổ sung sự xác thực nguồn gốc dữ liệu và sự toàn vẹn dữ liệu cho DNS.

3.1.6  Root Zone

Zone ở Root.

3.1.7  Máy chủ tên miền bảo mật-nhận biết (Security-Aware Name Server)

Phần mở rộng bảo mật DNS được quy định trong tiêu chuẩn này đóng vai trò của một máy chủ tên miền (quy định tại mục 2.4 của [RFC 1034]). Đặc biệt một máy chủ tên miền bảo mật-nhận biết nhận các truy vấn DNS, gửi các phản hồi DNS, hỗ trợ phần mở rộng kích thước thông báo EDNSO và bít DO và hỗ trợ các loại RR và các bít tiêu đề thông báo được quy định trong [RFC 4033].

3.1.8  Máy chủ tên miền đệ quy bảo mật-nhận biết (Security-Aware Recursive Name Server)

Một đơn vị có tác động trong cả máy chủ tên miền bảo mật-nhận biết và các vai trò máy chủ bảo mật-nhận biết.

3.1.9  Bộ phân giải bảo mật-nhận biết (Security-Aware Resolver)

Phần mở rộng bảo mật DNS quy định trong [RFC 4033] hoạt động trong vai trò của một bộ phân giải (quy định tại mục 2.4 của [RFC 1034]). Đặc biệt, một bộ phân giải bảo mật-nhận biết gửi truy vấn DNS, nhận phản hồi DNS, hỗ trợ phần mở rộng kích thước thông báo EDNS0 và bít DO và sử dụng các loại RR và bít tiêu đề thông báo được quy định trong [RFC 4033] để cung cấp các máy chủ DNSSEC.

3.1.10  Bộ phân giải gốc bảo mật-nhận biết (Security-Aware Stub Resolver)

Một đơn vị hoạt động trong vai trò của một bộ phân giải gốc (quy định tại mục 5.3.1 của [RFC 2034]) có thể nhận biết các phần mở rộng bảo mật DNS được quy định trong [RFC 4033] thiết lập để cung cấp các dịch vụ kèm theo không có sẵn từ một bộ phân giải gốc bảo mật-không còn được biết đến. Các bộ phân giải gốc bảo mật-nhận biết có thể là “chứng thực” hoặc “không chứng thực”, tùy thuộc vào bộ phân giải gốc cố gắng xác minh chữ ký DNSSEC trên nó hoặc kỳ vọng một máy chủ tên miền bảo mật-nhận biết thân thiết.

3.1.11  Bảo mật-không còn được biết đến < ...> (Security-Oblivious <anything>)

Là khái niệm trái ngược với bảo mật-nhận biết, nghĩa là không biết, không hỗ trợ bảo mật-nhận biết đối với DNSSEC.

3.1.12  Zone được ký (Signed Zone)

Một zone có các tập bản ghi tài nguyên được ký và chứa các khóa công khai DNS (DNSKEY), chữ ký bản ghi tài nguyên (RRSIG), bảo mật kế tiếp (NSEC) và tùy chọn các bản ghi tài nguyên ký chuyển giao (DS).

3.1.13  Điểm tin cậy Trust Anchor (Trust Anchor)

Một tập bản ghi tài nguyên DNSKEY được cấu hình hoặc mã băm DS RR của một tập bản ghi tài nguyên DNSKEY. Một bộ phân giải bảo mật-nhận biết sử dụng khóa công khai này hoặc mã băm như điểm bắt đầu cho việc xây dựng các chuỗi xác thực cho một phản hồi DNS được ký. Nói chung, bộ phân giải chứng thực phải đạt được giá trị ban đầu của điểm tin cậy Trust Anchor của nó thông qua một số bảo mật hoặc giá trị trung bình có độ tin cậy bên ngoài giao thức DNS. Điểm tin cậy Trust Anchor thể hiện việc bộ phân giải đoán trước vùng để các điểm tin cậy Trust Anchor được ký.

3.1.14  Zone chưa được ký (Unsigned Zone)

Là khái niệm trái ngược Zone được ký.

3.1.15  Chứng thực bộ phân giải gốc bảo mật-nhận biết (Validating Security-Aware stub Resolver)

Một bộ phân giải bảo mật-nhận biết gửi truy vấn ở chế độ đệ quy nhưng thực hiện ký xác nhận của riêng mình thay vì tìm kiếm điểm tin cậy của máy chủ tên miền đệ quy bảo mật-nhận biết theo chiều ngược lại.

3.1.16  Đỉnh vùng (Zone Apex)

Khái niệm tương đồng với định nghĩa điểm chuyển giao. Thuật ngữ dùng để mô tả tên miền phía phân vùng con của một mặt cắt vùng.

3.1.17  Zone Cut

Ranh giới giữa các zone. Ranh giới chia tách zone con (ở bên dưới ranh giới) và zonecha (ở bên trên ranh giới) (RFC 2181).

3.1.18  Zone Key

Khóa của zone.

3.1.19  Zone Transfer

Chuyển thông tin tên miền của zone.

3.1.20  Zone

Phần liên tục và riêng biệt của không gian tên miền trong hệ thống DNS.

3.2  Ký hiệu

Theo mục đích của tiêu chuẩn này, ký tự sau đây được áp dụng:

“I” toán tử ghép

3.3  Chữ viết tắt

Theo mục đích của tiêu chuẩn này, các chữ viết tắt sau đây được áp dụng:

4  Ký zone

DNSSEC đưa ra khái niệm các Zone được ký (Signed Zone). Zone được ký có khóa công khai DNS (DNSKEY), chữ ký bản ghi tài nguyên (RRSIG), bảo mật kế tiếp (NSEC) và tùy chọn các bản ghi tài nguyên ký chuyển giao (DS) tùy theo các nguyên tắc được quy định trong các mục 4.1, 4.2, 4.3 và 4.4 tương ứng. Zone không có các bản ghi tài nguyên theo các nguyên tắc trong mục này là zone chưa được ký.

DNSSEC yêu cầu một thay đổi đối với định nghĩa bản ghi tài nguyên CNAME [RFC 1035]. Mục 4.5 thay đổi bản ghi tài nguyên CNAME để cho phép các bản ghi tài nguyên RRSIG và NSEC được xuất hiện ở cùng một tên miền chủ giống như bản ghi tài nguyên CNAME.

DNSSEC quy định vị trí của hai loại bản ghi tài nguyên mới, NSEC và DS. Các bản ghi tài nguyên này có thể được đặt tại phía cha của zone cut (tức là ở điểm chuyển giao). Điều này là một ngoại lệ đối với việc cấm đưa dữ liệu trong zonecha tại zone cut. Mục 4.6 trình bày sự thay đổi này.

4.1  Các bản ghi tài nguyên DNSKEY trong một zone

Để ký một zone, người quản trị zone đó tạo một hoặc nhiều cặp khóa công khai/riêng và sử dụng (các) khóa riêng để ký các tập bản ghi tài nguyên có thẩm quyền trong zone đó. Đối với mỗi khóa riêng được sử dụng để tạo các bản ghi tài nguyên RRSIG trong một zone, zone này nên có một bản ghi tài nguyên DNSKEY của zone chứa khóa công khai tương ứng. Bản ghi tài nguyên DNSKEY chứa khóa công khai này của zone phải có bit khóa công khai của zone thuộc trường Flags RDATA được thiết lập (xem mục 2.1.1 của RFC 4034). Các khóa công khai liên kết với các hoạt động DNS khác có thể được chứa trong các bản ghi tài nguyên DNSKEY không được xác định là các khóa công khai của zone thì không được sử dụng để kiểm tra các RRSIG.

Nếu người quản trị có ý định sử dụng zone được ký ở mức độ cao hơn (đã ký zone nhưng chưa chuyển giao chuỗi xác thực từ zonecha) thì zone apex phải bao gồm ít nhất một bản ghi tài nguyên DNSKEY được hoạt động như một điểm truy nhập bảo mật của zone. Do đó, điểm truy nhập bảo mật này có thể được sử dụng làm đích của một chuyển giao bảo mật thông qua một bản ghi tài nguyên DS tương ứng trong zonecha (xem RFC 4034)

4.2  Các bản ghi tài nguyên RRSIG trong một zone

Đối với mỗi tập bản ghi tài nguyên có thẩm quyền trong một Zone được ký, phải có ít nhất một bản ghi tài nguyên RRSIG đáp ứng các yêu cầu sau:

- Tên miền chủ RRSIG này giống tên miền chủ tập bản ghi tài nguyên này.

- Lớp RRSIG này giống lớp của tập bản ghi tài nguyên này.

- Trường RRSIG Type Covered giống loại của tập bản ghi tài nguyên này.

- Trường RRSIG Original TTL giống TTL của tập bản ghi tài nguyên này.

- TTL của bản ghi tài nguyên RRSIG này giống TTL của tập bản ghi tài nguyên này.

- Trường RRSIG Labels giống số nhãn trong tên miền chủ của tập bản ghi tài nguyên này, không tính nhãn null root và nhãn phía trái ngoài cùng khi nó là một ký tự đại diện.

- Trường Name của RRSIG Signer giống tên miền của zone chứa tập bản ghi tài nguyên này.

- Các trường RRSIG Algorithm, Name của Signer và Key Tag giống bản ghi tài nguyên DNSKEY chứa khóa công khai của zone tại zone apex.

Quá trình xây dựng một bản ghi tài nguyên RRSIG đối với một tập bản ghi tài nguyên cho trước được trình bày trong RFC 4034. Một tập bản ghi tài nguyên có thể có nhiều bản ghi tài nguyên RRSIG liên kết với nó. Lưu ý rằng, vì bản ghi tài nguyên RRSIG được liên kết chặt với tập bản ghi tài nguyên mà được bao gồm trong chữ ký của chúng, nên bản ghi tài nguyên RRSIG không giống tất cả các loại bản ghi tài nguyên DNS khác, không có tập bản ghi tài nguyên (RRset). Trong đó, các giá trị TTL trong bản ghi tài nguyên RRSIG với tên miền chung không tuân theo các quy tắc của tập bản ghi tài nguyên được trình bày trong RFC 2181.

Một bản ghi tài nguyên RRSIG không được tự ký vì việc ký một bản ghi tài nguyên RRSIG sẽ không có giá trị và sẽ tạo một vòng lặp không xác định trong quá trình ký.

Tập bản ghi tài nguyên NS xuất hiện tại tên miền của zone apex phải được ký nhưng các tập bản ghi tài nguyên NS xuất hiện tại các điểm chuyển giao (tức là các tập bản ghi tài nguyên NS trong zonecha mà chuyển giao tên miền này cho các máy chủ tên miền của zone con) không được ký. Các tập bản ghi tài nguyên được liên kết với sự chuyển giao (glue address) sẽ không được ký.

Phải có một RRSIG đối với mỗi tập bản ghi tài nguyên sử dụng ít nhất một DNSKEY của mỗi thuật toán trong tập bản ghi tài nguyên DNSKEY của zone apex, tập bản ghi tài nguyên DNS của zone apex này phải được tự ký bằng mỗi thuật toán xuất hiện trong tập bản ghi tài nguyên DS được đặt ở phía cha chuyển giao (nếu có).

4.3  Các bản ghi tài nguyên NSEC trong một zone

Mỗi tên miền chủ trong zone có dữ liệu có thẩm quyền hoặc một tập bản ghi tài nguyên NS của điểm chuyển giao phải có một bản ghi tài nguyên NSEC. Định dạng của các bản ghi tài nguyên NSEC và quá trình xây dựng bản ghi tài nguyên NSEC đối với một tên miền cho trước được trình bày trong RFC 4034.

Giá trị TTL đối với bất kỳ bản ghi tài nguyên NSEC nên giống trường giá trị TTL tối thiểu trong bản ghi tài nguyên SOA của zone này.

Một bản ghi tài nguyên NSEC (và tập bản ghi tài nguyên RRSIG của nó) phải không được là tập bản ghi tài nguyên duy nhất tại bất kỳ tên miền chủ cụ thể nào. Đó là, quá trình ký không tạo bản ghi tài nguyên NSEC hoặc RRSIG của node tên miền chủ mà chưa phải là tên miền chủ của bất kỳ tập bản ghi tài nguyên nào, trước khi zone đó được ký. Lý do chính của điều này là muốn sự nhất quán không gian tên miền giữa các phiên bản được ký và không được ký trong cùng một zone, và làm giảm nguy cơ phản hồi mâu thuẫn trong các máy chủ đệ quy không có bảo mật.

Ánh xạ loại của mỗi bản ghi tài nguyên NSEC trong một Zone được ký phải chỉ ra sự có mặt của cả chính bản ghi tài nguyên NSEC này và bản ghi tài nguyên RRSIG tương ứng.

Sự khác nhau giữa bộ các tên miền chủ có yêu cầu các bản ghi tài nguyên RRSIG và bộ các tên miền chủ có yêu cầu các bản ghi tài nguyên NSEC là tinh vi và đáng nêu rõ. Các bản ghi tài nguyên RRSIG có ở các tên miền chủ của tất cả các tập bản ghi tài nguyên có thẩm quyền. Các bản ghi tài nguyên NSEC có ở các tên miền chủ của tất cả các tên miền mà Zone được ký có thẩm quyền đối với chúng và ở các tên miền chủ của những chuyển giao từ Zone được ký sang zone con của nó. Các bản ghi tài nguyên NSEC hoặc RRSIG không có (trong zonecha) ở các tên miền chủ của các tập bản ghi tài nguyên địa chỉ liên kết. Tuy nhiên, chú ý rằng sự khác biệt này chỉ là phần dễ thấy nhất trong quá trình ký zone vì các tập bản ghi tài nguyên NSEC là dữ liệu có thẩm quyền và do đó được ký. Do đó, bất kỳ tên miền chủ nào có một tập bản ghi tài nguyên NSEC cũng sẽ có các bản ghi tài nguyên RRSIG trong Zone được ký.

Việc ánh xạ đối với bản ghi tài nguyên NSEC ở điểm chuyển giao yêu cầu sự quan tâm đặc biệt. Các bít tương ứng tập bản ghi tài nguyên NS chuyển giao và bất kỳ các tập bản ghi tài nguyên mà zonecha có dữ liệu có thẩm quyền đối với chúng phải được thiết lập; các bit tương ứng bất kỳ tập bản ghi tài nguyên không là NS mà phía cha không có thẩm quyền đối với chúng phải xóa.

4.4  Các bản ghi tài nguyên DS trong một zone

Bản ghi tài nguyên DS thiết lập các chuỗi xác thực giữa các zone DNS. Tập bản ghi tài nguyên DS nên có tại điểm chuyển giao khi zone con được ký. Tập bản ghi tài nguyên DS có thể chứa nhiều bản ghi tài nguyên, mỗi bản ghi tài nguyên tham chiếu đến một khóa công khai trong zone con được sử dụng để kiểm tra các RRSIG trong zone đó. Tất cả các tập bản ghi tài nguyên DS trong một zone phải được ký và các tập bản ghi tài nguyên DS không được xuất hiện tại zone apex.

Một bản ghi tài nguyên DS nên chỉ đến một bản ghi tài nguyên DNSKEY có trong tập bản ghi tài nguyên DNSKEY của zone apex của phía con và tập bản ghi tài nguyên DNSKEY của zone apex của phía con này nên được ký bằng một khóa riêng tương ứng. Các bản ghi tài nguyên DS không đáp ứng các điều kiện này không được dùng để xác nhận nhưng vì bản ghi tài nguyên DS này và bản ghi tài nguyên DNSKEY tương ứng của nó trong các zone khác nhau và vì DNS không quy định rõ, những điểm không thống nhất tạm thời có thể xảy ra.

TTL của một tập bản ghi tài nguyên DS nên phù hợp TTL của tập bản ghi tài nguyên NS chuyển giao (tức là tập bản ghi tài nguyên NS ở cùng zone chứa tập bản ghi tài nguyên DS).

Việc xây dựng một bản ghi tài nguyên DS yêu cầu sự hiểu biết về bản ghi tài nguyên DNSKEY tương ứng trong zone con, điều này chỉ ra mối liên hệ giữa các zonecha và con. Mối liên hệ này là một vấn đề vận hành không được đề cập trong tiêu chuẩn này.

4.5  Những thay đổi đối với bản ghi tài nguyên CNAME

Khi một tập bản ghi tài nguyên CNAME có ở tên miền trong một Zone được ký, phải có các tập bản ghi tài nguyên RRSIG và NSEC tương ứng ở tên miền đó. Đồng thời cho phép một tập bản ghi tài nguyên KEY ở tên miền đó để cập nhật bảo mật động (RFC 3007). Các loại khác không được có ở tên miền đó.

Điều này là một thay đổi so với định nghĩa gốc của CNAME trong RFC 1034. Định nghĩa gốc của bản ghi tài nguyên CNAME không cho phép bất kỳ các loại khác cùng xuất hiện với bản ghi tài nguyên CNAME nhưng một Zone được ký yêu cầu các bản ghi tài nguyên NSEC và RRSIG đối với mỗi tên miền có thẩm quyền. Để giải quyết điểm không đồng nhất này, tiêu chuẩn này thay đổi định nghĩa của bản ghi tài nguyên CNAME để cho phép nó cùng xuất hiện với các bản ghi tài nguyên NSEC và RRSIG.

4.6  Các loại bản ghi tài nguyên DNSSEC xuất hiện ở zone cut

DNSSEC đưa ra hai loại bản ghi tài nguyên mới thường xuất hiện ở phía cha của mặt cắt. Ở phía cha của zone cut (tức là ở điểm chuyển giao), yêu cầu các bản ghi tài nguyên NSEC ở tên miền chủ. Một bản ghi tài nguyên DS cũng có thể có khi zone được chuyển giao này được ký và cố gắng có một chuỗi xác thực đối với zonecha. Điều này là một ngoại lệ đối với tiêu chuẩn DNS gốc (RFC 1034), nó quy định rằng chỉ các tập bản ghi tài nguyên NS có thể xuất hiện ở phía cha của zone cut.

4.7  Ví dụ một zone có bảo mật

Phụ lục A trình bày một ví dụ hoàn chỉnh của một Zone được ký nhỏ.

5  Hoạt động

Mục này quy định hoạt động của các phần tử có các chức năng Security-Aware Name Server. Trong nhiều trường hợp, các chức năng như vậy sẽ thuộc một Security-Aware Recursive Name Server nhưng một máy chủ tên miền có thẩm quyền có bảo mật có một số các yêu cầu tương tự. Các chức năng quy định đối với các Security-Aware Recursive Name Server được trình bày trong mục 5.2; các chức năng quy định đối với các máy chủ có thẩm quyền được trình bày trong mục 5.1.

Trong phần tiếp theo, các thuật ngữ “SNAME”, “SCLASS" và “STYPE” được tham chiếu theo RFC 1034.

Security-Aware Name Server phải hỗ trợ EDNS0 (RFC 2671) phần mở rộng kích cỡ bản tin phải hỗ trợ kích cỡ bản tin tối thiểu 1220 octet và nên hỗ trợ kích cỡ bản tin 4000 octet. Vì các gói tin IPv6 chỉ có thể được máy tính chủ nguồn phân đoạn, Security-Aware Name Server nên thực hiện các bước để đảm bảo rằng các gói thông tin UDP nó truyền qua IPv6 được phân đoạn ở mức MTU IPv6 tối thiểu nếu cần trừ phi biết MTU của tuyến. Tham khảo RFC 1122, RFC 2460 và RFC 3226 về các vấn đề phân đoạn và kích cỡ gói tin.

Một Security-Aware Name Server nhận một truy vấn DNS không chứa EDNS OPT giả-bản ghi tài nguyên hoặc có bit DO trống phải đáp ứng các bản ghi tài nguyên RRSIG, DNSKEY và NSEC như đáp ứng bất kỳ tập bản ghi tài nguyên khác và không được thực hiện bất kỳ hành động bổ sung được trình bày dưới đây. Vì loại bản ghi tài nguyên DS có thuộc tính khác thường là chỉ xuất hiện trong zonecha ở các điểm chuyển giao, các bản ghi tài nguyên DS luôn luôn yêu cầu một hành động đặc biệt nào đó như được trình bày trong mục 5.1.4.1.

Các Security-Aware Name Server nhận các truy vấn rõ ràng về các loại bản ghi tài nguyên bảo mật phù hợp nội dung của nhiều hơn một zone mà nó phục vụ (ví dụ các bản ghi tài nguyên NSEC và RRSIG ở trên và dưới điểm chuyển giao nơi máy chủ này có thẩm quyền đối với cả hai zone) nên hành xử nhất quán. Máy chủ tên miền này có thể trả về một trong các nội dung sau miễn là trả lời này luôn nhất quán đối với mỗi truy vấn đến máy chủ tên miền này:

- Các tập bản ghi tài nguyên trên điểm chuyển giao.

- Các tập bản ghi tài nguyên dưới điểm chuyển giao

- Cả hai tập bản ghi tài nguyên trên và dưới điểm chuyển giao.

- Phần trả lời trống (không có bản ghi tài nguyên).

- Một trả lời khác nào đó.

- Một lỗi.

DNSSEC phân bố hai bít mới trong phần mào đầu bản tin DNS: bit CD (Checking Disabled) và bit AD (Authentic Data). Bit CD được các Resolver điều khiển; một Security-Aware Name Server phải sao chép bit CD từ một truy vấn thành một trả lời tương ứng. Bit AD được các máy chủ tên miền điều khiển; Security-Aware Name Server phải bỏ qua việc thiết lập bit AD trong các truy vấn. Xem các mục 5.1.6, 5.2.2, 5.2.3, 6 và 6.9 về hành vi của các bit này.

Security-Aware Name Server đồng bộ các bản ghi tài nguyên CNAME từ các bản ghi tài nguyên DNAME như được trình bày trong RFC 2672 không nên tạo các chữ ký đối với các bản ghi tài nguyên CNAME được đồng bộ này.

5.1  Các máy chủ tên miền có thẩm quyền

Dựa vào việc nhận một truy vấn liên quan có bit DO EDNS OPT giả-bản ghi tài nguyên (RFC 2671) được thiết lập, máy chủ tên miền có thẩm quyền có bảo mật đối với một Zone được ký phải chứa các bản ghi tài nguyên RRSIG, NSEC và DS bổ sung tuân theo các nguyên tắc sau:

- Các bản ghi tài nguyên RRSIG có thể được sử dụng để xác thực một trả lời phải được chứa trong trả lời này tuân theo các nguyên tắc trong mục 5.1.1.

- Các bản ghi tài nguyên NSEC có thể được sử dụng để cung cấp xác nhận từ chối sự tồn tại phải được chứa trong trả lời này tuân theo một cách tự động các nguyên tắc trong mục 5.1.3.

- Tập bản ghi tài nguyên DS hoặc một bản ghi tài nguyên NSEC chỉ ra rằng không có bản ghi tài nguyên DS nào tồn tại phải được chứa trong các tham chiếu một cách tự động tuân theo các nguyên tắc trong mục 5.1.4.

Các nguyên tắc này chỉ áp dụng cho các trả lời trong đó các cú pháp truyền thông tin về sự có hoặc không có các bản ghi tài nguyên. Do đó, các nguyên tắc này không đưa ra các trả lời giống như “Không được thực hiện” đối với RCODE hay “Bị từ chối” đối với RCODE 5.

DNSSEC không thay đổi giao thức DNS zone transfer. Mục 5.1.5 trình bày các yêu cầu về zone transfer.

5.1.1  Các bản ghi tài nguyên RRSIG trong một trả lời

Khi trả lời một truy vấn có bit DO được thiết lập, máy chủ tên miền có thẩm quyền có bảo mật nên cố gắng gửi các bản ghi tài nguyên RRSIG mà Security-Aware Resolver có thể sử dụng để xác thực các tập bản ghi tài nguyên này trong trả lời này. Một máy chủ tên miền nên thực hiện mọi cố gắng để giữ tập bản ghi tài nguyên này và (các) RRSIG liên kết của nó trong một trả lời. Việc chứa các bản ghi tài nguyên RRSIG trong một trả lời tuân theo các nguyên tắc sau:

- Khi đặt một tập bản ghi tài nguyên được ký trong phần trả lời, máy chủ tên miền này cũng phải đặt các bản ghi tài nguyên RRSIG của nó trong phần trả lời đó. Các bản ghi tài nguyên RRSIG này có mức ưu tiên bao hàm cao hơn bất kỳ các tập bản ghi tài nguyên khác có thể phải được bao hàm. Khi không gian không cho phép bao hàm các bản ghi tài nguyên RRSIG này, máy chủ tên miền này phải thiết lập bit TC.

- Khi đặt một tập bản ghi tài nguyên được ký trong phần thẩm quyền, máy chủ tên miền cũng phải đặt các bản ghi tài nguyên RRSIG của nó trong phần thẩm quyền các bản ghi tài nguyên RRSIG này có mức ưu tiên bao hàm cao hơn bất kỳ các tập bản ghi tài nguyên khác có thể phải được bao hàm. Khi không gian không cho phép bao hành các bản ghi tài nguyên RRSIG này, máy chủ tên miền phải thiết lập bit TC.

- Khi đặt một tập bản ghi tài nguyên được ký trong phần bổ sung, máy chủ tên miền cũng phải đặt các bản ghi tài nguyên RRSIG của nó trong phần bổ sung. Khi không gian không cho phép bao hàm cả tập bản ghi tài nguyên này và các bản ghi tài nguyên RRSIG liên kết của nó, máy chủ tên miền có thể giữ lại tập bản ghi tài nguyên này và thả các bản ghi tài nguyên RRSIG. Khi điều này xảy ra, máy chủ tên miền không được thiết lập bit TC vì các bản ghi tài nguyên RRSIG đã không phù hợp.

5.1.2  Các bản ghi tài nguyên DNSKEY trong một trả lời

Khi trả lời một truy vấn có bit DO được thiết lập và yêu cầu các bản ghi tài nguyên SOA hoặc NS ở zone apex được ký, máy chủ tên miền có thẩm quyền có bảo mật đối với zone đó có thể trả về tập bản ghi tài nguyên DNSKEY của zone apex này trong phần bổ sung. Trong trường hợp này, tập bản ghi nguyên DNSKEY và các bản ghi tài nguyên RRSIG liên kết có mức ưu tiên thấp hơn bất kỳ thông tin khác được đặt trong phần bổ sung. Máy chủ tên miền không nên bao hàm tập bản ghi tài nguyên DNSKEY này trừ khi có đủ không gian trong bản tin trả lời dành cho cả tập bản ghi tài nguyên DNSKEY và (các) bản ghi tài nguyên RRSIG liên kết của nó. Khi không có đủ không gian để bao hàm DNSKEY và các bản ghi tài nguyên RRSIG này, máy chủ tên miền phải loại bỏ chúng và không được thiết lập bit TC vì các bản ghi tài nguyên này đã không phù hợp (xem mục 5.1.1)

5.1.3  Các bản ghi tài nguyên NSEC trong một trả lời

Khi trả lời một truy vấn có bit DO được thiết lập, máy chủ tên miền có thẩm quyền có bảo mật đối với zone đó phải bao hàm các bản ghi tài nguyên NSEC trong một trong các trường hợp sau:

Không có dữ liệu: Zone chứa các tập bản ghi tài nguyên phù hợp hoàn toàn <SNAME, SCLASS> nhưng không chứa bất kỳ tập bản ghi tài nguyên phù hợp hoàn toàn <SNAME, SCLASS, STYPE>

Lỗi tên miền: Zone không chứa bất kỳ tập bản ghi tài nguyên phù hợp <SNAME, SCLASS> một cách hoàn toàn hoặc thông qua phần mở rộng tên miền ký tự đại diện.

Trả lời ký tự đại diện: Zone không chứa bất kỳ tập bản ghi tài nguyên phù hợp hoàn toàn <SNAME, SCLASS> nhưng chứa một tập bản ghi tài nguyên phù hợp <SNAME, SCLASS, STYPE> thông qua phần mở rộng tên miền ký tự đại diện.

Không có dữ liệu ký tự đại diện: Zone không chứa bất kỳ tập bản ghi tài nguyên phù hợp hoàn toàn <SNAME, SCLASS> và chứa một hoặc nhiều tập bản ghi tài nguyên phù hợp <SNAME, SCLASS> thông qua phần mở rộng tên miền ký tự đại diện nhưng không chứa bất kỳ tập bản ghi tài nguyên phù hợp <SNAME, SCLASS, STYPE> thông qua phần mở rộng tên miền ký tự đại diện.

Trong mỗi trường hợp này, máy chủ tên miền bao hàm các bản ghi tài nguyên NSEC trong trả lời để chỉ ra rằng sự phù hợp hoàn toàn đối với <SNAME, SCLASS, STYPE> không có trong zone này và rằng trả lời này máy chủ tên miền trả về là đúng với dữ liệu trong zone này.

5.1.3.1  Các bản ghi tài nguyên NSEC: Trả lời không có dữ liệu

Khi zone chứa các tập bản ghi tài nguyên phù hợp <SNAME, SCLASS> nhưng không chứa tập bản ghi tài nguyên phù hợp <SNAME, SCLASS, STYPE> thì máy chủ tên miền phải bao hàm bản ghi tài nguyên NSEC dành cho <SNAME, SCLASS> cùng với (các) bản ghi tài nguyên RRSIG liên kết của nó trong phần thẩm quyền của trả lời (xem mục 5.1.1). Khi không gian không cho phép bao hàm bản ghi tài nguyên NSEC hoặc (các) bản ghi tài nguyên RRSIG liên kết của nó, máy chủ tên miền phải thiết lập bit TC (xem mục 5.1.1).

Khi tên miền tìm kiếm tồn tại, phần mở rộng tên miền ký tự đại diện không áp dụng đối với truy vấn này và một bản ghi tài nguyên NSEC được ký duy nhất đủ để chỉ ra rằng loại bản ghi tài nguyên được yêu cầu không tồn tại.

5.1.3.2  Các bản ghi tài nguyên NSEC: Trả lời lỗi tên miền

Khi zone không chứa bất kỳ tập bản ghi tài nguyên phù hợp <SNAME, SCLASS> hoàn toàn hoặc thông qua phần mở rộng tên miền ký tự đại diện thì máy chủ tên miền phải bao hàm các bản ghi tài nguyên NSEC sau trong phần thẩm quyền cùng với các bản ghi tài nguyên RRSIG liên kết của nó:

- Một bản ghi tài nguyên NSEC chỉ ra rằng không có phù hợp hoàn toàn dành cho <SNAME, SCLASS>.

- Một bản ghi tài nguyên NSEC chỉ ra rằng zone này không chứa các tập bản ghi tài nguyên phù hợp <SNAME, SCLASS> thông qua phần mở rộng tên miền ký tự đại diện.

Trong một số trường hợp, một bản ghi tài nguyên NSEC có thể chỉ ra cả hai điều này. Khi đó, máy chủ tên miền chỉ nên bao hàm bản ghi tài nguyên NSEC này và (các) bản ghi tài nguyên RRSIG của nó trong phần thẩm quyền.

Khi không gian không cho phép bao hàm các bản ghi tài nguyên NSEC và RRSIG này, máy chủ tên miền phải thiết lập bit TC (xem mục 5.1.1)

Các tên miền chủ của các bản ghi tài nguyên NSEC và RRSIG này không phụ thuộc vào phần mở rộng tên miền ký tự đại diện khi các bản ghi tài nguyên này được bao hàm trong phần thẩm quyền của trả lời.

Chú ý rằng dạng trả lời bao hàm các trường hợp trong đó SNAME tương ứng một tên miền trống không kết thúc trong zone đó (một tên miền không là tên miền chủ đối với bất kỳ tập bản ghi tài nguyên nhưng là tên miền cha của một hoặc nhiều tập bản ghi tài nguyên)

5.1.3.3  Các bản ghi tài nguyên NSEC: Trả lời trả lời ký tự đại diện

Khi zone này không chứa bất kỳ các tập bản ghi tài nguyên phù hợp hoàn toàn <SNAME, SCLASS> nhưng chứa một tập bản ghi tài nguyên phù hợp <SNAME, SCLASS, STYPE> thông qua phần mở rộng tên miền ký tự đại diện, máy chủ tên miền này phải chứa trả lời có phần mở rộng ký tự đại diện và các bản ghi tài nguyên RRSIG có phần mở rộng ký tự đại diện tương ứng trong phần trả lời và phải chứa trong phần thẩm quyền một bản ghi tài nguyên NSEC và (các) bản ghi tài nguyên RRSIG tương ứng chỉ ra rằng zone này không chứa một phù hợp gần với <SNAME, SCLASS>. Khi không gian không cho phép bao hàm trả lời, các bản ghi tài nguyên NSEC và RRSIG, máy chủ tên miền này phải thiết lập bit TC (xem mục 5.1.1).

5.1.3.4  Các bản ghi tài nguyên NSEC: Trả lời không có dữ liệu ký tự đại diện

Trường hợp này là sự kết hợp của các trường hợp trước. Zone này không chứa sự phù hợp hoàn toàn đối với <SNAME, SCLASS> và mặc dù zone này chứa các tập bản ghi tài nguyên phù hợp <SNAME, SCLASS> thông qua phần mở rộng ký tự đại diện, không có tập bản ghi tài nguyên nào phù hợp STYPE. Máy chủ tên miền phải bao hàm các bản ghi tài nguyên NSEC sau trong phần thẩm quyền cùng với các bản ghi tài nguyên RRSIG liên kết của chúng:

- Một bản ghi tài nguyên NSEC chỉ ra rằng không có tập bản ghi tài nguyên nào phù hợp STYPE ở tên miền chủ ký tự đại diện mà phù hợp <SNAME, SCLASS> thông qua phần mở rộng ký tự đại diện.

- Một bản ghi tài nguyên NSEC chỉ ra rằng không có tập bản ghi tài nguyên nào trong zone này phù hợp gần với <SNAME, SCLASS>.

Trong một số trường hợp, một bản ghi tài nguyên NSEC đơn có thể chỉ ra cả hai điều này. Khi đó, máy chủ tên miền chỉ nên bao hàm bản ghi tài nguyên NSEC này và (các) bản ghi tài nguyên RRSIG của nó trong phần thẩm quyền.

Tên miền chủ của các bản ghi tài nguyên NSEC và RRSIG này không phụ thuộc vào phần mở rộng tên miền ký tự đại diện khi các bản ghi tài nguyên này được bao hàm trong phần thẩm quyền của trả lời.

Khi không gian không cho phép bao hàm các bản ghi tài nguyên NSEC và RRSIG này, máy chủ tên miền phải thiết lập bit TC (xem mục 5.1.1).

5.1.3.5  Tìm các bản ghi tài nguyên NSEC đúng

Như được trình bày ở trên, có một số tình huống trong đó máy chủ tên miền có thẩm quyền có bảo mật phải đặt một bản ghi tài nguyên NSEC để chỉ ra rằng không có tập bản ghi tài nguyên nào phù hợp một SNAME cụ thể hiện có. Việc đặt một bản ghi tài nguyên NSEC trong một zone có thẩm quyền như vậy tương đối đơn giản, ít nhất về mặt khái niệm. Phần thảo luận sau giả thiết rằng máy chủ tên miền này có thẩm quyền đối với zone chứa các tập bản ghi tài nguyên không tồn tại phù hợp SNAME. Thuật toán sau được viết để làm rõ dù không hiệu quả.

Để tìm NSEC chỉ ra rằng không có tập bản ghi tài nguyên nào phù hợp tên miền N tồn tại trong zone Z chứa chúng, xây dựng một câu S bao gồm các tên miền chủ của mỗi tập bản ghi tài nguyên trong Z, được sắp xếp theo thứ tự chính tắc (RFC 4034) không có tên miền trùng lặp. Tìm tên miền M đứng ngay trước N trong S khi bất kỳ tập bản ghi tài nguyên có tên miền chủ N tồn tại. M là tên miền chủ của bản ghi tài nguyên NSEC chỉ ra rằng không có tập bản ghi tài nguyên nào tồn tại có tên miền chủ N.

Thuật toán tìm bản ghi tài nguyên NSEC này chỉ ra rằng một tên miền cho trước không được bất kỳ ký tự đại diện có thể áp dụng nào che đậy là tương tự nhưng yêu cầu thêm một bước. Nói một cách chính xác hơn, thuật toán tìm NSEC chỉ ra rằng không tập bản ghi tài nguyên nào tồn tại có tên miền ký tự đại diện có thể áp dụng là giống thuật toán tìm bản ghi tài nguyên NSEC chỉ ra rằng các tập bản ghi tài nguyên có bất kỳ một tên miền chủ khác không tồn tại. Phần thiếu là phương pháp xác định tên miền của ký tự đại diện có thể áp dụng không tồn tại. Thực tế, điều này là dễ dàng vì máy chủ tên miền có thẩm quyền đã tìm kiếm sự có mặt của tên miền ký tự đại diện này như một phần của bước (1) (c) của thuật toán tìm kiếm chuẩn được trình bày trong mục 4.3.2 của RFC 1034.

5.1.4  Các bản ghi tài nguyên DS trong một trả lời

Khi trả lời một truy vấn có bít DO được thiết lập, máy chủ tên miền có thẩm quyền có bảo mật trả về một tham chiếu bao hàm dữ liệu DNSSEC cùng với tập bản ghi tài nguyên NS này.

Khi một tập bản ghi tài nguyên DS có tại điểm chuyển giao, máy chủ tên miền phải trả về cả tập bản ghi tài nguyên DS và (các) bản ghi tài nguyên RRSIG liên kết của nó trong phần thẩm quyền cùng với tập bản ghi tài nguyên NS này.

Khi không có tập bản ghi tài nguyên DS tại điểm chuyển giao, máy chủ tên miền phải trả về cả bản ghi tài nguyên NSEC chỉ ra rằng tập bản ghi tài nguyên DS không có và (các) bản ghi tài nguyên RRSIG liên kết của bản ghi tài nguyên NSEC này cùng với tập bản ghi tài nguyên NS. Máy chủ tên miền phải đặt tập bản ghi tài nguyên NS trước tập bản ghi tài nguyên NSEC và (các) bản ghi tài nguyên RRSIG liên kết của nó.

Việc bao hàm các bản ghi tài nguyên DS, NSEC và RRSIG làm tăng kích cỡ của các bản tin tham chiếu và có thể làm cho một vài hoặc tất cả các bản ghi tài nguyên liên kết bị loại bỏ. Khi không gian không cho phép bao hàm tập bản ghi tài nguyên DS hoặc NSEC và các bản ghi tài nguyên RRSIG liên kết, máy chủ tên miền phải thiết lập bit TC (xem mục 5.1.1)

5.1.4.1  Trả lời các truy vấn về các bản ghi tài nguyên DS

Loại bản ghi tài nguyên DS là khác thường khi nó chỉ xuất hiện về phía zonecha của zone cut. Ví dụ, tập bản ghi tài nguyên DS để chuyển giao “foo.example” được chứa trong zone “example” mà không phải là zone “too.example”. Điều này yêu cầu các nguyên tắc xử lý đặc biệt đối với cả các máy chủ tên miền và Resolver vì máy chủ tên miền đối với zone con có thẩm quyền đối với tên miền này ở zone cut này theo các nguyên tắc DNS chuẩn nhưng zone con không chứa tập bản ghi tài nguyên DS này.

Security-Aware Resolver gửi các truy vấn đến zonecha khi tìm kiếm một bản ghi tài nguyên DS ở điểm chuyển giao (xem mục 6.2). Tuy nhiên, cần các nguyên tắc đặc biệt để tránh làm nhầm lẫn các Security-Oblivious Resolver, chúng có thể bị liên quan trong việc xử lý một truy vấn như vậy (ví dụ, trong một cấu hình mạng có bắt buộc một Security-Aware Resolver chuyển các truy vấn của nó qua một security-oblivious recursive name server). Phần còn lại của mục này trình bày cách một Security-Aware Name Server xử lý các truy vấn theo trật tự để tránh xảy ra vấn đề này.

Nhu cầu đối với một việc xử lý đặc biệt của một Security-Aware Name Server chỉ phát sinh khi tất cả các điều kiện sau đều thỏa mãn:

- Máy chủ tên miền đã nhận được một truy vấn đối với tập bản ghi tài nguyên DS tại zone cut.

- Máy chủ tên miền có thẩm quyền đối với zone con.

- Máy chủ tên miền không có thẩm quyền đối với zonecha.

- Máy chủ tên miền không thực hiện đệ quy. Trong tất cả các trường hợp khác, máy chủ tên miền có cách để có tập bản ghi tài nguyên DS này hoặc không cần có tập bản ghi tài nguyên DS này theo các nguyên tắc xử lý không DNSSEC, do đó máy chủ tên miền có thể trả về tập bản ghi tài nguyên DS hoặc một trả lời lỗi theo các nguyên tắc xử lý chuẩn này.

Tuy nhiên, khi tất cả các điều kiện trên được thỏa mãn, máy chủ tên miền có thẩm quyền đối với SNAME nhưng không thể cung cấp tập bản ghi tài nguyên được yêu cầu này. Trong trường hợp này, máy chủ tên miền phải trả về một trả lời có thẩm quyền “không có dữ liệu” chỉ ra rằng tập bản ghi tài nguyên DS không tồn tại trong zone apex của zone con. Xem phụ lục B.8 về một ví dụ của một trả lời như vậy.

5.1.5  Trả lời các truy vấn đối với loại AXFR hoặc IXFR

DNSSEC không làm thay đổi quá trình DNS zone transfer. Một Zone được ký sẽ chứa các bản ghi tài nguyên RRSIG, DNSKEY và DS nhưng các bản ghi tài nguyên này không có ý nghĩa đặc biệt đối với một hoạt động của zone transfer.

Không yêu cầu một máy chủ tên miền có thẩm quyền phải kiểm tra xem một zone đã được ký đúng trước khi gửi hoặc nhận một zone transfer.

Tuy nhiên, máy chủ tên miền có thẩm quyền có thể lựa chọn để hủy bỏ một zone transfer khi zone này không thỏa mãn bất kỳ các yêu cầu về ký được trình bày trong mục 4. Mục đích chính của zone transfer là để đảm bảo rằng tất cả các máy chủ tên miền có các bản sao chép giống nhau của zone. Một máy chủ tên miền có thẩm quyền lựa chọn thực hiện việc xác nhận zone của chính nó không được loại bỏ một số bản ghi tài nguyên và chấp nhận các bản ghi tài nguyên khác một cách có lựa chọn.

Các tập bản ghi tài nguyên DS chỉ xuất hiện ở phía cha của zone cut và là dữ liệu có thẩm quyền trong zonecha. Như với bất kỳ tập bản ghi tài nguyên có thẩm quyền khác, tập bản ghi tài nguyên DS phải được bao hàm trong các zone transfer của zone mà trong zone đó tập bản ghi tài nguyên này là dữ liệu có thẩm quyền. Trong trường hợp tập bản ghi tài nguyên DS, zone đó là zonecha.

Các bản ghi tài nguyên NSEC xuất hiện trong cả zonecha và con ở zone cut và là dữ liệu có thẩm quyền trong cả zonecha và con. Các bản ghi tài nguyên NSEC phía cha và con ở zone cut không giống nhau vì bản ghi tài nguyên NSEC trong zone apex của zone con sẽ luôn luôn chỉ ra sự tồn tại của bản ghi tài nguyên SOA của zone con trong khi bản ghi tài nguyên NSEC phía cha ở zone cut sẽ không bao giờ chỉ ra sự tồn tại của một bản ghi tài nguyên SOA. Như với bất kỳ các bản ghi tài nguyên có thẩm quyền khác, các bản ghi tài nguyên NSEC phải được bao hàm trong các zone transfer của zone mà trong zone đó chúng là dữ liệu có thẩm quyền bản ghi tài nguyên NSEC phía cha ở zone cut phải được bao hàm trong các zone transfer của zonecha và NSEC ở zone apex của zone con phải được bao hàm trong các zone transfer của zone con.

Các bản ghi tài nguyên RRSIG xuất hiện trong cả zonecha và con ở zone cut và có thẩm quyền trong mỗi zone chứa tập bản ghi tài nguyên có thẩm quyền này mà bản ghi tài nguyên RRSIG cung cấp chữ ký này. Tức là, bản ghi tài nguyên RRSIG dành cho một tập bản ghi tài nguyên DS hoặc một bản ghi tài nguyên NSEC phía cha ở zone cut sẽ có thẩm quyền trong zonecha và bản ghi tài nguyên RRSIG dành cho tập bản ghi tài nguyên bất kỳ trong zone apex của zone con sẽ có thẩm quyền trong zone con. Các bản ghi tài nguyên RRSIG phía cha và con ở zone cut sẽ không bao giờ giống nhau vì trường Name của Signer của một bản ghi tài nguyên RRSIG trong zone apex của zone con sẽ chỉ ra một bản ghi tài nguyên DNSKEY trong zone apex của zone con trong khi trường này của bản ghi tài nguyên RRSIG phía cha ở zone cut sẽ chỉ ra một bản ghi tài nguyên DNSKEY trong zone apex của zonecha. Như với bất kỳ các bản ghi tài nguyên có thẩm quyền khác, các bản ghi tài nguyên RRSIG phải được bao hàm trong các zone transfer của zone mà trong zone đó chúng là dữ liệu có thẩm quyền.

5.1.6  Các bit AD và CD trong một trả lời có thẩm quyền

Các bit CD và AD được thiết kế để sử dụng trong truyền tin giữa các Security-Aware Resolver và các Security-Aware Recursive Name Server. Các bit này phần lớn không liên quan đến quá trình truy vấn bởi các máy chủ tên miền có thẩm quyền có bảo mật.

Một Security-Aware Name Server không thực hiện xác thực chữ ký đối với dữ liệu có thẩm quyền trong quá trình truy vấn, thậm chí khi bit CD trống. Security-Aware Name Server nên xóa bit CD này khi tạo một trả lời có thẩm quyền.

Security-Aware Name Server không được thiết lập bit AD trong một trả lời trừ khi máy chủ tên miền này xem tất cả các tập bản ghi tài nguyên trong các phần trả lời và thẩm quyền của trả lời là xác thực. Chính sách địa phương của Security-Aware Name Server có thể xem dữ liệu từ một zone có thẩm quyền là xác thực mà không phải xác thực thêm. Tuy nhiên, máy chủ tên miền này không được làm vậy trừ khi máy chủ tên miền này có được zone có thẩm quyền thông qua các biện pháp bảo mật (ví dụ như cơ chế zone transfer có bảo mật) và không được làm vậy trừ khi hành vi này đã được cấu hình rõ ràng.

Một Security-Aware Name Server mà hỗ trợ đệ quy phải theo các nguyên tắc dành cho các bit CD và AD được trình bày trong mục 5.2 khi tạo một trả lời có liên qua dữ liệu có được thông qua đệ quy.

5.2  Recursive Name Server

Như được trình bày trong RFC 4033, Security-Aware Recursive Name Server là phần tử hoạt động trong cả vai trò của Security-Aware Name Server và Security-Aware Resolver. Mục này sử dụng thuật ngữ “phía máy chủ tên miền” và “phía Resolver” để chỉ phần mã trong một Security-Aware Recursive Name Server thực hiện vai trò Security-Aware Name Server và phần mã thực hiện vai trò Security-Aware Resolver tương ứng.

Phía Resolver tuân theo các nguyên tắc thông thường để đệm và đệm âm được áp dụng cho bất kỳ Security-Aware Resolver.

5.2.1  Bit DO

Phía Resolver của một Security-Aware Recursive Name Server phải thiết lập bit DO khi gửi các yêu cầu mà không cần để ý tới trạng thái của bit DO trong yêu cầu khởi tạo được phía máy chủ tên miền nhận. Khi bit DO trong truy vấn khởi tạo không được thiết lập, phía máy chủ tên miền phải lấy đi các bản ghi tài nguyên DNSSEC có thẩm quyền bất kỳ từ trả lời nhưng không được lấy đi các loại bản ghi tài nguyên DNSSEC bất kỳ mà truy vấn khởi tạo đã yêu cầu rõ ràng.

5.2.2  Bit CD

Bit CD tồn tại để cho phép Security-Aware Resolver không cho phép việc xác thực chữ ký trong quá trình truy vấn cụ thể của một Security-Aware Name Server.

Phía máy chủ tên miền phải sao chép trạng thái thiết lập của bit CD từ một truy vấn sang trả lời tương ứng.

Phía máy chủ tên miền của Security-Aware Recursive Name Server phải truyền trạng thái của bit CD sang phía Resolver cùng với phần còn lại của một truy vấn khởi tạo sao cho phía Resolver sẽ biết liệu nó có được yêu cầu phải kiểm tra dữ liệu phản hồi mà nó trả về phía máy chủ tên miền. Khi bit CD được thiết lập, nó chỉ ra rằng Resolver gốc sẵn sàng thực hiện bất cứ việc xác thực mà chính sách địa phương của nó yêu cầu. Do đó, phía Resolver của máy chủ tên miền đệ quy này không cần thực hiện xác thực các tập bản ghi tài nguyên trong trả lời. Khi bit CD được thiết lập, máy chủ tên miền đệ quy này nên, nếu có thể, trả về dữ liệu được yêu cầu về Resolver gốc, thậm chí khi chính sách xác thực địa phương của máy chủ tên miền đệ quy này sẽ loại bỏ các bản ghi tài nguyên này trong truy vấn. Do đó, bằng cách thiết lập bit CD, Resolver gốc đã chỉ ra rằng nó có trách nhiệm thực hiện việc xác thực của chính nó và máy chủ tên miền đệ quy không nên can thiệp.

Khi phía Resolver thực hiện BAD cache (xem mục 6.7) và phía máy chủ tên miền nhận một truy vấn phù hợp một mục trong BAD cache của phía Resolver, phản ứng của phía máy chủ tên miền phụ thuộc vào trạng thái của bit CD trong truy vấn gốc. Khi bit CD được thiết lập, phía máy chủ tên miền nên trả về dữ liệu từ BAD cache; khi bit CD không được thiết lập, phía máy chủ tên miền phải trả về RCODE 2 (lỗi máy chủ).

Mục đích của nguyên tắc trên là để cung cấp dữ liệu thô đến các máy khách có khả năng thực hiện các kiểm tra chữ ký của chính chúng đồng thời bảo vệ các máy khách phụ thuộc phía Resolver của Security-Aware Recursive Name Server thực hiện các kiểm tra này. Một số lý do có khả năng mà việc xác thực chữ ký có thể thất bại liên quan các điều kiện có thể không được áp dụng giống nhau đối với máy chủ tên miền đệ quy và máy khách có liên quan. Ví dụ, xung nhịp của máy chủ tên miền đệ quy có thể được thiết lập không chính xác hay máy khách có thể biết một Island of Security có liên quan mà máy chủ tên miền đệ quy không chia sẻ. Trong những trường hợp như vậy, việc “bảo vệ” máy khách có khả năng thực hiện xác thực chữ ký chính nó khỏi việc thấy dữ liệu “xấu” không giúp cho máy khách.

5.2.3  Bit AD

Phía máy chủ tên miền của Security-Aware Recursive Name Server không được thiết lập bit AD trong trả lời trừ khi máy chủ tên miền này xem xét tất cả các tập bản ghi tài nguyên trong các phần trả lời và thẩm quyền là xác thực. Phía máy chủ tên miền nên thiết lập bit AD khi và chỉ khi phía Resolver xem xét tất cả các tập bản ghi tài nguyên trong phần trả lời và bất kỳ các bản ghi tài nguyên phản hồi phủ định có liên quan trong phần thẩm quyền là xác thực. Phía Resolver phải theo thủ tục được trình bày trong mục 7 để xác định liệu các bản ghi tài nguyên này trong truy vấn có xác thực. Tuy nhiên, để tương thích ngược, máy chủ tên miền đệ quy có thể thiết lập bit AD khi trả lời bao hàm các bản ghi tài nguyên CNAME chưa được ký khi các bản ghi tài nguyên CNAME này có thể đã được đồng bộ từ một bản ghi tài nguyên DNAME thẩm quyền mà nó cũng được bao hàm trong trả lời này theo các nguyên tắc đồng bộ được trình bày trong RFC 2672.

5.3  Ví dụ các trả lời DNSSEC

Xem phụ lục B về ví dụ các gói tin trả lời.

6  Phân giải

Mục này trình bày hành vi của các thực thể bao hàm các chức năng của Security-Aware Resolver. Trong nhiều trường hợp các chức năng này sẽ thuộc Security-Aware Recursive Name Server nhưng một Security-Aware Resolver đơn độc có nhiều yêu cầu giống nhau. Các chức năng dành cho các Security-Aware Recursive Name Server được trình bày trong mục 5.2.

6.1  Hỗ trợ EDNS

Security-Aware Resolver phải bao hàm một EDNS (RFC 2671) OPT giả-bản ghi tài nguyên với bit DO (RFC 3225) được thiết lập khi gửi các truy vấn.

Security-Aware Resolver phải hỗ trợ kích cỡ bản tin tối thiết 1220 octet nên hỗ trợ kích cỡ bản tin 4000 octet và phải sử dụng trường “sender’s UDP payload size” trong EDNS OPT giả-bản ghi tài nguyên để thông báo kích cỡ bản tin mà nó sẵn sàng nhận lớp ip của Security-Aware Resolver phải xử lý các gói tin UDP được phân đoạn một cách chính xác không cần quan tâm đến các gói tin được phân đoạn này là được nhận thông qua IPv4 hay IPv6. Xem RFC 1122, RFC 2460 và RFC 3226 về các yêu cầu này.

6.2  Hỗ trợ kiểm tra chữ ký

Security-Aware Resolver phải hỗ trợ các cơ chế kiểm tra chữ ký được trình bày trong mục 7 và nên áp dụng chúng cho mỗi trả lời nhận được trừ khi:

- Security-Aware Resolver thuộc Security-Aware Recursive Name Server và trả lời là kết quả của đệ quy dựa vào một truy vấn nhận được với bit CD được thiết lập;

- Trả lời là kết quả của một đệ quy được tạo trực tiếp thông qua một dạng giao diện ứng dụng hướng dẫn Security-Aware Resolver không được thực hiện xác thực đối với truy vấn này; hoặc

- Việc xác thực đối với truy vấn này được chính sách nội bộ ngăn chặn.

Việc hỗ trợ kiểm tra chữ ký của một Security-Aware Resolver phải bao hàm việc hỗ trợ kiểm tra các tên miền chủ ký tự đại diện.

Các Security-Aware Resolver có thể truy vấn các bản ghi tài nguyên bảo mật thiếu trong một nỗ lực để thực hiện xác thực; các hành động để thực hiện điều này phải biết rằng các trả lời nhận được có thể không đủ để xác thực trả lời gốc. Ví dụ, việc cập nhật zone có thể đã làm thay đổi (xóa) thông tin cần thiết giữa các truy vấn gốc và kế tiếp.

Khi cố gắng lấy lại các bản ghi tài nguyên NSEC thiếu đặt ở phía cha ở zone cut, một Security-Aware Resolver chế độ lặp phải truy vấn các máy chủ tên miền về zonecha mà không phải là zone con.

Khi cố gắng lấy lại một DS thiếu, Security-Aware Resolver chế độ lặp phải truy vấn các máy chủ tên miền về zonecha mà không phải là zone con. Như được trình bày trong mục 5.1.4.1, các Security- Aware Name Server cần áp dụng các nguyên tắc xử lý đặc biệt để xử lý bản ghi tài nguyên DS này và trong một số tình huống, Resolver cũng có thể cần áp dụng các nguyên tắc đặc biệt để định vị các máy chủ tên miền này cho zonecha khi Resolver này không có tập bản ghi tài nguyên NS phía cha. Để định vị tập bản ghi tài nguyên NS phía cha, Resolver có thể bắt đầu với tên miền chuyển giao, loại bỏ nhãn ngoài cùng bên trái và truy vấn một tập bản ghi tài nguyên NS bằng tên miền đó. Khi không có tập bản ghi tài nguyên NS có ở tên miền đó, tiếp theo Resolver loại bỏ nhãn còn lại ngoài cùng bên trái và thử truy vấn đối với tên miền đó, lặp lại quá trình đi này cho tới khi tìm thấy tập bản ghi tài nguyên NS hoặc không còn nhãn nào.

6.3  Xác định trạng thái bảo mật của dữ liệu

Security-Aware Resolver phải có khả năng xác định liệu nó có nên chờ đợi một tập bản ghi tài nguyên cụ thể được ký. Một cách chính xác hơn, Security-Aware Resolver phải có khả năng phân biệt giữa 4 trường hợp sau:

Bảo mật: tập bản ghi tài nguyên mà Resolver có khả năng xây dựng một chuỗi các bản ghi tài nguyên DNSKEY và DS được ký từ một anchor bảo mật tin cậy đến tập bản ghi tài nguyên này. Trong trường hợp này, tập bản ghi tài nguyên này nên được ký và phụ thuộc vào xác nhận chữ ký nhưng được trình bày ở trên.

Không bảo mật: tập bản ghi tài nguyên mà Resolver biết rằng nó không có chuỗi các bản ghi tài nguyên DNSKEY và DS được ký từ bất kỳ điểm khởi điểm tin cậy đến tập bản ghi tài nguyên này. Điều này có thể xảy ra khi tập bản ghi tài nguyên đích nằm trong một zone không được ký hoặc một zone không được ký con cháu. Trong trường hợp này, tập bản ghi tài nguyên này có thể hoặc không được ký nhưng Resolver sẽ không thể kiểm tra chữ ký.

Giả mạo: tập bản ghi tài nguyên mà Resolver tin cậy rằng nó có thể thiết lập một chuỗi tin cậy nhưng nó lại không thể thực hiện điều đó vì chữ ký không được xác nhận vì một lý do nào đó hoặc vì dữ liệu thiếu mà các bản ghi tài nguyên DNSSEC có liên quan chỉ ra nên có. Trường hợp này có thể chỉ ra một tấn công nhưng cũng có thể chỉ ra một lỗi cấu hình hoặc một dạng lỗi dữ liệu.

Không xác định: tập bản ghi tài nguyên mà Resolver không thể xác định liệu tập bản ghi tài nguyên này có nên được ký vì Resolver không thể có các bản ghi tài nguyên DNSSEC cần thiết. Điều này có thể xảy ra khi Security-Aware Resolver không thể liên lạc với các Security-Aware Name Server đối với các zone liên quan.

6.4  Trust Anchor được cấu hình

Security-Aware Resolver phải có khả năng được cấu hình với ít nhất khóa công khai tin cậy hoặc bản ghi tài nguyên DS nên có khả năng được cấu hình với nhiều khóa công khai tin cậy hoặc các bản ghi tài nguyên DS. Vì Security-Aware Resolver sẽ không có khả năng xác nhận các chữ ký không có một Trust Anchor được cấu hình như vậy, Resolver nên có một cơ chế chắc chắn hợp lý nào đó để đạt được các khóa này khi nó khởi tạo; ví dụ một cơ chế như vậy sẽ là một dạng lưu trữ không khả biến (như một ổ đĩa) hoặc một dạng của cơ chế cấu hình mạng nội bộ tin cậy nào đó.

Chú ý rằng các Trust Anchor cũng che đậy thông tin khóa được cập nhật theo một cách bảo mật. Cách thức bảo mật này có thể thông qua phương tiện vật lý, giao thức trao đổi khóa hoặc một số biện pháp khác.

6.5  Phản hồi của bộ đệm

Một Security-Aware Resolver nên lưu bộ nhớ đệm cho mỗi phản hồi như một mục đơn nguyên chứa toàn bộ câu trả lời, bao gồm cả tên miền tập bản ghi tài nguyên và bất kỳ bản ghi tài nguyên DNSSEC được liên kết. Resolver nên loại bỏ toàn bộ mục đơn nguyên này khi có bất kỳ bản ghi tài nguyên chứa trong nó bị hết hạn. Trong phần lớn trường hợp, chỉ mục nhớ đệm phù hợp đối với mục nhập nguyên này sẽ là bội ba <QNAME, QTYPE, QCLASS> nhưng trong các trường hợp như dạng đệ quy được trình bày trong mục 5.1.3.2, chỉ mục nhớ đệm phù hợp sẽ là bội hai <QNAME, QCLASS>.

Lý do đối với các khuyến nghị này là giữa truy vấn ban đầu và hết thời gian dữ liệu trong nhớ đệm, dữ liệu có thẩm quyền có thể đã thay đổi (ví dụ, thông qua cập nhật động)

Có 2 tình huống liên quan:

a) Bằng cách sử dụng bản ghi tài nguyên RRSIG, có thể suy diễn rằng một trả lời đã được đồng bộ từ một ký tự đại diện. Security-Aware Recursive Name Server có thể lưu trữ dữ liệu ký tự đại diện này và sử dụng nó để tạo các phản hồi khẳng định đối với các truy vấn chứ không phải là tên miền mà trả lời gốc đã được nhận đầu tiên.

b) Các bản ghi tài nguyên NSEC nhận được để chỉ ra sự không tồn tại của một tên miền có thể được Security-Aware Resolver sử dụng lại để chỉ ra sự không tồn tại của bất kỳ tên miền trong dải tên miền nó bao trùm.

Trong lý thuyết, một Resolver có thể sử dụng các ký tự đại diện hoặc các bản ghi tài nguyên NSEC để tạo các phản hồi khẳng định và phủ định (tương ứng) cho tới khi TTL hoặc các chữ ký trên các bản ghi tài nguyên trong truy vấn hết thời gian. Tuy nhiên, các Resolver nên thận trọng để tránh việc ngăn chặn dữ liệu có thẩm quyền mới hoặc việc đồng bộ dữ liệu mới trên chính nó. Các Resolver theo khuyến nghị này sẽ có quan điểm nhất quán hơn về không gian tên miền.

6.6  Xử lý các bit CD và AD

Security-Aware Resolver có thể thiết lập bit CD của truy vấn để chỉ ra rằng Resolver này nhận trách nhiệm thực hiện bất kỳ thẩm quyền mà chính sách nội bộ của nó yêu cầu đối với các tập bản ghi tài nguyên trong trả lời này. Xem mục 5.2 về ảnh hưởng của bit này lên hành vi của các Security-Aware Recursive Name Server.

Security-Aware Resolver phải xóa bit AD khi xây dựng các bản tin truy vấn để bảo vệ chống lại các máy chủ tên miền có nhiều lỗi sao chép các bit phần mào đầu một cách máy móc mà chúng không hiểu từ bản tin truy vấn sang bản tin trả lời.

Resolver phải không quan tâm đến ý nghĩa của các bit CD và AD trong một trả lời trừ khi trả lời này đã đạt được bằng cách sử dụng một kênh có bảo mật hoặc Resolver này đã được cấu hình một cách đặc biệt để quan tâm các bit phần mào đầu bản tin mà không sử dụng kênh có bảo mật.

6.7  Dữ liệu bộ đệm BAD

Khi nhiều lỗi xác thực là tạm thời, một số lỗi có thể liên tục, như thể chúng là do lỗi quản lý gây ra (lỗi ký lại một zone, lệch xung nhịp, ...). Vì việc truy vấn lại sẽ không có ích trong các trường hợp này, các Resolver xác thực có thể tạo một lượng lưu lượng DNS không cần thiết đáng kể khi lặp lại các truy vấn đối với các tập bản ghi tài nguyên với các lỗi xác thực liên tục này.

Để tránh lưu lượng DNS không cần thiết này, các Security-Aware Resolver có thể nhớ đệm dữ liệu với các chữ ký không hợp pháp bằng một số hạn chế.

Về mặt khái niệm, việc nhớ đệm dữ liệu này tương tự việc nhớ đệm âm (RFC 2308) ngoại trừ rằng thay vi nhớ đệm một phản hồi phủ định hợp pháp, Resolver này đang nhớ đệm sự kiện một trả lời cụ thể xác thực không thành công. Tiêu chuẩn này xem việc nhớ đệm dữ liệu có các chữ ký không hợp pháp là một “BAD cache”.

Các Resolver thực hiện một BAD cache phải thực hiện các bước để tránh nhớ đệm khỏi trở thành một thiết bị tăng cường hữu hiệu của tấn công từ chối dịch vụ, cụ thể là:

- Khi các tập bản ghi tài nguyên xác thực không thành công không có các TTL tin cậy, việc thực hiện này phải ấn định một TTL. TTL này nên nhỏ để giảm thiểu ảnh hưởng của nhớ đệm các kết quả của một tấn công.

- Để tránh nhớ đệm một lỗi xác thực tạm thời (nó có thể là kết quả của một tấn công), các Resolver nên theo dấu các truy vấn gây ra các lỗi xác thực và chỉ nên trả lời từ BAD cache sau khi số lượt trả lời các truy vấn đối với <QNAME, QTYPE, QCLASS> cụ thể xác thực không thành công vượt quá một giá trị ngưỡng.

Các Resolver không được trả về các tập bản ghi tài nguyên từ BAD cache trừ khi Resolver này không được yêu cầu để xác nhận các chữ ký của các tập bản ghi tài nguyên trong câu hỏi theo các nguyên tắc được trình bày trong mục 6.2 và mục 5.2.2 về cách các trả lời được Security-Aware Recursive Name Server trả về hoạt động với BAD cache.

6.8  Các CNAME được đồng bộ

Một Security-Aware Resolver xác nhận phải xử lý chữ ký của một bản ghi tài nguyên DNAME được ký hợp pháp cũng như bao trùm các bản ghi tài nguyên CNAME chưa được ký có thể đã được đồng bộ từ bản ghi tài nguyên DNAME như trình bày trong RFC 2672, ít nhất ở mức không hủy bỏ chỉ có một bản tin trả lời vì nó chứa các bản ghi tài nguyên CNAME như vậy. Resolver này có thể giữ lại các bản ghi tài nguyên CNAME này trong nhớ đệm của nó hoặc trong các trả lời mà nó truyền trở lại nhưng nó không được yêu cầu làm vậy.

6.9  Các Stub Resolver

Security-Aware Stub Resolver phải hỗ trợ các loại bản ghi tài nguyên DNSSEC ít nhất ở mức không xử lý nhầm các trả lời chỉ vì chúng chứa các bản ghi tài nguyên DNSSEC.

6.9.1  Xử lý bit DO

Non-validating security-aware stub resolver có thể chứa các bản ghi tài nguyên DNSSEC được Security-Aware Recursive Name Server trả về như là dữ liệu mà Stub Resolver này truyền lại cho ứng dụng liên quan đến nó nhưng có không được yêu cầu làm vậy. Non-validating stub resolver tìm cách làm này sẽ cần thiết lập bit DO để nhận các bản ghi tài nguyên DNSSEC từ máy chủ tên miền đệ quy này.

Validating Security-Aware Stub Resolver phải thiết lập bit DO vì nếu không nó sẽ không nhận các bản ghi tài nguyên DNSSEC mà nó cần thực hiện xác nhận chữ ký.

6.9.2  Xử lý bit CD

Non-validating security-aware stub resolver không nên thiết lập bit CD khi gửi các truy vấn trừ khi nó được lớp ứng dụng yêu cầu, như theo định nghĩa, Non-Validating Stub Resolver phụ thuộc vào Security-Aware Recursive Name Server thực hiện xác thực thay cho nó.

Validating Security-Aware stub Resolver nên thiết lập bit CD vì nếu không Security-Aware Recursive Name Server sẽ trả lời truy vấn bằng cách sử dụng chính sách nội bộ của máy chủ tên miền này, chính sách này có thể ngăn cản Stub Resolver này nhận dữ liệu có thể được chấp nhận theo chính sách nội bộ của Stub Resolver này.

6.9.3  Xử lý bit AD

Non-validating security-aware stub resolver có thể lựa chọn để kiểm tra việc thiết lập của bit AD trong các bản tin phản hồi mà nó nhận để xác định liệu Security-Aware Recursive Name Server gửi các xác nhận phản hồi đã được kiểm tra mã hóa dữ liệu trong các phần trả lời và thẩm quyền của bản tin phản hồi. Tuy nhiên, chú ý rằng, các phản hồi được Security-Aware Stub Resolver nhận phụ thuộc chủ yếu vào chính sách nội bộ của Security-Aware Recursive Name Server. Do đó, có thể có ít giá trị thực tế trong việc kiểm tra trạng thái của bit AD ngoại trừ có thể trợ giúp gỡ rối. Trong bất kỳ trường hợp nào, Security-Aware Stub Resolver không được đặt bất kỳ tin cậy nào vào xác nhận chữ ký được thực hiện thay thế cho nó trừ khi Security-Aware Stub Resolver này có được dữ liệu này từ Security-Aware Recursive Name Server thông qua một kênh bảo mật.

Validating Security-Aware Stub Resolver không nên kiểm tra việc thiết lập bit AD trong các bản tin phản hồi như theo định nghĩa, Stub Resolver thực hiện xác nhận chữ ký của chính nó mà không quan tâm đến việc thiết lập của bit AD.

7  Xác thực các trả lời DNS

Để sử dụng các bản ghi tài nguyên DNSSEC để xác thực, Security-Aware Resolver yêu cầu biết được cấu hình của ít nhất một bản ghi tài nguyên DNSKEY hoặc DS được xác thực. Quá trình có được và xác thực Trust Anchor khởi đầu này đạt được thông qua một cơ chế bên ngoài nào đó. Ví dụ, Resolver có thể sử dụng việc trao đổi được xác thực ngoại tuyến nào đó để có được một DNSKEY của zone hoặc có được một bản ghi tài nguyên DS nhận biết và xác thực một bản ghi tài nguyên DNSKEY của zone. Phần còn lại của mục này giả thiết rằng Resolver này đã có được một bộ khởi đầu các Trust Anchor.

Một bản ghi tài nguyên DNSKEY khởi đầu có thể được sử dụng để xác thực tập bản ghi tài nguyên DNSKEY của zone apex của zone. Để xác thực tập bản ghi tài nguyên DNSKEY của zone apex bằng cách sử dụng một khóa khởi đầu, Resolver này phải:

a) Kiểm tra xem bản ghi tài nguyên DNSKEY khởi tạo xuất hiện trong tập bản ghi tài nguyên DNSKEY của zone apex và xem bản ghi tài nguyên DNSKEY có Zone KEY Flag (DNSKEY RDATA bit 7) được thiết lập: và

b) Kiểm tra xem có bản ghi tài nguyên RRSIG nào bao trùm tập bản ghi tài nguyên DNSKEY của zone apex và xem kết hợp của bản ghi tài nguyên RRSIG và bản ghi tài nguyên DNSKEY khởi tạo này xác thực tập bản ghi tài nguyên DNSKEY này. Quá trình sử dụng một bản ghi tài nguyên RRSIG để xác thực một tập bản ghi tài nguyên được trình bày trong mục 7.3

Khi Resolver này đã xác thực tập bản ghi tài nguyên DNSKEY của zone apex bằng cách sử dụng một bản ghi tài nguyên DNSKEY khởi tạo, các chuyển giao từ zone đó có thể được xác thực bằng cách sử dụng các bản ghi tài nguyên DS. Điều này cho phép Resolver bắt đầu từ một khóa khởi tạo và sử dụng các tập bản ghi tài nguyên DNSKEY để tiến hành đệ quy xuống cây DNS, có được các tập bản ghi tài nguyên DNSKEY của zone apex. Khi Resolver đã được cấu hình bằng một bản ghi tài nguyên DNSKEY gốc và khi mỗi chuyển giao có một bản ghi tài nguyên DS liên kết với nó thì Resolver có thể có được và xác nhận bất kỳ tập bản ghi tài nguyên DNSKEY của zone apex nào. Quá trình sử dụng các bản ghi tài nguyên DS để xác thực các truyền tải được trình bày trong mục 7.2

Mục 7.3 trình bày cách 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ỳ các tập bản ghi tài nguyên khác trong zone khi Resolver đã xác thực tập bản ghi tài nguyên DNSKEY của zone apex của zone. Mục 7.4 trình bày cách Resolver có thể 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 có trong zone này.

Khi Resolver chỉ ra sự hỗ trợ dành cho DNSKEY (bằng cách thiết lập bit DO), Security-Aware Name Server nên cố gắng cung cấp các tập bản ghi tài nguyên DNSKEY, RRSIG, NSEC và DS trong một trả lời (xem mục 5). Tuy nhiên, Security-Aware Resolver vẫn có thể nhận một trả lời thiếu các bản ghi tài nguyên DNSKEY phù hợp vì các vấn đề cấu hình như security-oblivious recursive name server hướng lên can thiệp các bản ghi tài nguyên DNSKEY một cách tình cờ hoặc vì một tấn công cố ý trong đó đối phương gửi một trả lời, loại bỏ các bản ghi tài nguyên DNSKEY từ một trả lời hoặc thay đổi một truy vấn để các bản ghi tài nguyên DNSKEY không xuất hiện như yêu cầu. Việc thiếu dữ liệu DNSKEY trong một trả lời không được tự lấy làm chỉ dẫn rằng thông tin xác thực không tồn tại.

Resolver nên chờ thông tin xác thực từ các Zone được ký. Resolver nên tin tưởng rằng một Zone được ký khi Resolver này đã được cấu hình với thông tin khóa công khai đối với zone đó hoặc khi cha của zone này được ký và sự chuyển giao từ cha chứa tập bản ghi tài nguyên DS.

7.1  Các vấn đề đặc biệt về cô lập bảo mật

Cô lập bảo mật (xem RFC 4033) là các zone được ký mà nó không được xây dựng chuỗi xác thực trong zone từ zonecha của nó.Việc xác nhận các chữ ký trong cô lập bảo mật yêu cầu rằng phần xác nhận có một số phương pháp lấy một zone key được xác thực ban đầu đối với cô lập bảo mật này. Khi phần xác nhận không thể lấy được một khóa như vậy thì nó nên chuyển sang hoạt động như thể các zone này trong cô lập bảo mật này chưa được ký.

Tất cả các quá trình chuẩn để xác nhận các trả lời áp dụng đối với các cô lập bảo mật. Sự khác nhau duy nhất giữa xác nhận chuẩn và xác nhận trong một cô lập bảo mật là trong cách mà phần xác nhận lấy Trust Anchor dành cho chuỗi xác thực.

7.2  Xác thực các tham chiếu

Khi tập bản ghi tài nguyên DNSKEY của zone apex dành cho một zonecha được ký đã được xác thực, các tập bản ghi tài nguyên DS có thể được sử dụng để xác thực chuyển giao đến một zone con được ký. Một bản ghi tài nguyên DS xác định một bản ghi tài nguyên DNSKEY trong tập bản ghi tài nguyên DNSKEY của zone apex của zone con này và chứa một tóm tắt mật mã của bản ghi tài nguyên DNSKEY của zone con. Việc sử dụng thuật toán tóm tắt mật mã mạnh đảm bảo rằng việc tạo một bản ghi tài nguyên DNSKEY phù hợp với phần tóm tắt đối với một đối thủ là không khả thi về mặt tính toán. Do đó, việc xác thực phần tóm tắt cho phép Resolver xác thực bản ghi tài nguyên DNSKEY phù hợp. Tiếp theo, Resolver này có thể sử dụng bản ghi tài nguyên DNSKEY con này để xác thực toàn bộ tập bản ghi tài nguyên DNSKEY của zone apex phía zone con.

Cho trước một bản ghi tài nguyên DS dành cho chuyển giao, tập bản ghi tài nguyên DNSKEY của zone apex của zone con có thể được xác thực khi tất cả các nội dung sau được đáp ứng:

- Bản ghi tài nguyên DS này đã được xác thực bằng cách sử dụng một bản ghi tài nguyên DNSKEY nào đó trong tập bản ghi tài nguyên DNSKEY của zone apex của zonecha(xem mục 7.3).

- Thuật toán và thẻ khóa trong bản ghi tài nguyên DS này phù hợp trường thuật toán và thẻ khóa của một bản ghi tài nguyên DNSKEY trong tập bản ghi tài nguyên DNSKEY của zone apex của zone con và khi RDATA và tên miền chủ của bản ghi tài nguyên DNSKEY này được trộn bằng cách sử dụng thuật toán tóm tắt được quy định trong trường loại tóm tắt của bản ghi tài nguyên DS này, giá trị tóm tắt thu được phù hợp trường tóm tắt của bản ghi tài nguyên DS này.

- Bản ghi tài nguyên DNSKEY phù hợp trong zone con có bit Zone Flag được thiết lập, khóa riêng tương ứng đã ký tập bản ghi tài nguyên DNSKEY của zone apex của zone con và bản ghi tài nguyên RRSIG thu được xác thực tập bản ghi tài nguyên DNSKEY của zone apex của zone con.

Khi tham chiếu này từ zonecha đã không chứa một tập bản ghi tài nguyên DS, trả lời này đã chứa một tập bản ghi tài nguyên NSEC được ký chỉ ra rằng không có tập bản ghi tài nguyên DS nào tồn tại dành cho tên miền được chuyển giao này (xem mục 5.1.4) Security-Aware Resolver phải truy vấn các máy chủ tên miền dành cho zonecha đối với tập bản ghi tài nguyên DS này khi tham chiếu này không chứa tập bản ghi tài nguyên DS hoặc tập bản ghi tài nguyên NSEC chỉ ra rằng tập bản ghi tài nguyên DS không tồn tại (xem mục 6)

Khi phần xác nhận xác thực một tập bản ghi tài nguyên NSEC để chỉ ra rằng không có tập bản ghi tài nguyên DS nào hiện có dành cho zone này thì không có liên kết xác thực nào dẫn từ cha đến con. Khi Resolver này có bản ghi tài nguyên DNSKEY hoặc DS khởi tạo thuộc zone con hoặc thuộc bất kỳ chuyển giao nào dưới zone con, bản ghi tài nguyên DNSKEY hoặc DS khởi tạo này có thể được sử dụng để thiết lập lại liên kết xác thực. Khi không có bản ghi tài nguyên DNSKEY hoặc DS như vậy tồn tại, phần xác nhận không thể xác thực các tập bản ghi tài nguyên trong hoặc dưới zone con.

Khi phần xác nhận không hỗ trợ bất kỳ thuật toán được liệt kê trong một tập bản ghi tài nguyên DS được xác thực thì Resolver này không hỗ trợ liên kết xác thực dẫn từ cha đến con. Resolver nên xử lý trường hợp này khi nó là trường hợp của một tập bản ghi tài nguyên NSEC được xác thực chỉ ra rằng không có tập bản ghi tài nguyên DS nào tồn tại như đã được trình bày ở trên.

Chú ý rằng, đối với một chuyển giao được ký, có hai bản ghi tài nguyên NSEC liên kết với tên miền được chuyển giao. Một bản ghi tài nguyên NSEC thứ nhất tại zonecha và có thể được sử dụng để chỉ ra liệu một tập bản ghi tài nguyên DS có tồn tại dành cho tên miền được chuyển giao. Một bản ghi tài nguyên NSEC thứ hai tại zone con và xác định các tập bản ghi tài nguyên nào hiện có ở của zone apex của zone con. Bản ghi tài nguyên NSEC cha và bản ghi tài nguyên NSEC con luôn luôn có thể được phân biệt vì bit SOA sẽ được thiết lập trong bản ghi tài nguyên NSEC con và bị xóa trong bản ghi tài nguyên NSEC cha. Security-Aware Resolver phải sử dụng bản ghi tài nguyên NSEC cha khi cố gắng chỉ ra rằng một tập bản ghi tài nguyên DS không tồn tại.

Khi Resolver này không hỗ trợ bất kỳ thuật toán được liệt kê trong một tập bản ghi tài nguyên DS được xác thực thì Resolver này sẽ không thể kiểm tra liên kết xác thực đến zone con. Trong trường hợp này, Resolver này nên xử lý zone con như thể nó chưa được ký.

7.3  Xác thực một tập bản ghi tài nguyên bằng một bản ghi tài nguyên RRSIG

Phần xác nhận có thể 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ó để cố gắng xác thực các tập bản ghi tài nguyên. Trước tiên, Resolver kiểm tra bản ghi tài nguyên RRSIG để kiểm tra xem nó có bao trùm tập bản ghi tài nguyên này, có khoảng thời gian hợp lệ và xác định một bản ghi tài nguyên DNSKEY hợp lệ. Tiếp theo, phần xác nhận này 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 này. Cuối cùng, phần xác nhận sử dụng khóa công khai và chữ ký này để xác thực dữ liệu được ký. Các mục 7.3.1, 7.3.2 và 7.3.3 trình bày chi tiết mỗi bước này.

7.3.1  Kiểm tra tính hợp lệ của bản ghi tài nguyên RRSIG

Security-Aware Resolver có thể sử dụng một bản ghi tài nguyên RRSIG để xác thực một tập bản ghi tài nguyên khi tất cả các điều kiện sau được thỏa mãn:

- Bản ghi tài nguyên RRSIG và tập bản ghi tài nguyên này phải có tên miền chủ và lớp giống nhau.

- Trường Name của Signer của bản ghi tài nguyên RRSIG phải là tên miền của zone chứa tập bản ghi tài nguyên này.

- Trường Type Covered của bản ghi tài nguyên RRSIG phải giống loại của tập bản ghi tài nguyên này.

- Số các nhãn trong tên miền chủ của tập bản ghi tài nguyên phải lớn hơn hoặc bằng giá trị trong trường Labels của bản ghi tài nguyên RRSIG này.

- Thời gian hiện tại của phần xác nhận phải nhỏ hơn hoặc bằng thời gian được liệt kê trong trường Expiration của bản ghi tài nguyên RRSIG.

- Thời gian hiện tại của phần xác nhận phải lớn hơn hoặc bằng thời gian được liệt kê trong trường Inception của bản ghi tài nguyên RRSIG.

- Các trường Name, Algorithm và Key Tag của Signer của bản ghi tài nguyên RRSIG phải phù hợp tên miền chủ, thuật toán và thẻ khóa dành cho một bản ghi tài nguyên DNSKEY nào đó trong tập bản ghi tài nguyên DNSKEY của zone apex của zone này.

- Bản ghi tài nguyên DNSKEY phù hợp phải hiện có trong tập bản ghi tài nguyên DNSKEY của zone apex của zone này và phải có bit Zone Flag được thiết lập (DNSKEY RDATA Flag bit 7).

Việc phù hợp các điều kiện trên đối với nhiều bản ghi tài nguyên DNSKEY là khả thi. Trong trường hợp này, phần xác nhận có thể không tiên lượng được bản ghi tài nguyên DNSKEY nào được sử dụng để xác thực chữ ký này và nó phải thử từng bản ghi tài nguyên DNSKEY phù hợp cho tới khi chữ ký được xác thực hoặc phần xác nhận không con các khóa công khai phù hợp để thử.

Chú ý rằng quá trình xác thực này chỉ có ý nghĩa khi phần xác nhận xác thực bản ghi tài nguyên DNSKEY này trước khi việc sử dụng nó để xác nhận các chữ ký. Bản ghi tài nguyên DNSKEY phù hợp được xem là xác thực khi:

- Tập bản ghi tài nguyên DNSKEY của zone apex này chứa bản ghi tài nguyên DNSKEY này được xem là xác thực hoặc

- Tập bản ghi tài nguyên được bản ghi tài nguyên RRSIG bao trùm chính là tập bản ghi tài nguyên DNSKEY của zone apex và bản ghi tài nguyên DNSKEY này phù hợp một bản ghi tài nguyên DS được xác thực từ zonecha hoặc phù hợp một Trust Anchor.

7.3.2  Xây dựng lại dữ liệu được ký

Khi bản ghi tài nguyên RRSIG đã đáp ứng các yêu cầu xác nhận được trình bày trong mục 7.3.1, phần xác nhận phải xây dựng lại dữ liệu được ký ban đầu. Dữ liệu được ký ban đầu bao gồm RRSIG RDATA (trừ trường Signature) và dạng chính tắc của tập bản ghi tài nguyên. Ngoài cấu trúc lệnh, dạng chính tắc của tập bản ghi tài nguyên này cũng có thể khác tập bản ghi tài nguyên nhận được vì nén tên miền DNS, các TTL giảm hoặc mở rộng ký tự đại diện. Phần xác nhận này nên sử dụng các lệnh sau để xây dựng lại dữ liệu được ký ban đầu:

signed_data = RRSIG_RDATA I RR(1) I RR(2)...

trong đó

“I” là toán tử ghép

RRSIG_RDATA là dạng chuỗi của các trường RRSIG RDATA với trường Signature bị loại bỏ và Signer's Name có dạng chính tắc.

RR(i) = name I type I class I OrigTTL I RDATA length I RDATA

trong đó

name được tính theo hàm dưới đây

class là lớp của tập bản ghi tài nguyên.

type là loại của tập bản ghi tài nguyên và tất cả các bản ghi tài nguyên trong lớp này

OrigTTL là giá trị từ trường RRSIG Original TTL

Tất cả các tên miền trong RDATA có dạng chính tắc.

Tất cả các RR (i) được sắp xếp theo thứ tự chính tắc.

Để tính tên miền:

Đặt rrsig_labels = giá trị của trường RRSIG Labels

Đặt fqdn = tên miền đủ điều kiện hoàn toàn của tập bản ghi tài nguyên dưới dạng chính tắc.

Đặt fqdn_labels = số nhãn của fqdn bên trên.

Khi rrsig_labels = fqdn_labels thì name = fqdn

Khi rrsig_labels < fqdn_labels thì name = “*.” I các nhãn rrsig_label bên phải ngoài cùng của fqdn

Khi rrsig_labels > fqdn_labels thì bản ghi tài nguyên RRSIG đã không vượt qua các kiểm tra xác nhận cần thiết và không được sử dụng để xác thực tập bản ghi tài nguyên này.

Các dạng chính tắc đối với các tên miền và tập bản ghi tài nguyên được trình bày trong RFC 4034.

Các tập bản ghi tài nguyên NSEC ở ranh giới chuyển giao yêu cầu xử lý đặc biệt có hai tập bản ghi tài nguyên NSEC khác nhau liên kết với một tên miền được chuyển giao được ký. Tập bản ghi tài nguyên NSEC thứ nhất trong zonecha và xác định các tập bản ghi tài nguyên nào hiện có ở zonecha. Tập bản ghi tài nguyên NSEC thứ hai ở zone con và xác định các tập bản ghi tài nguyên nào hiện có ở của zone apex trong zone con. Tập bản ghi tài nguyên NSEC cha và tập bản ghi tài nguyên NSEC con luôn luôn có thể được phân biệt vì chỉ một bản ghi tài nguyên NSEC con sẽ chỉ ra rằng một tập bản ghi tài nguyên SOA tồn tại ở tên miền. Khi xây dựng lại tập bản ghi tài nguyên NSEC ban đầu dành cho chuyển giao từ zonecha, các bản ghi tài nguyên NSEC này không được kết hợp với các bản ghi tài nguyên NSEC từ zone con. Khi xây dựng lại tập bản ghi tài nguyên NSEC ban đầu dành cho của zone apex của zone con, các bản ghi tài nguyên NSEC không được kết hợp với các bản ghi tài nguyên NSEC từ zonecha.

Chú ý rằng từng tập bản ghi tài nguyên của hai tập bản ghi tài nguyên NSEC này ở điểm chuyển giao có một bản ghi tài nguyên RRSIG tương ứng với một tên miền chủ phù hợp tên miền được chuyển giao và từng bản ghi tài nguyên của các bản ghi tài nguyên RRSIG này được liên kết dữ liệu xác thực với zone chứa tập bản ghi tài nguyên NSEC tương ứng. Khi cần, Resolver có thể phân biệt các bản ghi tài nguyên RRSIG này bằng cách kiểm tra trường tên miền của Signer.

7.3.3  Kiểm tra chữ ký

Khi Resolver đã xác nhận bản ghi tài nguyên RRSIG như được trình bày trong mục 7.3.1 và xây dựng lại dữ liệu được ký ban đầu như được trình bày trong mục 7.3.2, Resolver có thể thử sử dụng chữ ký mật mã để xác thực dữ liệu được ký này và (cuối cùng) xác thực tập bản ghi tài nguyên này.

Trường Algorithm trong bản ghi tài nguyên RRSIG xác định thuật toán mật mã được sử dụng để tạo chữ ký. Chữ ký này được chứa trong trường Signature của RRSIG RDATA và khóa công khai được sử dụng để kiểm tra chữ ký được chứa trong trường Public KEY của (các) DNSKEY phù hợp (tìm thấy trong mục 7.3.1) RFC 4034 cung cấp một danh sách các loại thuật toán và cung cấp các con trỏ đến các tài liệu hướng dẫn sử dụng từng thuật toán này.

Chú ý rằng việc thỏa mãn các điều kiện trong mục 7.3.1 đối với nhiều hơn 1 bản ghi tài nguyên DNSKEY là khả thi. Trong trường hợp này, Resolver chỉ có thể xác định bản ghi tài nguyên DNSKEY nào là đúng bằng cách thử từng khóa công khai phù hợp cho tới khi Resolver thành công trong việc xác nhận chữ ký này hoặc hết các khóa để thử.

Khi trường Labels của bản ghi tài nguyên RRSIG không bằng số các nhãn trong tên miền chủ đủ điều kiện hoàn toàn của bản ghi tài nguyên RRSIG thì tập bản ghi tài nguyên này là không hợp lệ hoặc là kết quả của phần mở rộng ký tự đại diện. Resolver phải kiểm tra xem phần mở rộng có được áp dụng đúng trước khi xem xét tập bản ghi tài nguyên có xác thực. Mục 7.3.4 trình bày cách xác định xem ký tự đại diện có được áp dụng đúng không.

Khi các bản ghi tài nguyên RRSIG khác cũng bao trùm tập bản ghi tài nguyên này, chính sách bảo mật Resolver nội bộ xác định liệu Resolver này cũng phải kiểm tra các bản ghi tài nguyên RRSIG này và cách xử lý các xung đột khi các bản ghi tài nguyên RRSIG này dẫn đến các kết quả khác nhau.

Khi Resolver này chấp nhận tập bản ghi tài nguyên là xác thực, phần xác nhận phải thiết lập TTL của bản ghi tài nguyên RRSIG và từng bản ghi tài nguyên trong tập bản ghi tài nguyên được xác thực theo giá trị không lớn hơn giá trị tối thiểu của:

- TTL của tập bản ghi tài nguyên nhận được trong trả lời;

- TTL của bản ghi tài nguyên RRSIG nhận được trong trả lời;

- Giá trị trong trường TTL ban đầu của bản ghi tài nguyên RRSIG và

- Chênh lệch giữa thời gian hết hạn của chữ ký của bản ghi tài nguyên RRSIG và thời gian hiện tại.

7.3.4  Xác thực một phản hồi khẳng định của tập bản ghi tài nguyên có phần mở rộng ký tự đại diện

Khi số nhãn trong tên miền chủ của tập bản ghi tài nguyên lớn hơn trường Labels của bản ghi tài nguyên RRSIG bao trùm thì tập bản ghi tài nguyên và bản ghi tài nguyên RRSIG bao trùm của nó đã được tạo ra là kết quả của phần mở rộng ký tự đại diện. Khi phần xác nhận đã kiểm tra chữ ký như được trình bày trong mục 7.3, việc kiểm tra sự không tồn tại của một sự phù hợp chính xác hoặc sự phù hợp ký tự đại diện gần hơn đối với truy vấn phải thực hiện các bước bổ sung. Mục 7.4 trình bày các bước này.

Chú ý rằng trả lời Resolver nhận được nên chứa tất cả các bản ghi tài nguyên NSEC cần thiết để xác thực trả lời này (xem mục 5.1.3).

7.4  Xác thực từ chối sự tồn tại

Resolver có thể sử dụng các bản ghi tài nguyên NSEC được xác thực để chỉ ra rằng một tập bản ghi tài nguyên không hiện có trong một Zone được ký. Các Security-Aware Name Server nên chứa bất kỳ các bản ghi tài nguyên NSEC cần thiết đối với các Zone được ký trong các trả lời của chúng đến các Security-Aware Resolver một cách tự động.

Phủ nhận sự tồn tại được xác định bằng cách nguyên tắc sau:

- Khi tên miền bản ghi tài nguyên được yêu cầu phù hợp tên miền chủ của một bản ghi tài nguyên NSEC được xác thực thì trường ánh xạ bit loại của bản ghi tài nguyên NSEC có thể chỉ ra rằng loại bản ghi tài nguyên được yêu cầu không tồn tại bằng cách kiểm tra loại bản ghi tài nguyên trong ánh xạ này. Khi số nhãn trong một tên miền chủ của một bản ghi tài nguyên NSEC được xác thực bằng trường Labels của bản ghi tài nguyên RRSIG bao trùm thì sự tồn tại của bản ghi tài nguyên NSEC chỉ ra rằng phần mở rộng ký tự đại diện đã không được sử dụng để phù hợp yêu cầu này.

- Khi tên miền bản ghi tài nguyên được yêu cầu xuất hiện sau khi một tên miền chủ của bản ghi tài nguyên NSEC được xác thực và trước tên miền được liệt kê trong trường Next Domain Name của bản ghi tài nguyên NSEC theo thứ tự tên miền DNS chính tắc trong RFC 4034 thì không tập bản ghi tài nguyên nào có tên miền được yêu cầu tồn tại trong zone này. Tuy nhiên, một ký tự đại diện có thể được được sử dụng để phù hợp loại và tên miền chủ của bản ghi tài nguyên được yêu cầu do đó chỉ ra rằng tập bản ghi tài nguyên được yêu cầu không tồn tại yêu chỉ ra rằng không có tập bản ghi tài nguyên ký tự đại diện tồn tại và đã được sử dụng để tạo ra một phản hồi khẳng định.

Ngoài ra, các Security-Aware Resolver phải xác thực các tập bản ghi tài nguyên NSEC chứa bằng chứng không tồn tại như được trình bày trong mục 7.3.

Để chỉ ra sự không tồn tại của một tập bản ghi tài nguyên, Resolver phải có khả năng kiểm tra cả tập bản ghi tài nguyên được truy vấn không tồn tại và không có tập bản ghi tài nguyên ký tự đại diện liên quan tồn tại. Việc chỉ ra điều này có thể yêu cầu nhiều hơn một tập bản ghi tài nguyên NSEC từ zone này. Khi tập đầy đủ các tập bản ghi tài nguyên NSEC cần thiết không hiện có trong một trả lời (có thể do cắt cụt bản tin) thì Security-Aware Resolver phải gửi lại truy vấn này để có được tập hợp đầy đủ các bản ghi tài nguyên NSEC cần thiết để kiểm tra sự không tồn tại của tập bản ghi tài nguyên được yêu cầu. Tuy nhiên Resolver này phải chuyển công việc này thành việc trả lời một truy vấn cụ thể nào đó.

Khi một bản ghi tài nguyên NSEC được xác nhận chỉ ra sự tồn tại của cả nó và bản ghi tài nguyên RRSIG tương ứng của nó, phần xác nhận phải bỏ qua các thiết lập của các bit NSEC và RRSIG trong một bản ghi tài nguyên NSEC.

7.5  Trạng thái Resolver khi các chữ ký không xác nhận

Khi vì bất cứ lý do nào mà không có một trong các RRSIG có thể được xác nhận, trả lời nên được xem xét là “BAD”. Khi xác nhận đang được thực hiện để phục vụ một truy vấn đệ quy, máy chủ tên miền phải trả RCODE 2 về máy khách khởi tạo. Tuy nhiên, nó phải trả về trả lời đầy đủ này khi và chỉ khi truy vấn ban đầu có bit CD được thiết lập. Xem mục 6.7 về nhớ đệm các trả lời không xác nhận.

7.6  Ví dụ về xác thực

Phụ lục C trình bày một ví dụ của quá trình xác thực.

8  Các vấn đề IANA

RFC 4034 trình bày tổng quan các vấn đề IANA được DNSSEC đưa ra. Các vấn đề IANA bổ sung được trình bày trong tiêu chuẩn này là:

RFC 2535 đã dự phòng các bit CD và AD trong phần mào đầu bản tin. Bit AD đã được định nghĩa lại trong RFC 3655 và cả bit CD và AD đã được định nghĩa lại trong tiêu chuẩn này. Không có bit mới nào trong phần mào đầu bản tin DNS được xác định trong tiêu chuẩn này.

RFC 2671 đưa ra EDNS và RFC 3225 dự phòng bit DNSSEC OK và xác định cách sử dụng nó. Cách sử dụng này được xác định lại nhưng không bị thay đổi trong tiêu chuẩn này.

9  Các vấn đề bảo mật

Tiêu chuẩn này trình bày cách các phần mở rộng bảo mật DNS sử dụng mật mã khóa công khai để ký và xác thực các bộ bản ghi tài nguyên DNS. Xem RFC 4033 về thuật ngữ và các vấn đề bảo mật chung liên quan đến DNSSEC; xem RFC 4034 về các vấn đề cụ thể đối với các loại bản ghi tài nguyên DNSSEC.

Kẻ tấn công chủ động có thể thiết lập bit CD trong bản tin truy vấn DNS hoặc bit AD trong bản tin trả lời DNS có thể sử dụng các bit này để vượt qua sự bảo vệ mà DNSSEC cung cấp cho các Security- Oblivious Recursive-Mode Resolver. Vì lý do này, việc sử dụng các bit kiểm soát này bởi một security- oblivious recursive-mode resolvers yêu cầu một kênh bảo mật. Xem mục 5.2.2 và 6.9 để biết thêm về nội dung này.

Giao thức được trình bày trong tiêu chuẩn này mở rộng các ưu điểm của DNSSEC đến các security- oblivious stub resolver. Tuy nhiên, khi việc khôi phục từ các thất bại xác nhận có thể được xác định đối với các ứng dụng cụ thể, phương tiện mà DNSSEC cung cấp cho các Stub Resolver có thể chỉ ra là không đủ. Các nhà điều hành các Security-Aware Recursive Name Server sẽ phải quan tâm đến hành vi của các ứng dụng sử dụng các dịch vụ của chúng khi lựa chọn một chính sách xác nhận nội bộ; việc thất bại của việc này dẫn đến máy chủ tên miền đệ quy từ chối dịch vụ đối với các máy khách mà nó hỗ trợ.

Phụ lục C

(Tham khảo)

Các ví dụ xác thực

Các ví dụ trong phụ lục này trình bày cách các bản tin trả lời trong phụ lục B được xác thực.

C.1  Xác thực một trả lời

Truy vấn trong mục B.1 đã trả về một tập bản ghi tài nguyên MX dành cho “x.w.example”. RRSIG tương ứng chỉ ra rằng tập bản ghi tài nguyên MX đã được một DNSKEY “example” ký với thuật toán 5 và thẻ khóa 38519. Resolver cần bản ghi tài nguyên DNSKEY tương ứng để xác thực trả lời này. Nội dung tiếp theo trình bày cách một Resolver có thể có được bản ghi tài nguyên DNSKEY này.

RRSIG chỉ ra TTL ban đầu của tập bản ghi tài nguyên MX là 3600 và vì mục đích xác thực, TTL hiện tại được thay thế bằng 3600. Giá trị trường các nhãn RRSIG là 3 chỉ ra rằng trả lời đã không là kết quả của phần mở rộng ký tự đại diện. Tập bản ghi tài nguyên MX của “x.w.example.com” được đặt trong dạng chính tắc và giả thiết thời gian hiện tại nằm giữa thời điểm hết hạn và bắt đầu của chữ ký, chữ ký được xác thực.

C.1.1  Xác thực bản ghi tài nguyên DNSKEY “example”

Ví dụ này trình bày quá trình xác thực lô gisc bắt đầu từ DNSKEY gốc được cấu hình và di chuyển xuống cây để xác thực bản ghi tài nguyên DNSKEY “example” mong muốn. Thực hiện có thể lựa chọn để xây dựng xác thực khi các tham chiếu được nhận hoặc để xây dựng chuỗi xác thực chỉ sau khi tất cả các tập bản ghi tài nguyên đã thu được hoặc trong bất kỳ một kết hợp nào khác mà nó thấy phù hợp. Ở đây, ví dụ chỉ mô tả quá trình lô gic này và không giải thích bất kỳ các nguyên tắc thực hiện.

Giả thiết là Resolver bắt đầu với một bản ghi tài nguyên DNSKEY được cấu hình dành cho root zone (hoặc một bản ghi tài nguyên DS được cấu hình dành cho root zone). Resolver kiểm tra xem bản ghi tài nguyên DNSKEY được cấu hình có hiện có trong tập bản ghi tài nguyên DNSKEY gốc (hoặc xem bản ghi tài nguyên DS có phù hợp một DNSKEY nào trong tập bản ghi tài nguyên DNSKEY gốc), xem bản ghi tài nguyên DNSKEY này đã ký tập bản ghi tài nguyên DNSKEY gốc và xem thời gian tồn tại chữ ký có hợp lệ. Khi tất cả các điều kiện này được thỏa mãn, tất cả các khoá trong tập bản ghi tài nguyên DNSKEY được xem là được xác thực. Tiếp theo, Resolver sử dụng một (hoặc nhiều) bản ghi tài nguyên DNSKEY gốc để xác thực tập bản ghi tài nguyên DS “example”. Chú ý rằng Resolver này có thể phải truy vấn root zone để thu được tập bản ghi tài nguyên DNSKEY gốc hoặc tập bản ghi tài nguyên DS “example”.

Khi tập bản ghi tài nguyên DS đã được xác thực bằng cách sử dụng DNSKEY gốc, Resolver kiểm tra tập bản ghi tài nguyên DNSKEY “example” dành cho bản ghi tài nguyên DNSKEY “example” nào đó phù hợp một trong các bản ghi tài nguyên DS “example” được xác thực. Khi một bản ghi tài nguyên DNSKEY như vậy đã ký tập bản ghi tài nguyên DNSKEY “example” và thời gian tồn tại của chữ ký là hợp lệ. Khi các điều kiện này được thỏa mãn, tất cả các khóa trong tập bản ghi tài nguyên DNSKEY “example” được xem là được xác thực.

Cuối cùng, Resolver kiểm ta xem một bản ghi tài nguyên DNSKEY nào đó trong tập bản ghi tài nguyên DNSKEY “example” sử dụng thuật toán 5 và có thẻ khóa là 38519. DNSKEY này được sử dụng để xác thực RRSIG được chứa trong trả lời. Khi nhiều bản ghi tài nguyên DNSKEY “example” phù hợp thuật toán và thẻ khóa này thì từng bản ghi tài nguyên DNSKEY được thử và trả lời được xác thực khi bất kỳ bản ghi tài nguyên DNSKEY phù hợp xác nhận chữ ký như được trình bày ở trên.

C.2  Lỗi tên miền

Truy vấn trong mục B.2 đã trả về các bản ghi tài nguyên NSEC chỉ ra rằng dữ liệu được yêu cầu không tồn tại và không có ký tự đại diện nào áp dụng. Việc kiểm tra cả hai bản ghi tài nguyên NSEC xác thực phản hồi phủ định này. Các bản ghi tài nguyên NSEC này được xác thực theo cách giống cách của tập bản ghi tài nguyên MX đã được trình bày ở trên.

C.3  Lỗi không có dữ liệu

Truy vấn trong mục B.3 trả về một bản ghi tài nguyên NSEC chỉ ra rằng tên miền được yêu cầu tồn tại nhưng loại bản ghi tài nguyên được yêu cầu không tồn tại. Việc kiểm tra bản ghi tài nguyên NSEC này xác thực phản hồi phủ định này bản ghi tài nguyên NSEC này được xác thực theo cách giống cách của tập Bản ghi tài nguyên MX đã được trình bày ở trên.

C.4  Tham chiếu đến Zone được ký

Truy vấn trong mục B.4 trả về một tham chiếu đến Zone được ký “example”. Bản ghi tài nguyên DS này được xác thực theo cách giống cách của tập bản ghi tài nguyên MX đã được trình bày ở trên. Bản ghi tài nguyên DS được sử dụng để xác thực tập bản ghi tài nguyên DNSKEY “a.example”.

Khi tập bản ghi tài nguyên DS “a.example” đã được xác thực bằng cách sử dụng DNSKEY “example”, Resolver kiểm tra tập bản ghi tài nguyên DNSKEY “a.example” dành cho một bản ghi tài nguyên DNSKEY “a.example” nào đó phù hợp bản ghi tài nguyên DS này. Khi một DNSKEY “a.example” phù hợp được tìm thấy, Resolver kiểm tra xem bản ghi tài nguyên DNSKEY này đã ký bộ DNSKEY “a.example” vDNSKEY “a.example” và xem thời gian tồn tại của chữ ký có hợp lệ. Khi tất cả các điều kiện này được thỏa mãn, tất cả các khóa trong tập bản ghi tài nguyên DNSKEY “a.example” được xem làm là xác thực.

C.5  Tham chiếu đến zone chưa được ký

Truy vấn trong mục B.5 trả về một tham chiếu đến một zone chưa được ký “b.example”. NSEC này chỉ ra rằng không có xác thực nào dẫn từ “example” đến “b.example” và bản ghi tài nguyên IMSEC này được xác thực theo cách giống cách của tập bản ghi tài nguyên MX đã được trình bày ở trên.

C.6  Phần mở rộng ký tự đại diện

Truy vấn trong mục B.6 trả về một trả lời được tạo ra là kết quả của phần mở rộng ký tự đại diện. Phần trả lời này chứa một tập bản ghi tài nguyên ký tự đại diện được mở rộng vì nó thuộc một trả lời DNS truyền thống và RRSIG tương ứng chỉ ra rằng tập bản ghi tài nguyên MX ký tự đại diện được mở rộng đã được DNSKEY “example” ký với thuật toán 5 và thẻ khóa 38519. RRSIG này chỉ ra rằng TTL ban đầu của tập bản ghi tài nguyên MX là 3600 và dành cho mục đích xác thực, TTL hiện tại được thay thế bằng 3600. Giá trị trường nhãn RRSIG là 2 chỉ ra rằng trả lời này là kết quả của phần mở rộng ký tự đại diện vì tên miền “a.z.w.example” chứa 4 nhãn. Tên miền “a.z.w.w.example” được thay thế bằng “*.w.example”, tập bản ghi tài nguyên MX được đặt theo dạng chính tắc và giả thiết rằng thời gian hiện tại nằm giữa thời điểm hết hạn và bắt đầu của chữ ký, chữ ký này được xác thực.

NSEC này chỉ ra rằng không có sự phù hợp hơn (giống hoặc gần giống ký tự đại diện) có thể đã được sử dụng để trả lời truy vấn này và bản ghi tài nguyên NSEC cũng phải được xác thực trước khi trả lời được xem là hợp lệ.

C.7  Lỗi không có dữ liệu ký tự đại diện

Truy vấn trong mục B.7 trả về các bản ghi tài nguyên NSEC chỉ ra rằng dữ liệu được yêu cầu không tồn tại và không có ký tự đại diện áp dụng. Việc kiểm tra cả hai bản ghi tài nguyên NSEC này xác thực phản hồi phủ định này.

C.8  Lỗi không có dữ liệu của zone con của DS

Truy vấn trong mục B.8 trả về các bản ghi tài nguyên NSEC chỉ ra rằng máy chủ con ( máy chủ “example”) trả lời truy vấn được yêu cầu này. Bản ghi tài nguyên NSEC này chỉ ra sự có mặt của một bản ghi tài nguyên SOA chỉ ra rằng trả lời này từ zone con. Các truy vấn dành cho tập bản ghi tài nguyên DS “example” nên được gửi đến các máy chủ cha (các máy chủ “gốc”).

Phụ lục D

(Quy định)

Các RFC cập nhật

Tiêu chuẩn này được xây dựng dựa trên RFC 4035. Theo quy luật tất yếu, RFC 4035 cập nhật thông tin đối với các RFC trước đó và các RFC được ban hành mới hơn RFC 4035, như RFC 4470, RFC 6014 và RFC 6840, sẽ cập nhật thông tin cho RFC 4035. Phụ lục này chỉ trình bày các thông tin được cập nhật cho RFC 4035. Để việc tham khảo thuận tiện, các mục trong tiêu chuẩn này sẽ được liên hệ với các mục tương ứng trong RFC 4035.

D.1  RFC 4470 “Minimally Covering NSEC Records and DNSSEC On-line Signing” - RFC 4470 “Các bản ghi tài nguyên NSEC bao trùm tối thiểu và ký trực tuyến DNSSEC”, 2006-04.

Tại trang 3 của RFC 4470:

Ánh xạ loại của bản ghi tài nguyên NSEC được tạo ra phải có các bit RRSIG và NSEC được thiết lập và không nên có bất kỳ bít nào khác được thiết lập. Điều này nới lỏng yêu cầu trong mục 4.3 (2.3 của RFC 4035) là các bản ghi tài nguyên NSEC không được xuất hiện ở các tên miền không tồn tại trước khi zone của nó được ký.

D.2  RFC 6014 “Cryptographic Algorithm Identifier Allocation for DNSSEC” - RFC 6014 “Phân bố nhận dạng thuật toán mật mã đối với DNSSEC”, 2010-11.

Tại trang 3 của RFC 6014:

2. Các yêu cầu về ấn định trong việc ký số thuật toán bảo mật DNS

Tiêu chuẩn này thay đổi yêu cầu về ký từ một RFC tiêu chuẩn tham chiếu sang một RFC được xuất bản dưới bất kỳ loại nào.

Có hai lý do để nới lỏng yêu cầu là:

- Có một số thuật toán có ích không thể nằm trong một RFC tiêu chuẩn tham chiếu. Vì các lý do nào đó, một thuật toán có thể đã không được đánh giá đủ kỹ lưỡng để có thể thành một tiêu chuẩn tham chiếu. Hoặc là thuật toán đó có thể có quyền sở hữu trí tuệ không rõ ràng đã ngăn cản thuật toán này được xây dựng thành một tiêu chuẩn tham chiếu.

- Mặc dù không gian ký bị hạn chế (khoảng 250 số), các thuật toán mới được đề xuất không thường xuyên. Nó có thể kéo dài nhiều thập kỷ trước khi có một lý do nào đó để xem xét lại việc hạn chế ký. Một số nhà phát triển sẽ quan tâm đến mức tiêu chuẩn của các RFC trong việc ký. Việc ký đã được cập nhật để phản ảnh mức tiêu chuẩn hiện tại của từng thuật toán được liệt kê.

Để giải quyết những lo ngại về việc đầy số ký, IETF nên đánh giá lại các yêu cầu đối với số ký khi số ký được ấn định xấp xỉ 120. Việc đánh giá này có thể dẫn đến những hạn chế chặt chẽ hơn hoặc một cơ chế mới để mở rộng không gian ký. Để việc đánh giá khả thi hơn, IANA đã đánh dấu khoảng một nửa số ký khả dụng là “Dự phòng” để việc đánh giá lại này có thời gian rõ ràng hơn.

Các giá trị 253 và 254 vẫn được dành cho các nhà phát triển muốn kiểm tra các thuật toán không nằm trong một RFC. Tiêu chuẩn này không làm thay đổi cú phát của hai giá trị này.

D.3  RFC 6840 “Clarifications and Implementation Notes for DNS Security (DNSSEC)” - RFC 6840 “Các chú ý làm rõ và thực hiện đối với phần mở rộng bảo mật DNS (DNSSEC)”, 2013-02.

Tại trang 5 của RFC 6840:

Mục 7.4 (5.4 của RFC4035) chưa quy định một thuật toán để kiểm tra các bằng chứng không tồn tại. Cụ thể là, thuật toán như được trình bày này sẽ cho phép phần xác nhận dịch một NSEC hoặc NSEC3 bản ghi tài nguyên từ zone nhóm cấp cao để 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.

Một bản ghi tài nguyên NSEC (hoặc bản ghi tài nguyên NSEC3) của “chuyển giao nhóm cấp cao” là một bản ghi tài nguyên có:

- Bit NS được thiết lập,

- Bit SOA bị xóa và

- Trường Signer ngắn hơn tên miền chủ của bản ghi tài nguyên NSEC hoặc tên miền chủ ban đầu đối với bản ghi tài nguyên NSEC3.

Tại trang 6 của RFC 6840:

Các bản ghi tài nguyên NSEC hoặc NSEC3 của chuyển giao nhóm cấp cao không được sử dụng để giả thiết sự không tồn tại của bất kỳ bản ghi tài nguyên nào dưới zone cut đó có chứa tất cả các bản ghi tài nguyên ở tên miền chủ (ban đầu) đó khác các bản ghi tài nguyên DS và tất cả các bản ghi tài nguyên dưới tên miền chủ đó của bất kỳ loại nào.

Tương tự như vậy, thuật toán này cũng sẽ cho phép một bản ghi tài nguyên NSEC ở tên miền chủ giống như một bản ghi tài nguyên DNAME hoặc một NSEC3 ở tên miền chủ ban đầu giống như một bản ghi tài nguyên DNAME để chứng minh sự không tồn tại của các tên miền bên dưới DNAME đó. Một bản ghi tài nguyên NSEC hoặc NSEC3 có bit DNAME được thiết lập không được sử dụng để giả thiết sự không tồn tại của bất kỳ miền con của tên miền chủ (ban đầu) của NSEC/NSEC3.

[RFC4035] không đưa ra cách xác nhận các trả lời khi QTYPE=*. Trong mục 6.2.2 của [RFC1034] đã đưa ra, một trả lời phù hợp đối với QTYPE=* có thể chứa một tập con các tập bản ghi tài nguyên ở một tên miền đã cho. Tức là, việc chứa tất cả các tập bản ghi tài nguyên ở QNAME trong trả lời này là không cần thiết.

Khi xác nhận một trả lời đối với QTYPE=*, tất cả các tập bản ghi tài nguyên nhận được phù hợp với QNAME và QCLASS phải được xác nhận. Khi có bất kỳ tập bản ghi tài nguyên nào không được xác nhận, trả lời được xem là giả mạo. Khi không có tập bản ghi tài nguyên phù hợp QNAME và QCLASS, điều này phải được xác nhận theo các nguyên tắc trong mục 7.4 (5.4 của RFC4035). Tức là, phần xác nhận không được nhận tất cả các bản ghi tài nguyên ở QNAME để phản hồi đối với QTYPE=*.

Mục 7 (5 của RFC4035) trình bày không có gì rõ ràng về việc xác nhận các trả lời dựa trên (hoặc nên được dựa trên) các CNAME. Khi xác nhận một trả lời NOERROR/NODATA, các phần xác nhận 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 ngoài bit dành cho loại truy vấn.

Nếu không có việc kiểm tra này, kẻ tấn công có thể chuyển đổi thành công một phản hồi CNAME khẳng định thành một phản hồi NOERROR/NODATA (ví dụ như) bằng cách đơn giản lấy tập bản ghi tài nguyên CNAME từ trả lời này. Sau đó, một phần xác nhận không có sự nghi ngờ sẽ xác nhận rằng QTYPE đã không hiện có trong bản ghi tài nguyên NSEC/NSEC3 phù hợp nhưng không nhận thấy rằng bit CNAME đã được thiết lập, do đó, trả lời này nên là một phản hồi CNAME khẳng định.

Tại trang 7 của RFC 6840:

Mục 7.2 (5.2 của RFC4035) quy định rằng khi chứng minh một chuyển giao là không bảo mật thì 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 này 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 một bản ghi tài nguyên NSEC3 có cờ Opt-Out được thiết lập bao trùm.

Không có việc kiểm tra này, kẻ tấn công có thể tái sử dụng một bản ghi tài nguyên NSEC hoặc NSEC3 phù hợp một tên miền không chuyển giao để chứng minh một chuyển giao không được ký ở tên miền đó. Điều này sẽ khẳng định rằng một tập bản ghi tài nguyên được ký (hoặc tập của các tập bản ghi tài nguyên) hiện có là dưới một chuyển giao không được ký, do đó, không được ký và dễ bị tấn công hơn.

Mục 7.2 (5.2 của RFC4035) đưa ra các nguyên tắc cho cách xử lý các chuyển giao đến các Zone được ký có các thuật toán KEY công khai không được hỗ trợ hoàn toàn như được các thuật toán KEY được trình bày trong các tập bản ghi tài nguyên DS của các zone này chỉ ra. Nó không giải quyết một cách rõ ràng cách để xử lý các bản ghi tài nguyên DS có sử dụng các thuật toán tóm tắt bản tin không được hỗ trợ. Tóm lại, các bản ghi tài nguyên DS có sử dụng các 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ử theo cách giống 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 KEY công khai không được hỗ trợ hoặc mới lạ.

Tại trang 8 của RFC 6840:

Nội dung hiện tại là:

Khi phần xác nhận không hỗ trợ bất kỳ thuật toán được liệt kê trong một tập bản ghi tài nguyên DS được xác thực thì phần xử lý này không hỗ trợ liên kết xác thực dẫn từ cha đến con. Phần xử lý nên xử lý trường hợp này khi nó là trường hợp của một tập bản ghi tài nguyên NSEC được xác thực chỉ ra rằng không có tập bản ghi tài nguyên DS nào tồn tại như đã được trình bày ở trên.

Nói cách khác, khi xác định trạng thái bảo mật của một zone, phần xác nhận không quan tâm đến bất kỳ các bản ghi tài nguyên DS được xác thực có quy định các thuật toán DNSKEY không được hỗ trợ hoặc mới lạ. Khi không còn thuật toán nào phù hợp, zone này được xử lý là chưa được ký.

Tiêu chuẩn này sửa đổi nội dung trên để cũng không quan tâm đến các bản ghi tài nguyên DS được xác thực có sử dụng các thuật toán tóm tắt bản tin không được hỗ trợ hoặc mới lại.

Trang 10

Cú pháp của bit AD trong truy vấn không được xác định trước đây. Mục 6.6 (4.6 của RFC4035) đã chỉ dẫn các phần xử lý luôn luôn xóa bit AD khi xây dựng các truy vấn.

Tiêu chuẩn này xác định việc thiết lập bit AD trong một truy vấn là một tín hiệu chỉ ra rằng phần yêu cầu hiểu và quan tâm đến giá trị của bit AD trong trả lời. Điều này cho phép phần yêu cầu chỉ ra rằng nó hiểu bit AD mà không yêu cầu dữ liệu DNSSEC thông qua bit DO.

Mục 5.2.3 (3.2.3 của RFC4035) mô tả theo các điều kiện nào một phần xử lý xác nhận nên thiết lập hoặc xóa bit AD trong một trả lời. Để tương thích với các phần xử lý cụt cũ và các phần trung gian không hiểu hoặc không quan tâm bit AD, các phần xử lý xác nhận chỉ nên thiết lập bit AD khi trả lời thỏa mãn cả các điều kiện được liệt kê trong mục 5.2.3 (3.2.3 của RFC4035) và yêu cầu chứa bit DO được thiết lập hoặc bit AD được thiết lập.

Khi xử lý một yêu cầu có bit CD được thiết lập, phần xử lý nên trả về tất cả các dữ liệu trả lời, kể cả dữ liệu có xác nhận DNSSEC không thành công. Mục 5.2.2 (3.2.2 của RFC4035) yêu cầu một phần xử lý xử lý một yêu cầu có bit CD được thiết lập để thiết lập bit CD này trên các truy vấn hướng lên của nó.

Tiêu chuẩn này quy định thêm rằng các phần xử lý xác nhận nên thiết lập bit CD trên từng truy vấn hướng lên. Điều này không quan tâm là bit CD đã được thiết lập trên truy vấn tới hay nó có mỏ neo tin cật ở hoặc trên QNAME.

[RFC4035] không rõ ràng về điều cần làm khi thu được một trả lời được nhớ đệm có bit CD không được thiết lập, trường hợp chỉ phát sinh khi phần xử lý này lựa chọn không thiết lập bit CD trên tất cả các truy vấn hướng lên như được quy định ở trên. Trong trường hợp điển hình này, không yêu cầu một truy vấn mới nào cũng không cần nhớ đệm theo dõi trạng thái bit CD được sử dụng để thực hiện một truy vấn đã cho. Vấn đề này phát sinh khi trả lời được nhớ đệm là một lỗi máy chủ (RCODE2), nó có thể chỉ ra rằng dữ liệu được yêu cầu không được xác nhận DNSSEC thành công ở phần xử lý xác nhận hướng lên. ([RFC2308] cho phép nhớ đệm các lỗi máy chủ lên đến 5 phút). Trong các trường hợp này, yêu cầu một truy vấn mới có bit CD được thiết lập.

Trang 11

Đoạn cuối của mục 4.2 (2.2 của RFC4035) trình bày các nguyên tắc mô tả các thuật toán phải được sử dụng để ký một zone. Vì các nguyên tắc này khó hiểu, chúng được trình bày lại bằng cách sử dụng một cách diễn đạt khác như sau:

Các tập bản ghi tài nguyên DS và DNSKEY được sử dụng để thông báo thuật toán được sử dụng để ký một zone. Sự có mặt của một thuật toán trong tập bản ghi tài nguyên DS hoặc DNSKEY của zone thông báo rằng thuật toán đó được sử dụng để ký zone này. Một Zone được ký phải chứa một DNSKEY dành cho từng thuật toán hiện có trong tập bản ghi tài nguyên DS của zone này và các Trust Anchor dành cho zone này. Zone này cũng phải được ký với từng thuật toán (mặc dù không với từng khóa mã) hiện có trong tập bản ghi tài nguyên DNSKEY. Việc thêm các thuật toán ở DNSKEY không có trong bản ghi tài nguyên DS là có thể nhưng không theo chiều ngược lại. Khi có nhiều hơn một khóa của cùng một thuật toán trong tập bản ghi tài nguyên DNSKEY, việc ký từng tập bản ghi tài nguyên với bất kỳ tập con của các DNSKEY là có thể chấp nhận.

Việc ký một số các tập bản ghi tài nguyên với một tập con của các khóa (hoặc một khóa) và các tập bản ghi tài nguyên khác với một tập con khác là có thể chấp nhận miễn sao có ít nhất một DNSKEY của từng thuật toán được sử dụng để ký từng tập bản ghi tài nguyên.

Tương tự như vậy, khi có nhiều bản ghi tài nguyên DS dành cho nhiều khóa của cùng một thuật toán thì bất kỳ tập con của chúng có thể xuất hiện trong tập bản ghi tài nguyên DNSKEY này.

Trang 12

Yêu cầu này áp dụng cho các máy chủ, không áp dụng cho các phần xác nhận. Các phần xác nhận nên chấp nhận bất kỳ một liên kết hợp pháp. Chúng không nên yêu cầu rằng tất cả các thuật toán được thông báo trong tập bản ghi tài nguyên DS đều làm việc và chúng không được yêu cầu tất cả các thuật toán được thông báo trong tập bản ghi tài nguyên DNSKEY đều làm việc. Một phần xác nhận có thể có một cấu hình tùy chọn để thực hiện một kiểm tra đầy đủ chữ ký để hỗ trợ xử lý sự cố.

Và

Mục C.8 (C.8 của RFC4035) thảo luận việc gửi các truy vấn DS đến các máy chủ đối với một zonecha nhưng không đưa ra cách để tìm kiếm các máy chủ này. Các hướng dẫn cụ thể này có thể được trình bày trong mục 6.2 (4.2 của RFC4035).

Trang 13

Nội dung trong mục C.1 (C.1 của RFC4035) tham chiếu đến các ví dụ trong mục B.1 như “x.w.example.com” trong khi mục B.1 sử dụng “x.w.example”. Điều này dẫn đến một lỗi hiển nhiên trong đoạn văn thứ hai khi nó đưa ra rằng giá trị trường các nhãn RRSIG là 3 chỉ ra rằng trả lời không là kết quả của phần mở rộng ký tự đại diện. Điều này chỉ đúng đối với “x.w.example” nhưng không phải đối với “x.w.example.com”, vì số nhãn của nó là 4 (ngược lại, số nhãn là 3 sẽ ám chỉ trả lời là kết quả của phần mở rộng ký tự đại diện).

Đoạn đầu tiên của mục C.6 (C.6 của RFC4035) cũng có một lỗi nhỏ: tham chiếu đến “a.z.w.w.example” nên được thay bằng “a.z.w.example".

Thư mục tài liệu tham khảo

[1] Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[2] RFC 4470 Weiler, S. and J. Ihren, “Minimally Covering NSEC Records and DNSSEC On-line Signing”, RFC 4470, April 2006.

[3] RFC 6014 Hoffman, P., “Cryptographic Algorithm Identifier Allocation for DNSSEC”, RFC 6014, November 2010.

[4] RFC 6840 Weiler, S., Ed. And D. Blacka, Ed. “Clarifications and Implementation Notes for DNS Security (DNSSEC)”, RFC 6840, February 2013.

[5] RFC 4035Arends, R., Austein, R., Larson, M., Massey, D., and S.Rose, “Protocol Protocol Modifications for the DNS Security Extensions”, RFC 4035, March 2005.

MỤC LỤC

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ, ký hiệu và chữ viết tắt

3.1  Thuật ngữ

3.2  Ký hiệu

3.3  Chữ viết tắt

4  Ký zone

4.1  Các bản ghi tài nguyên DNSKEY trong một zone

4.2  Các bản ghi tài nguyên RRSIG trong một zone

4.3  Các bản ghi tài nguyên NSEC trong một zone

4.4  Các bản ghi tài nguyên DS trong một zone

4.5  Những thay đổi đối với bản ghi tài nguyên CNAME

4.6  Các loại bản ghi tài nguyên DNSSEC xuất hiện ở zone cut

4.7  Ví dụ một zone có bảo mật

5  Hoạt động

5.1  Các máy chủ tên miền có thẩm quyền

5.2  Recursive Name Server

5.3  Ví dụ các trả lời DNSSEC

6  Phân giải

6.1  Hỗ trợ EDNS

6.2  Hỗ trợ kiểm tra chữ ký

6.3  Xác định trạng thái bảo mật của dữ liệu

6.4  Trust Anchor được cấu hình

6.5  Phản hồi của bộ đệm

6.6  Xử lý các bit CD và AD

6.7  Dữ liệu bộ đệm BAD

6.8  Các CNAME được đồng bộ

6.9  Các Stub Resolver

7  Xác thực các trả lời DNS

7.1  Các vấn đề đặc biệt về cô lập bảo mật

7.2  Xác thực các tham chiếu

7.3  Xác thực một tập bản ghi tài nguyên bằng một bản ghi tài nguyên RRSIG

7.4  Xác thực từ chối sự tồn tại

7.5  Trạng thái Resolver khi các chữ ký không xác nhận

7.6  Ví dụ về xác thực

8  Các vấn đề IANA

9  Các vấn đề bảo mật

Phụ lục A (Tham khảo) - Ví dụ Zone được ký

Phụ lục B (Tham khảo) - Ví dụ các trả lời

Phụ lục C (Tham khảo) - Các ví dụ xác thực

Phụ lục D (Quy định) - Các RFC cập nhật

Thư mục tài liệu tham khảo