Bản ghi NSEC chỉ ra rằng không có bản ghi DS dành cho ủy quyền này tồn tại trong zone cha. ;; Header: QR DO RCODE=0 ;; ;; Question mc.b.example. IN MX ;; Answer ;; (empty) ;; Authority b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns2.b.example.
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example. GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ vhRXgWT7OuFXldoCG6TfVFMs9xE= ) ;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8 B.6 Phần mở rộng ký tự đại diện
Một truy vấn thành công đã được trả lời thông qua phần mở rộng ký tự đại diện. Số nhãn trong bản ghi RRSIG của trả lời chỉ ra rằng một tập bản ghi ký tự đại diện đã được mở rộng để tạo nên trả lời này và bản ghi NSEC chỉ ra rằng không có sự phù hợp hơn tồn tại trong zone này.
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX ;; Answer a.z.w.example. 3600 IN MX 1 ai.example. a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw 4kX18MMR34i8lC36SR5xBni8vHI= ) ;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example.
example. 3600 RRSIG NS 5 1 3600 20040509183619 ( 20040409183619 38519 example. gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) ;; Additional ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( 20040409183619 38519 example. pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( 20040409183619 38519 example. nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 sZM6QjBBLmukH30+w1z3h8PUP2o= )
B.7 Lỗi không có dữ liệu ký tự đại diện
Trả lời “no data” dành cho một tên được một ký tự đại diện bao trùm. Các bản ghi NSEC chỉ ra rằng tên ký tự đại diện phù hợp không có bất kỳ bản ghi nào của loại được yêu cầu và không có phù hợp này tồn tại trong zone này.
;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA ;; Answer ;; (empty) ;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377 3600 300 3600000 3600 )
example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example. OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example. r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 s1InQ2UoIv6tJEaaKkP701j8OLA= ) ;; Additional ;; (empty)
B.8 Lỗi không có dữ liệu của zone con của DS
Trả lời “no data” dành cho truy vấn QTYPE=DS được gửi nhầm tới máy chủ tên miền dành cho zone con. ;; Header: QR AA DO RCODE=0 ;; ;; Question example. IN DS ;; Answer ;; (empty) ;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377 3600 300 3600000 3600 )
example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example. O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm jfFJ5arXf4nPxp/kEowGgBRzY/U= ) ;; Additional ;; (empty)
Phụ lục C - 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 MX dành cho “x.w.example”. RRSIG tương ứng chỉ ra rằng tập bản ghi 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 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 DNSKEY này.
RRSIG chỉ ra TTL ban đầu của tập bản ghi 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 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 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 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 đã 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 DNSKEY được cấu hình dành cho root zone (hoặc một bản ghi DS được cấu hình dành cho root zone). Resolver kiểm tra xem bản ghi DNSKEY được cấu hình có hiện có trong tập bản ghi DNSKEY gốc (hoặc xem bản ghi DS có phù hợp một DNSKEY nào trong tập bản ghi DNSKEY gốc), xem bản ghi DNSKEY này đã ký tập bản ghi 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 khá trong tập bản ghi 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 DNSKEY gốc để xác thực tập bản ghi DS “example”. Chú ý rằng Resolver này có thể phải truy vấn root zone để thu được tập bản ghi DNSKEY gốc hoặc tập bản ghi DS “example”.
Khi tập bản ghi DS đã được xác thực bằng cách sử dụng DNSKEY gốc, Resolver kiểm ta tập bản ghi DNSKEY “example” dành cho bản ghi DNSKEY “example” nào đó phù hợp một trong các bản ghi DS “example” được xác thực. Khi môt bản ghi DNSKEY như vậy đã ký tập bản ghi 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 tong tập bản ghi DNSKEY “example” được xem là được xác thực.
Cuối cùng, Resolver kiểm ta xem một bản ghi DNSKEY nào đó trong tập bản ghi 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 DNSKEY “example” phù hợp thuật toán và thẻ khóa này thì từng bản ghi DNSKEY được thử và trả lời được xác thực khi bất kỳ bản ghi DNSKEY phù hợp xác nhận chữ ký như được trình bày ở trên.
C.2 Lỗi tên
Truy vấn trong mục B.2 đã trả về các bản ghi 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 NSEC xác thực trả lời âm này. Các bản ghi NSEC này được xác thực theo cách giống cách của tập bản ghi 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 NSEC chỉ ra rằng tên được yêu cầu tồn tại nhưng loại bản ghi được yêu cầu không tồn tại. Việc kiểm tra bản ghi NSEC này xác thực trả lời âm này. bản ghi NSEC này được xác thực theo cách giống cách của tập bản ghi MX đã được trình bày ở trên.
C.4 Tham chiếu đến Signed Zone
Truy vấn trong mục B.4 trả về một tham chiếu đến Signed Zone “example”. Bản ghi DS này được xác thực theo cách giống cách của tập bản ghi MX đã được trình bày ở trên. Bản ghi DS được sử dụng để xác thực tập bản ghi DNSKEY “a.example”.
Khi tập bản ghi 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 DNSKEY “a.example” dành cho một bản ghi DNSKEY “a.example” nào đó phù hợp bản ghi 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 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 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 NSEC này được xác thực theo cách giống cách của tập bản ghi 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 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 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 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 “a.z.w.example” chứa 4 nhãn. Tên “a.z.w.w.example” được thay thế bằng “*.w.example”, tập bản ghi 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 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 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 NSEC này xác thực trả lời âm 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 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 NSEC này chỉ ra sự có mặt của một bản ghi 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 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 – 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 NSEC bao trùm tối thiểu và ký trực tuyến DNSSEC”, 2006-04.
Trang 3:
Ánh xạ loại của bản ghi 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ỳ bit nào khác được thiết lập. Điều này nới lỏng yêu cầu trong mục 5.3 (2.3 của RFC 4035) là các bản ghi NSEC không được xuất hiện ở các tê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.
Trang 3:
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 để lớ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.
Trang 5:
Mục 8.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ừ zone nhóm cấp cao để chứng minh sự không tồn tại của một bản ghi trong một zone con. Một bản ghi NSEC (hoặc bản ghi NSEC3) của “ủy quyền nhóm cấp cao” là một bản ghi có:
- Bit NS được thiết lập,
- Bit SOA bị xóa và
- Trường Signer ngắn hơn tên sở hữu của bản ghi NSEC hoặc tên sở hữu ban đầu đối với bản ghi NSEC3.
Trang 6
Các bản ghi NSEC hoặc NSEC3 của ủy quyền 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 nào dưới zone cut đó có chứa tất cả các bản ghi ở tên sở hữu (ban đầu) đó khác các bản ghi DS và tất cả các bản ghi dưới tên sở hữu đó 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 NSEC ở tên sở hữu giống như một bản ghi DNAME hoặc một NSEC3 ở tên sở hữu ban đầu giống như một bản ghi DNAME để chứng minh sự không tồn tại của các tên bên dưới DNAME đó. Một bản ghiNSEC 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 sở hữu (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 ở một tên đã cho. Tức là, việc chứa tất cả các tập bản ghi ở 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 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 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 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 8.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 ở QNAME để phàn hồi đối với QTYPE=*.
Mục 8 (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 NSEC hoặc NSEC3 ngoài bit dành cho loại truy vấn.