Định nghĩa
Theo mục đích của tiêu chuẩn này, các định nghĩa sau đây được áp dụng:
BAD cache: Bộ nhớ dữ liệu có các chữ ký không hợp lệ.
Island of Security: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
Non-Validating Security-Aware Stub Resolver: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc
Non-Validating Stub Resolver: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
Phần mở rộng bảo mật hệ thống tên miền (DNSSEC) là một tập hợp các bản ghi tài nguyên mới và cải tiến giao thức nhằm cung cấp xác thực nguồn gốc dữ liệu và đảm bảo tính toàn vẹn cho hệ thống DNS.
Security-Aware Name Server: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
Security-Aware Recursive Name Server: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC
Security-Aware Resolver: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
Security-Aware Stub Resolver: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
Security-Oblivious < … >: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
Signed Zone (Zone được ký): Một zone có các tập bản ghi đượ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 ký ủy quyền (DS).
Stub Resolver: Tham khảo mục 3.1 của TCVN xxxx: 2015.
Trust Anchor: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
Unsigned Zone (Zone chưa được ký): Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033). Validating Security-Aware Stub Resolver: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC
Zone Apex: Tham khảo mục 3.1 của TCVN xxxx: 2015 (hoặc RFC 4033).
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à zone cha
(ở bên trên ranh giới) (RFC 2181).
Zone Key: Khóa của zone.
Zone Transfer: Chuyển thông tin tên miên của zone.
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.
Ký tự
Theo mục đích của tiêu chuẩn này, ký tự sau đây được áp dụng:
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:
AD Authentic Data Dữ liệu chứng thực
AXFR Full Zone Transfer Đồng bộ toàn phần
CD Checking Disabled Kiểm tra vô hiệu hóa
CNAME Canonical Name Tên chính tắc
DNAME Delegation Name Tên ủy quyền
DNS Domain Name System Hệ thống tên miền
DNSKEY DNS Public KEY Khóa công khai DNS
DNSSEC DNS Security Extensions Phần mở rộng bảo mật DNS
DS Delegation Signer Ký ủy quyền
EDNS Extension Mechanisms for DNS Các cơ chế mở rộng cho DNS
IANA Internet Assigned Numbers Authority Tổ chức cấp phát số hiệu Internet IXFR Incremental Zone Transfer Đồng bộ một phần
NS Name Server Máy chủ tên miền
NSEC Next Secure Bảo mật kế tiếp
QCLASS Query CLASS Lớp của truy vấn
QNAME Qualified NAME (a target domain name) Tên miền đích
QTYPE Query TYPE Loại của truy vấn
RCODE Response CODE Mã trả lời
RDATA Repair DATA Dữ liệu thay thế
RR Resource Record Bản ghi tài nguyên
RRSIG Resource Record Signature Chữ ký bản ghi tài nguyên
SCLASS the QCLASS of the search request QCLASS của truy vấn tìm kiếm
SNAME the domain name we are searching for Tên miền cần tìm kiếm
The Start of Authority (SOA) record is a crucial component of a zone file, indicating the primary source of information for that zone It includes essential details such as the type of query (QTYPE) associated with the search request, which helps in managing DNS resolution effectively.
TTL Time to Live Thời gian tồn tại
DNSSEC giới thiệu khái niệm về các Signed Zone, bao gồm 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 ký ủy quyền (DS) Các bản ghi này phải tuân theo các nguyên tắc quy định trong các mục 4.1, 4.2, 4.3 và 4.4 Nếu zone không có các bản ghi theo các nguyên tắc này, thì được coi là zone chưa được ký.
DNSSEC yêu cầu điều chỉnh định nghĩa bản ghi tài nguyên CNAME theo RFC 1035 Cụ thể, mục 4.5 cho phép các bản ghi RRSIG và NSEC xuất hiện cùng tên sở hữu với bản ghi CNAME.
DNSSEC quy định sự xuất hiện của hai loại bản ghi mới, NSEC và DS, có thể được đặt tại phía cha của zone cut, tức là tại điểm chuyển giao Đây là một ngoại lệ đối với quy định cấm đưa dữ liệu vào zone cha tại zone cut Thay đổi này được trình bày trong mục 4.6.
Các bản ghi DNSKEY trong một zone
Để ký một zone, quản trị viên cần tạo một hoặc nhiều cặp khóa công khai/mật và sử dụng các khóa mật này để ký các bản ghi có thẩm quyền trong zone Mỗi khóa mật sử dụng để tạo các bản ghi RRSIG phải có một bản ghi DNSKEY tương ứng chứa khóa công khai Bản ghi DNSKEY này cần có bit khóa công khai thuộc trường Flags RDATA được thiết lập theo RFC 4034 Các khóa công khai không được xác định là khóa công khai của zone sẽ không được sử dụng để kiểm tra các RRSIG.
Khi quản trị một zone, việc thiết lập một Signed Zone không chỉ tạo ra một Island of Security mà còn yêu cầu zone apex phải có ít nhất một bản ghi DNSKEY Bản ghi này hoạt động như một điểm truy nhập bảo mật cho zone, cho phép nó trở thành mục tiêu của một ủy quyền bảo mật thông qua bản ghi DS tương ứng trong zone cha, theo quy định trong RFC 4034.
Các bản ghi RRSIG trong một zone
Đối với mỗi tập bản ghi có thẩm quyền trong một Signed Zone, phải có ít nhất một bản ghi RRSIG đáp ứng các yêu cầu sau:
− Tên sở hữu RRSIG này giống tên sở hữu tập bản ghi này.
− Lớp RRSIG này giống lớp của tập bản ghi này.
− Trường RRSIG Type Covered giống loại của tập bản ghi này.
− Trường RRSIG Original TTL giống TTL của tập bản ghi này.
− TTL của bản ghi RRSIG này giống TTL của tập bản ghi này.
Trường RRSIG Labels tương ứng với số nhãn trong tên sở hữu của tập bản ghi, ngoại trừ nhãn null root và nhãn bên trái ngoài cùng khi được biểu thị bằng ký tự đại diện.
− Trường Name của RRSIG Signer giống tên của zone chứa tập bản ghi này.
− Các trường RRSIG Algorithm, Name của Signer và Key Tag giống bản ghi 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 RRSIG đối với một tập bản ghi cho trước được trình bày trong RFC
Bản ghi RRSIG có thể liên kết với nhiều bản ghi trong cùng một tập, nhưng các chữ ký trong bản ghi RRSIG không giống như các loại bản ghi DNS khác và không tạo thành các tập bản ghi Đặc biệt, giá trị TTL trong các bản ghi RRSIG có tên sở hữu chung không tuân theo các nguyên tắc của tập bản ghi theo RFC 2181.
Bản ghi RRSIG không thể được tự ký, vì việc ký một bản ghi như vậy sẽ không có giá trị và dẫn đến một vòng lặp không xác định trong quá trình ký.
Tập bản ghi NS tại tên của zone apex cần được ký, trong khi các tập bản ghi NS tại các điểm chuyển giao không yêu cầu ký Điều này có nghĩa là các tập bản ghi NS trong zone cha ủy quyền cho máy chủ tên miền của zone con không được ký Hơn nữa, các tập bản ghi địa chỉ liên kết với những ủy quyền không được ký cũng cần lưu ý.
Mỗi tập bản ghi DNS tại zone apex cần có một RRSIG, sử dụng ít nhất một DNSKEY từ mỗi thuật toán có trong tập bản ghi DNSKEY Tập bản ghi DNS này phải được tự ký bằng tất cả các thuật toán có trong tập bản ghi DS được đặt tại cha ủy quyền, nếu có.
Các bản ghi NSEC trong một zone
Mỗi tên miền trong khu vực phải có bản ghi tài nguyên NSEC, đảm bảo dữ liệu có thẩm quyền hoặc tập bản ghi NS tại điểm chuyển giao Định dạng và quy trình xây dựng bản ghi NSEC cho tên miền cụ thể được quy định trong RFC 4034.
Giá trị TTL đối với bất kỳ bản ghi NSEC nên giống trường giá trị TTL tối thiểu trong bản ghi SOA của zone này.
Một bản ghi NSEC cùng với tập bản ghi RRSIG liên quan không được là bản ghi duy nhất tại một tên sở hữu cụ thể nào Quá trình ký này không tạo ra các bản ghi NSEC hoặc RRSIG cho những nút tên sở hữu chưa được ký Điều này nhằm đảm bảo tính nhất quán trong không gian tên giữa các phiên bản ký và chưa ký của cùng một zone, đồng thời giảm thiểu nguy cơ mất nhất quán trong các máy chủ tên miền đệ quy không có bảo mật Mỗi bản ghi NSEC trong một Zone đã ký cần phải chỉ ra sự tồn tại của cả bản ghi NSEC và bản ghi RRSIG tương ứng.
Sự khác biệt giữa bộ tên sở hữu yêu cầu bản ghi RRSIG và bộ tên sở hữu yêu cầu bản ghi NSEC rất tinh vi Bản ghi RRSIG xuất hiện ở tất cả các tên sở hữu của các tập bản ghi có thẩm quyền, trong khi bản ghi NSEC có mặt ở các tên sở hữu mà Signed Zone có thẩm quyền và ở các tên sở hữu của các ủy quyền từ Signed Zone sang zone con Cần lưu ý rằng bản ghi NSEC hoặc RRSIG không tồn tại ở các tên sở hữu của các tập bản ghi địa chỉ liên kết trong zone cha Tuy nhiên, 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 NSEC là dữ liệu có thẩm quyền và do đó được ký Do đó, mọi tên sở hữu có một tập bản ghi NSEC cũng sẽ có các bản ghi RRSIG trong Signed Zone.
Ánh xạ bản ghi NSEC tại điểm chuyển giao cần được chú ý đặc biệt Các bit tương ứng của tập bản ghi NS ủy quyền và những tập bản ghi mà zone cha có quyền dữ liệu phải được thiết lập, trong khi các bit tương ứng của những tập bản ghi không phải NS mà zone cha không có quyền phải được xóa bỏ.
Các bản ghi DS trong một zone
Bản ghi DS thiết lập chuỗi xác thực giữa các zone DNS và cần có tại điểm chuyển giao khi zone con được ký Tập bản ghi DS có thể chứa nhiều bản ghi, mỗi bản ghi tham chiếu đến một khóa công khai trong zone con để kiểm tra RRSIG Tất cả các bản ghi DS trong một zone phải được ký và không được xuất hiện tại zone apex Một bản ghi DS chỉ nên tham chiếu đến một bản ghi DNSKEY trong tập bản ghi DNSKEY của zone apex của phía con, và bản ghi DNSKEY này cần được ký bằng khóa mật tương ứng Những bản ghi DS không đáp ứng điều kiện này sẽ không được dùng để xác nhận, dẫn đến khả năng xảy ra những điểm không thống nhất tạm thời do tính nhất quán lỏng lẻo của DNS.
TTL của bản ghi DS cần phải tương thích với TTL của bản ghi NS ủy quyền, tức là bản ghi NS trong cùng một zone với bản ghi DS.
Việc tạo lập bản ghi DS đòi hỏi phải nắm rõ bản ghi DNSKEY trong zone con, điều này thể hiện sự liên kết giữa các zone cha và con Tuy nhiên, mối quan hệ này lại không được đề cập rõ ràng trong các tiêu chuẩn hiện hành.
Những thay đổi đối với bản ghi tài nguyên CNAME
Khi một bản ghi CNAME xuất hiện trong một Signed Zone, cần có các bản ghi RRSIG và NSEC tương ứng, cùng với bản ghi KEY để hỗ trợ cập nhật bảo mật động (RFC 3007) Điều này đánh dấu sự thay đổi so với định nghĩa gốc của CNAME trong RFC 1034, nơi không cho phép các loại bản ghi khác xuất hiện cùng với CNAME Tuy nhiên, trong một Signed Zone, yêu cầu về các bản ghi NSEC và RRSIG cho mỗi tên có thẩm quyền đã dẫn đến việc điều chỉnh định nghĩa của bản ghi CNAME, cho phép nó đồng thời tồn tại với các bản ghi NSEC và RRSIG.
Các loại bản ghi DNSSEC xuất hiện ở zone cut
DNSSEC giới thiệu hai loại bản ghi mới thường xuất hiện ở phía cha của mặt cắt Tại điểm chuyển giao của zone cut, yêu cầu bản ghi NSEC phải có ở tên sở hữu Ngoài ra, bản ghi DS cũng có thể xuất hiện khi zone được ủy quyền được ký, nhằm tạo chuỗi xác thực với zone cha Đây là một ngoại lệ so với tiêu chuẩn DNS gốc (RFC 1034), chỉ cho phép các bản ghi NS xuất hiện ở phía cha của zone cut.
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 Signed Zone nhỏ
Mục này mô tả hành vi của các phần tử với chức năng máy chủ tên miền nhận thức về bảo mật (Security-Aware Name Server) Trong nhiều trường hợp, các chức năng này sẽ được tích hợp vào máy chủ tên miền đệ quy nhận thức về bảo mật (Security-Aware Recursive Name Server) Tuy nhiên, máy chủ tên miền có thẩm quyền cũng có những yêu cầu bảo mật tương tự Các chức năng dành cho máy chủ tên miền đệ quy nhận thức về bảo mật được trình bày trong mục 5.2, trong khi các yêu cầu cho máy chủ có thẩm quyền được nêu 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.
Máy chủ tên an toàn (Security-Aware Name Server) cần hỗ trợ EDNS0 (RFC 2671) với kích thước bản tin tối thiểu là 1220 octet và lý tưởng nên hỗ trợ kích thước lên đến 4000 octet Do các gói tin IPv6 chỉ có thể được máy chủ nguồn phân đoạn, máy chủ này cần đảm bảo rằng các gói UDP truyền qua IPv6 được phân đoạn theo mức MTU IPv6 tối thiểu, trừ khi đã biết MTU của tuyến đường Để biết thêm chi tiết về phân đoạn và kích thước gói tin, tham khảo các tài liệu RFC 1122, RFC 2460 và RFC 3226.
Một máy chủ tên an toàn sẽ đáp ứng các truy vấn DNS không có bản ghi giả EDNS OPT hoặc có bit DO trống bằng cách cung cấp các bản ghi RRSIG, DNSKEY và NSEC, giống như bất kỳ tập bản ghi nào khác, mà không thực hiện các hành động bổ sung Do bản ghi DS chỉ xuất hiện trong zone cha tại các điểm chuyển giao, chúng luôn yêu cầu một hành động đặc biệt như được mô tả trong mục 5.1.4.1.
Các Security-Aware Name Server xử lý các truy vấn liên quan đến bản ghi bảo mật cho nhiều zone mà chúng phục vụ, như NSEC và RRSIG, đảm bảo tính nhất quán trong các phản hồi Máy chủ tên miền này có thể cung cấp các kết quả khác nhau miễn là các phản hồi luôn giữ sự nhất quán cho mỗi truy vấn.
− Các tập bản ghi trên điểm chuyển giao.
− Các tập bản ghi dưới điểm chuyển giao
− Cả hai tập bản ghi trên và dưới điểm chuyển giao.
− Phần trả lời trống (không có bản ghi).
− Một trả lời khác nào đó.
DNSSEC giới thiệu hai bit mới trong phần đầu của bản tin DNS: bit CD (Checking Disabled) và bit AD (Authentic Data) Bit CD được điều khiển bởi các Resolver, trong khi bit AD do các máy chủ tên miền quản lý Một Security-Aware Name Server cần sao chép bit CD từ truy vấn sang phản hồi tương ứng, nhưng phải bỏ qua việc thiết lập bit AD trong các truy vấn Để hiểu rõ hơn về hành vi của các bit này, hãy tham khảo các mục 5.1.6, 5.2.2, 5.2.3, 6 và 6.9.
Máy chủ tên bảo mật (Security-Aware Name Server) đồng bộ các bản ghi CNAME từ các bản ghi DNAME theo quy định trong RFC 2672, và không nên tạo chữ ký cho các bản ghi CNAME được đồng bộ này.
Các máy chủ tên miền có thẩm quyền
Các bản ghi RRSIG trong một trả lời
Khi máy chủ tên miền có thẩm quyền nhận truy vấn với bit DO được thiết lập, nó nên cố gắng gửi các bản ghi RRSIG để Security-Aware Resolver có thể xác thực các bản ghi trong phản hồi Máy chủ tên miền cần duy trì tập bản ghi và các RRSIG liên quan trong một phản hồi, tuân theo các nguyên tắc bảo mật cần thiết.
Khi máy chủ tên miền trả lời với một tập bản ghi được ký, nó cần bao gồm các bản ghi RRSIG trong phần trả lời Các bản ghi RRSIG này có mức ưu tiên cao hơn bất kỳ bản ghi nào khác Nếu không gian không đủ để chứa các bản ghi RRSIG, máy chủ phải thiết lập bit TC.
Khi thiết lập một tập bản ghi ký trong phần thẩm quyền, máy chủ tên miền cần phải bao gồm các bản ghi RRSIG tương ứng Những bản ghi RRSIG này có mức ưu tiên cao hơn bất kỳ bản ghi nào khác trong cùng phần thẩm quyền Nếu không gian không đủ để chứa các bản ghi RRSIG, máy chủ tên miền cần thiết lập bit TC.
Khi một tập bản ghi được ký trong phần bổ sung, máy chủ tên miền cần phải bao gồm các bản ghi RRSIG tương ứng Nếu không gian không đủ để chứa cả tập bản ghi và các bản ghi RRSIG, máy chủ có thể giữ lại tập bản ghi nhưng loại bỏ các bản ghi RRSIG Trong trường hợp này, máy chủ tên miền không được thiết lập bit TC do sự không phù hợp của các bản ghi RRSIG.
Các bản ghi DNSKEY trong một trả lời
Khi xử lý truy vấn có bit DO được thiết lập và yêu cầu các bản ghi SOA hoặc NS ở zone apex được ký, máy chủ tên miền có thẩm quyền có thể trả về tập bản ghi DNSKEY trong phần bổ sung Trong trường hợp này, tập bản ghi DNSKEY và các bản ghi RRSIG liên kết sẽ có mức ưu tiên thấp hơn so với thông tin khác trong phần bổ sung Máy chủ tên miền chỉ nên bao gồm tập bản ghi DNSKEY nếu có đủ không gian trong bản tin để chứa cả DNSKEY và các bản ghi RRSIG liên quan Nếu không đủ không gian, máy chủ phải loại bỏ chúng mà không thiết lập bit TC, do các bản ghi này không phù hợp.
Các bản ghi NSEC trong một trả lời
Khi xử lý một truy vấn có bit DO được kích hoạt, máy chủ tên miền có thẩm quyền cần phải đảm bảo rằng các bản ghi NSEC được bao gồm trong trường hợp liên quan đến bảo mật của zone đó.
Zone không có dữ liệu khi chứa các tập bản ghi hoàn toàn phù hợp với , nhưng lại không có bất kỳ tập bản ghi nào phù hợp hoàn toàn với .
Lỗi tên: Zone không chứa bất kỳ tập bản ghi phù hợp một cách hoàn toàn hoặc thông qua phần mở rộng tên ký tự đại diện
Zone không chứa bất kỳ bản ghi nào phù hợp hoàn toàn với , nhưng lại có một bản ghi phù hợp với thông qua việc mở rộng tê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 phù hợp hoàn toàn