Tiêu chuẩn quốc gia TCVN 12044:2017 về Các yêu cầu bảo mật DNS (DNSSEC)

• Số hiệu: TCVN12044:2017
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2017

AD	Authenticated Data	Dữ liệu được xác thực
AES	Advanced Encryption Standard	Tiêu chuẩn mã hóa tiên tiế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 chuyển giao
DNS	Domain Name System	Hệ thống tên miền
DNSSEC	Security Extensions DNS	Phần mở rộng bảo mật hệ thống tên miền
DNSKEY	DNS Public Key	Bản ghi khóa công khai DNS
DO	DNSSEC OK	Hỗ trợ DNSSEC
DoS	Denial of Service Attack	Tấn công từ chối dịch vụ
DS	Delegation Signer	Bản ghi ký chuyển giao
EDNS	Extension Mechanisms for DNS	Cơ chế mở rộng cho DNS
IANA	Internet Assigned Numbers Authority	Tổ chức cấp phát số hiệu Internet
NAT	Network-address translation	Biên dịch địa chỉ mạng
NSEC	Next Secure	Bản ghi bảo mật kế tiếp
NSEC3	Next Secure 3	Bản ghi bảo mật kế tiếp 3
NSEC3PARAM		Bản ghi NSEC3PARAM
RR	Resource Record	Bản ghi tài nguyên
RRset	Resource Record set	Tập bản ghi tài nguyên
UDP	User Datagram Protocol	Giao thức gói dữ liệu người dùng
TTL	Time To Live	Thời gian hợp lệ
TCP	Transmission Control Protocol	Giao thức điều khiển truyền tải
TSIG	Transaction SIGnature	Chữ ký giao dịch

4  Dịch vụ cung cấp bởi bảo mật DNS

Phần mở rộng bảo mật DNS cung cấp cơ chế xác thực nguồn gốc và đảm bảo toàn vẹn dữ liệu cho dữ liệu DNS, bao gồm các cơ chế để xác thực việc từ chối tồn tại của dữ liệu DNS, Các cơ chế này được mô tả như sau:

- Các cơ chế yêu cầu thay đổi giao thức DNS: DNSSEC thêm bốn loại bản ghi tài nguyên mới là RRSIG, DNSKEY, DS và NSEC và hai bit tiêu đề thông báo mới CD và AD. DNSSEC yêu cầu hỗ trợ EDNS0 (xem [RFC 3225]) để đáp ứng việc tăng kích thước thông báo DNS do thêm các bản ghi DNSSEC. Cuối cùng, DNSSEC cũng yêu cầu hỗ trợ bit tiêu đề EDNS DNSSEC OK (DO) (xem [RFC 3225]), vì vậy, trong truy vấn của Security-Aware Resolver cho biết rằng Security-Aware Resolver này mong muốn nhận được các bản ghi DNSSEC trong thông báo Answer.

- Các chỉ dẫn bảo vệ hệ thống DNS chống lại các mối đe dọa được mô tả trong [RFC 3833], Xem mục 13 mô tả những hạn chế của các phần mở rộng.

4.1  Xác thực nguồn gốc dữ liệu và toàn vẹn dữ liệu

DNSSEC cung cấp xác thực bằng cách kết hợp chữ ký số được mã hóa với các tập bản ghi DNS. Những chữ ký số được lưu trữ trong một bản ghi tài nguyên mới, bản ghi RRSIG. Việc ký dữ liệu của zone do một khóa riêng duy nhất thực hiện, tuy nhiên, việc ký dữ liệu này cũng có thể do nhiều khóa thực hiện. Ví dụ, có thể dùng nhiều khóa đối với mỗi chuỗi các thuật toán ký số khác nhau. Nếu một Security-Aware Resolver chắc chắn biết được một khóa công khai của zone, nó có thể xác thực dữ liệu của zone đã được ký. Trong DNSSEC, khóa ký dữ liệu zone sẽ được liên kết với zone của chính nó và máy chủ thẩm quyền của zone đó (các khóa công khai của cơ chế xác thực tiến trình DNS có thể xuất hiện trong zone, như mô tả trong [RFC 2931], nhưng DNSSEC chỉ liên quan đến bảo mật các đối tượng trong dữ liệu DNS, không liên quan đến bảo mật tiến trình DNS. Các khóa được liên kết với bảo mật tiến trình có thể được lưu trữ trong các loại bản tin tài nguyên khác như mô tả trong [RFC 3755].

Một Security-Aware Resolver có thể nhận biết được khóa công khai của zone thông qua Neo tin cậy được cấu hình trong Resolver hoặc bằng quá trình phân giải DNS thông thường. Cho phép sau này, các khóa công khai được lưu trữ trong một loại bản ghi tài nguyên mới, bản ghi DNSKEY. Lưu ý, các khóa riêng sử dụng ký dữ liệu zone phải được giữ an toàn và được lưu trữ ngoại tuyến khi thực hiện.

Để phát hiện một khóa công khai tin cậy thông qua bộ phân giải DNS, khóa công khai của nó phải được ký bởi một khóa xác thực đã cấu hình từ trước. Security-Aware Resolver xác thực thông tin zone bằng cách tạo ra một chuỗi xác thực từ một khóa công khai mới được nhận biết theo chiều ngược lại một khóa công khai xác thực được biết đến từ trước, nghĩa là một trong hai khóa đã được cấu hình trong Resolver hoặc phải được nhận biết và xác thực trước đó. Do đó, Resolver phải được cấu hình với ít nhất một Neo tin cậy.

Nếu Neo tin cậy được cấu hình là một ZSK, nó sẽ xác thực zone được liên kết; nếu khóa được cấu hình là một KSK, nó sẽ xác thực một ZSK. Nếu Neo tin cậy được cấu hình là mã Hash của một khóa hay đúng hơn khóa của chính nó, Resolver có thể nhận được khóa thông qua truy vấn DNS. Để trợ giúp các bộ Security-Aware Resolver cấu hình chuỗi xác thực này, các Recurity-Aware Name Server gửi (các) chữ ký xác thực một khóa công khai của (các) zone trong thông báo hồi đáp DNS cùng với khóa công khai của nó và cung cấp không gian sẵn có trong thông điệp.

...

...

...

Một Security-Aware Resolver tạo chuỗi xác thực này từ root của hệ thống phân cấp DNS đến zone dựa trên nhận biết được cấu hình trong khóa công khai từ root này. Chính sách nội bộ cho phép Security- Aware Resolver sử dụng một hoặc nhiều khóa công khai được cấu hình (hoặc mã Hash của các khóa công khai) hơn là một khóa công khai của root, chính sách này có thể không cung cấp một nhận biết được cấu hình về khóa công khai của root, hoặc có thể ngăn chặn Resolver sử dụng khóa công khai một cách tùy ý, ngay cả khi các khóa công khai được ký đúng cách với chữ ký xác minh. DNSSEC cung cấp cơ chế để Security-Aware Resolver có thể xác định một chữ ký của tập bản ghi “hợp lệ". Trong phân tích cuối cùng, chính sách nội bộ xác thực các khóa DNS và dữ liệu, khi đó có thể mở rộng hoặc ghi đè các phần mở rộng giao thức được quy định trong tiêu chuẩn này. Xem tại mục 6.

4.2  Tên xác thực và loại không tồn tại xác thực

Cơ chế bảo mật được mô tả trong mục 4.1 chỉ cung cấp phương pháp cho việc ký các tập bản ghi đã có sẵn trong một zone, việc cung cấp các hồi đáp từ chối với mức xác thực và mức toàn vẹn sử dụng của một loại bản ghi tài nguyên mới, bản ghi NSEC. NSEC cho phép Security-Aware Resolver xác thực một hồi đáp từ chối cho tên xác thực hoặc loại không tồn tại xác thực. Với các hồi đáp DNS khác, Security-Aware Resolver sử dụng các cơ chế tương tự. Việc sử dụng NSEC yêu cầu một đại diện chuẩn và sắp xếp thứ tự các tên miền trong các zone. Các chuỗi của NSEC mô tả rõ các khoảng trống hoặc “không gian trống” giữa các tên miền trong một zone và danh sách các loại tập bản ghi hiện diện tại các tên miền hiện có. Mỗi NSEC được ký và được xác thực bằng cách sử dụng các cơ chế được mô tả trong mục 4.1.

5  Dịch vụ không cung cấp bởi bảo mật DNS

DNS ban đầu được thiết kế với giả định rằng DNS sẽ trả lại cho cùng câu trả lời cho các truy vấn bất kỳ mà không quan tâm đến người thực hiện truy vấn đó, và tất cả dữ liệu trong DNS đều có thể truy vấn được. Theo đó, DNSSEC không được thiết kế để cung cấp tính năng bảo mật, danh sách kiểm soát truy nhập, hoặc phương pháp phân biệt giữa các đối tượng thực hiện truy vấn.

DNSSEC không cung cấp cơ chế bảo vệ chống lại các tấn công từ chối dịch vụ. Các Security-Aware Resolver và các máy chủ tên miền Security-Aware dễ bị tấn công từ một loại bổ sung của tấn công từ chối dịch vụ dựa trên các hoạt động mã hóa (mô tả trong mục 13).

Phần mở rộng bảo mật DNS cung cấp dữ liệu và xác thực gốc cho dữ liệu DNS. Các cơ chế nêu trên không được thiết kế cho các hoạt động bảo vệ cũng như chuyển zone và cập nhật động ([RFC 2136], [RFC 3007]). Việc xác thực thông báo được mô tả trong [RFC 2845] và [RFC 2931] hoạt động bảo mật địa chỉ liên quan đến nghiệp vụ này.

6  Phạm vi của DNSSEC

Các chỉ tiêu kỹ thuật trong tiêu chuẩn này định nghĩa phương thức xử lý cho các chữ ký zone và các máy chủ tên miền Security-Aware và các Resolver theo phương pháp các đối tượng xác minh có thể xác định rõ trạng thái của dữ liệu.

...

...

...

- An toàn: Validating Resolver có một Neo tin cậy, có một chuỗi điểm tin cậy, và có thể xác minh tất cả các chữ ký trong các hồi đáp.

- Không an toàn: Validating Resolver có một Neo tin cậy, có một chuỗi điểm tin cậy, và tại một điểm ủy quyền, được ký chứng minh không tồn tại của một bản ghi DS. Điều này chỉ ra các nhánh tiếp theo của cây là không an toàn. Một validating Resolver có thể có chính sách nội bộ để đánh dấu các phần của không gian miền là không an toàn.

- Không có thật: Validating Resolver có một Neo tin cậy và ủy quyền an toàn chỉ ra dữ liệu phụ trợ đã được ký nhưng hồi đáp không thể xác minh đối với một số lý do: thiếu chữ ký, ký quá hạn, ký với các thuật toán không được hỗ trợ, mất dữ liệu các bản ghi NSEC liên quan hiện diện,...

- Không xác định: Không có Neo tin cậy chỉ ra một phần cụ thể của cây là an toàn. Đây là chế độ hoạt động mặc định.

Đặc tính kỹ thuật này chỉ quy định các Recurity-Aware Name Server có thể ký với các Non-Validating Stub Resolver rằng dữ liệu được tìm thấy không có thật (sử dụng RCODE=2, "Server Failure"; mô tả trong [RFC4035]).

Đây là cơ chế cho các máy chủ tên miền Recurity-Aware ký với các Security-Aware Stub Resolver thông báo dữ liệu được tìm thấy là an toàn (sử dụng bit AD, được mô tả trong [RFC 4035]).

Đặc tính này không định nghĩa định dạng cho thông tin trả lời vì sao hồi đáp được tìm thấy là không có thật hoặc được đánh dấu không an toàn. Cơ chế ký hiện hành không phân biệt giữa zone xác định và zone không an toàn.

Một phương pháp sử dụng cho việc truyền tín hiệu mã lỗi tiên tiến và các chính sách giữa một Security-Aware Stub Resolver và các máy chủ tên miền đệ quy Security-Aware là vấn đề được nghiên cứu trong tương lai, như giao diện giữa một Security-Aware Resolver và các ứng dụng mà nó sử dụng. Lưu ý, việc không đáp ứng đầy đủ các đặc tính của thông tin không ngăn cấm trong việc triển khai các zone đã được ký hoặc việc triển khai các Security Aware Recursive Name Server nhưng ngăn cấm việc lan truyền dữ liệu không có thật cho các ứng dụng.

7  Các yêu cầu đối với Resolver

...

...

...

Trong trường hợp, Security-Aware Resolver được tách ra từ các máy chủ có thẩm quyền liên quan bởi các máy chủ tên miền đệ quy hoặc bất kỳ thiết bị trung gian hoạt động như một proxy của DNS. Nếu Recursive Name Server hoặc thiết bị trung gian này không có chức năng Security-Aware thì Security- Aware Resolver có thể không có khả năng hoạt động trong một chế độ an toàn. Ví dụ, nếu các gói tin của Security-Aware Resolver được chuyển qua một thiết bị địa chỉ mạng (NAT) bao gồm một proxy không có chức năng Security-Aware, Security-Aware Resolver có thể gặp khó khăn trong việc tìm kiếm cũng như không có khả năng nhận hoặc xác thực dữ liệu DNS được ký. Security-Aware Resolver có thể phải mất thời gian để nhận được các bản ghi DS trong trường hợp như vậy, bản ghi DS không thực hiện theo các quy tắc DNS thông thường đối với quyền sở hữu của bản ghi tại các zone cut. Chú ý rằng, vấn đề này không đặc trưng cho NAT: bất kỳ phần mềm Security-Obliviou DNS của bất kỳ loại nào giữa Security-Aware Resolver và các máy chủ có thẩm quyền sẽ giao tiếp với DNSSEC.

Nếu một Security-Aware Resolver phải tin cậy vào một zone không được ký hoặc một máy chủ tên miền không có Security-Aware, Resolver có thể không có khả năng xác thực hồi đáp DNS, khi đó cần một chính sách nội bộ về việc có nên chấp nhận hồi đáp chưa được xác thực hay không.

Một Security-Aware Resolver đòi hỏi một khoảng thời gian cho việc xác minh chữ ký khi xác định TTL của dữ liệu trong bộ nhớ đệm của nó, tránh việc dữ liệu trong bộ nhớ đệm được ký sau thời gian xác minh chữ ký. Tuy nhiên, nó cũng cho phép khả năng đồng hồ của Security-Aware Resolver bị sai. Vì vậy, một Security-Aware Resolver là một phần của một máy chủ tên miền đệ quy Security-Aware phải chú ý đến bit CD “kiểm tra vô hiệu hóa” trong DNSSEC ([RFC 3034]). Điều này tránh tình trạng chữ ký hợp lệ bị chặn bởi các Security-Aware Resolvers khác là các máy khách của máy chủ tên miền đệ quy này. Việc một Secure Recursive Server xử lý truy vấn với cấu hình bit CD được mô tả trong [RFC 4035].

8  Các yêu cầu đối với Stub Resolver

Giao thức không đưa ra các yêu cầu, tuy nhiên, hầu hết các truy vấn DNS có nguồn gốc từ các Stub Resolver. Các Stub Resolver là các DNS Resolver tối giản và sử dụng chế độ truy vấn đệ quy để giảm tải cho các công việc của bộ phân tích DNS đến một máy chủ tên miền đệ quy. Cấu trúc của DNSSEC ghi chép các Stub Resolver vào một bảng kê để đáp ứng việc sử dụng rộng rãi các Stub Resolver này, nhưng các đặc tính bảo mật cần thiết trong một Stub Resolver và các đặc tính bảo mật trong một Security-Aware Iterative Resolver hoàn toàn khác nhau.

Thậm chí, một Security-Oblivious Stub Resolver có lợi từ DNSSEC nếu các máy chủ tên miền đệ quy được sử dụng là Security-Aware, nhưng nếu Stub Resolver tin tưởng vào các chỉ dẫn DNSSEC, Stub Resolver phải tin cậy vào cả máy chủ tên miền đệ quy trong câu hỏi và các kênh thông tin giữa nó và các máy chủ tên đó. Vấn đề đầu tiên là chính sách nội bộ: về bản chất, một Security-Oblivious Stub Resolver không thực hiện việc kiểm tra hiệu lực DNSSSEC mà tin tưởng vào máy chủ tên miền đệ quy nó sử dụng, vấn đề thứ hai quy định một số loại cơ chế bảo mật kênh; việc sử dụng hợp lý các cơ chế xác thực giao dịch DNS như SIG(0) ([RFC 2931]) hoặc TSIG ([RFC 2845]), hay sử dụng thích hợp của IPsec. Các bổ sung chi tiết có thể có những lựa chọn có sẵn, chẳng hạn như các cơ chế truyền tin liên quá trình đặc tính hệ thống điều hành. Các kênh này không cần bảo mật, nhưng tính toàn vẹn dữ liệu và xác thực thông báo cần được bảo mật. Một Security-Aware Stub Resolver tin tưởng vào máy chủ tên miền đệ quy và kênh thông tin để có thể lựa chọn và kiểm tra việc cấu hình bit AD trong tiêu đề thông báo của thông báo hồi đáp nó nhận được, Stub Resolver có thể sử dụng bit flag này để tìm máy chủ tên miền đệ quy đã có chữ ký xác minh đối với tất cả dữ liệu trong phần quyền hạn và trả lời của các hồi đáp.

Nếu vì bất kỳ lý do gì, Security-Aware Stub Resolver không có khả năng cấu hình một mối quan hệ độ tin cậy cần thiết với các máy chủ tên miền đệ quy mà nó sử dụng: nó có thể thực hiện xác minh chữ ký của mình bằng cách cấu hình bit CD trong các thông báo truy vấn. A validating Stub Resolver coi các chữ ký DNSSEC như các quan hệ tin cậy giữa các quản trị zone và Stub Resolver của nó.

9  Các yêu cầu đối với zone

Sự khác biệt giữa zone được ký và zone không được ký. Một zone đã được ký bao gồm các bản ghi bảo mật bổ sung (RRSIG, DNSKEY, DS và các NSEC). Các bản ghi RRSIG và NSEC có thể được tạo ra trong quá trình ký trước khi được sử dụng. Các bản ghi RRSIG kèm theo dữ liệu zone đã được xác định khởi đầu và cấu hình thời hạn có hiệu lực cho các chữ ký và dữ liệu zone.

...

...

...

Sự khác biệt giữa giá trị TTL của tập bản ghi và thời gian hiệu lực được ký quy định bởi sự bao phủ bản ghi RRSIG là tập bản ghi. DNSSEC không thay đổi định nghĩa hoặc chức năng của giá trị TTL, với mục đích duy trì sự liên kết cơ sở dữ liệu trong các bộ đệm. Một Resolver loại trừ các tập bản ghi từ bộ nhớ đệm của nó trước điểm kết thúc của hiệu lực thời gian được quy định bởi các trường TTL của các tập bản ghi, kể cả khi Resolver này là Security-Aware.

Các trường bắt đầu và kết thúc trong bản ghi RRSIG ([RFC 4034]) chỉ định chu kỳ thời gian chữ ký có thể được sử dụng để xác định tập bản ghi. Các chữ ký được liên kết với dữ liệu zone được ký chỉ có hiệu lực trong chu kỳ thời gian được quy định bởi các trường trong bản ghi RRSIG trong câu hỏi. Các giá trị TTL không thể kéo dài thời gian hiệu lực của tập bản ghi được ký trong bộ đệm của Resolver, nhưng Resolver có thể sử dụng thời gian còn lại trước khi kết thúc thời hạn hiệu lực chữ ký của một tập bản ghi được ký, việc kết thúc là bắt buộc đối với TTL của tập bản ghi đã được ký và được liên kết với bản ghi RRSIG trong bộ đệm của Resolver.

9.2  Các yêu cầu mới về phụ thuộc thời gian trong các zone

Thông tin trong một zone được ký tạm thời nhưng không tồn tại trong giao thức DNS gốc. Việc bảo trì zone được ký phải thường xuyên để đảm bảo mỗi tập bản ghi trong zone có một giá trị hiện hành bản ghi RRSIG. Thời gian hiệu lực chữ ký của một bản ghi RRSIG là khoảng thời gian có hiệu lực diễn ra việc ký nhận đối với mỗi tập bản ghi, và việc ký của các tập bản ghi khác nhau trong một zone có thể hết hiệu lực tại các thời điểm khác nhau. Việc ký lại một hoặc nhiều tập bản ghi sẽ thay đổi một hoặc nhiều bản ghi RRSIG, việc này làm tăng số dãy SOA của zone và cho biết đã xảy ra sự thay đổi zone và ký lại tập bản ghi SOA của chính nó. Do đó, việc ký lại bất kỳ tập bản ghi trong một zone có thể gây ra thông báo DNS NOTIFY và các hoạt động chuyển giao zone.

10  Các yêu cầu đối với máy chủ tên miền

Một máy chủ tên miền Recurity-Aware bao gồm các bản ghi DNSSEC thích hợp (RRSIG, DNSKEY, DS, và NSEC) trong tất cả các hồi đáp cho các truy vấn từ các Resolver và báo hiệu việc sẵn sàng nhận các bản ghi thông qua sử dụng bit DO trong tiêu đề EDNS, tùy thuộc vào giới hạn kích thức thông báo. Bởi vì, tập hợp của các bản ghi DNSSEC này có thể dễ dàng gây ra sự cắt xén thông báo UDP và dự phòng tới TCP, một máy chủ tên miền Recurity-Aware phải hỗ trợ cơ chế “tải UDP của người gửi” EDNS.

Nếu có thể, một nửa của mỗi khóa DNSSEC nên được giữ ngoại tuyến, nhưng không áp dụng cho zone cập nhật động DNS đã được kích hoạt. Trong trường hợp cập nhật động, Primary Master Server của zone ký lại zone khi được cập nhật, vì vậy khóa chính tương ứng với ZSK phải được giữ trực tuyến.

DNSSEC không thể đảm bảo tính toàn vẹn của toàn bộ zone trong suốt các hoạt động chuyển zone, vì vậy một zone được ký vẫn có thể chứa phần chưa được ký, dữ liệu chưa xác thực nếu zone đó không có zone con. Do đó, hoạt động bảo trì zone đòi hỏi một số cơ chế bổ sung (như hình thức bảo mật kênh TSIG, SIG(0) hoặc IPsec).

11  Họ tài liệu bảo mật DNS

...

...

...

“Tập tài liệu giao thức DNSSEC” đề cập đến ba tài liệu là chính của phần mở rộng bảo mật DNS:

1) Các yêu cầu và hướng dẫn bảo mật DNS ([RFC 4033]).

2) Bản ghi tài nguyên cho phần mở rộng bảo mật DNS ([RFC 4034]).

3) Các thay đổi trong giao thức cho phần mở rộng bảo mật DNS ([RFC 4035]).

Ngoài ra, bất kỳ tiêu chuẩn nào được thêm vào hoặc thay đổi tài liệu chính của phần mở rộng bảo mật DNS sẽ nằm trong nhóm này. Điều này bao gồm bất cứ việc làm trong tương lai liên quan đến giao tiếp giữa Security-Aware Stub Resolvers và máy chủ tên miền đệ quy Security-Aware ngược tuyến.

Nhóm các tiêu chuẩn “Chỉ tiêu kỹ thuật thuật toán ký số” mô tả cụ thể các thuật toán ký số cần được thực hiện để phù hợp với các định dạng bản ghi tài nguyên DNSSEC. Mỗi tài liệu này là một thuật toán ký số cụ thể. Phụ lục “Các loại thuật toán và phân loại DNS" mô tả trong [RFC 4034] cung cấp danh sách các thuật toán được định nghĩa khi các chỉ tiêu kỹ thuật chính này được xây dựng. “Giao thức xác thực giao dịch” đề cập đến giải quyết xác thực thông báo DNS bao gồm cấu hình khóa riêng và xác thực.

Tiêu chuẩn cuối cùng “Sử dụng bảo mật mới” đề cập tới các tiêu chuẩn tìm cách sử dụng đề xuất các phần mở rộng bảo mật DNS đối với các bảo mật khác có liên quan. DNSSEC không cung cấp bất kỳ bảo mật trực tiếp nào đối với các bảo mật mới này nhưng có thể được sử dụng để hỗ trợ. Các tài liệu này nằm trong nhóm mô tả việc sử dụng DNS trong lưu trữ và phân phối chứng chỉ [RFC2538].

12  Các yêu cầu của IANA

Các yêu cầu của IANA được đề cập trong [RFC 4034].

...

...

...

Tiêu chuẩn này giới thiệu phần mở rộng bảo mật DNS và mô tả tập tài liệu có chứa các bản ghi bảo mật mới và các thay đổi trong giao thức DNS. Phần mở rộng cung cấp xác thực dữ liệu gốc và toàn vẹn dữ liệu bằng cách sử dụng ký số trên các tập bản ghi tài nguyên.

Mục này đưa ra các hạn chế của phần mở rộng.

Để một Security-Aware Resolver xác minh một hồi đáp DNS, tất cả các zone dọc theo đường dẫn từ điểm bắt đầu được tin cậy tại zone chứa các zone hồi đáp phải được ký, và tất cả máy chủ tên miền và các Resolver liên quan trong quá trình phân tích phải là Security-Aware như mô tả trong tiêu chuẩn này. Một Security-Aware Resolver không thể xác thực nguồn gốc hồi đáp từ một zone không được ký, từ zone không được chỉ dẫn bởi một máy chủ tên miền Recurity-Aware, hoặc từ bất kỳ dữ liệu DNS không được nhận biết thông qua máy chủ tên miền đệ quy Security-Aware. Nếu chuỗi xác thực bị phá vỡ thì Security-Aware Resolver không thể xác minh các khóa xác thực cần thiết, sau đó Security-Aware Resolver này không thể xác minh dữ liệu DNS bị hư hỏng.

Tiêu chuẩn này đưa ra các phương pháp bảo mật bổ sung cho một truy vấn DNS, ví dụ sử dụng một kênh được bảo mật bởi IPsec hoặc sử dụng một cơ chế xác thực giao dịch DNS như TSIG ([RFC 2845]) hoặc SIG(0) ([RFC 2931]), nhưng bảo mật giao dịch không phải là một phần của DNSSEC.

Một non-validating Security-Aware Stub Resolver không thực hiện việc xác minh chữ ký DNSSEC trên chính nó, do đó, nó dễ bị ảnh hưởng khi bị tấn công vào máy chủ tên miền đệ quy Security-Aware do việc thực hiện kiểm tra trên đại diện của nó và bị tấn công vào giao tiếp của nó với các máy chủ tên miền đệ quy Security-Aware. Các Non-validating Security-Aware Stub Resolver nên sử dụng một số hình thức bảo mật kênh để chống lại các mối đe dọa sau này. Security-Aware Stub Resolver chống lại các mối đe dọa thông qua việc xác minh chữ ký của nó, lúc này nó sẽ không còn là Non-Validating Security-Aware Stub Resolver.

DNSSEC không bảo vệ chống lại tấn công từ chối dịch vụ (DoS). DNSSEC làm cho DNS dễ bị ảnh hưởng đến một loại mới của DoS dựa trên hoạt động mã hóa chống lại các Security-Aware Resolver và các máy chủ tên miền Recurity-Aware, ví dụ, kẻ tấn công có thể cố gắng sử dụng các cơ chế DNSSEC để tiêu hao tài nguyên của đối tượng bị tấn công. Loại tấn công này tồn tại ít nhất hai hình thức. Kẻ tấn công có thể tiêu hao mã xác minh chữ ký của một Security-Aware Resolver bằng cách giả mạo các thông báo hồi đáp trong các bản ghi RRSIG hoặc bằng cách tạo ra các chuỗi chữ ký phức tạp. Kẻ tấn công có thể tiêu thụ các tài nguyên trong một máy chủ tên miền Recurity-Aware hỗ trợ cập nhật động DNS, bằng cách gửi một dòng thông báo cập nhật, bắt buộc máy chủ tên miền Recurity- Aware ký lại các tập bản ghi trong zone với tần suất bất thường.

Một thiết kế có lựa chọn là DNSSEC không cung cấp bảo mật.

DNSSEC giới thiệu một khả năng cho kẻ tấn công để liệt kê tất cả các tên miền trong zone bởi một chuỗi NSEC sau đây. NSEC xác minh rằng tên miền không tồn tại trong một zone bởi các liên kết từ tên đã tạo sẵn đến tên đã tạo sẵn theo một trật tự chuẩn của tất cả các tên miền trong một zone. Do đó, kẻ tấn công có thể truy vấn các bản ghi NSEC trong dãy để thu được tất cả các tên miền trong zone. Mặc dù, không tấn công vào DNS của chính nó, nó có thể cho phép kẻ tấn công sắp xếp các network host hoặc các tài nguyên khác bằng cách liệt kê các nội dung của một zone.

DNSSEC không bảo vệ chống giả mạo với dữ liệu zone không được ký. Dữ liệu không được xác thực tại các zone cut (các bản ghi NS trong zone con) không được ký. Việc này không xảy ra vấn đề khi xác minh chuỗi xác thực, nhưng nó có nghĩa là dữ liệu "non-authoritative” của nó dễ bị xáo trộn trong suốt các hoạt động chuyển zone. Do đó, trong khi DNSSEC có thể cung cấp xác thực nguồn gốc dữ liệu và toàn vẹn dữ liệu đối với các tập bản ghi, nó không thể làm như vậy đối với các zone, và các cơ chế khác (như TSIG, SIG (0), hoặc IPsec) phải được sử dụng để bảo vệ các hoạt động chuyển giao zone, (xem [RFC 4034] và [RFC 4035] đối với các yêu cầu bảo mật bổ sung).

...

...

...

Phụ lục A

(Quy định)

Các RFC cập nhật

Phụ lục này chỉ trình bày các thông tin được cập nhật cho tiêu chuẩn này.

A.1  RFC 6014 “Cryptographic Algorithm Identifier Allocation for DNSSEC” - RFC 6014 “Định dạng các thuật toán mã hóa dùng cho DNSSEC” (11-2010)

RFC 6014 (11-2010) 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.

Trong Mục “2. Các yêu cầu về ấn định trong việc ký số thuật toán bảo mật DNS” tại Trang 3 của RFC 6014 (11-2010):

Có hai lý do để quy định 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.

...

...

...

Để giải quyết những lo ngại về việc đầy ký số, IETF nên đánh giá lại các yêu cầu đối với ký số khi ký số đượ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 ký số 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áp của hai giá trị này.

A.2  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 bảo mật DNS (DNSSEC)” (02-2013)

Trong Mục “2. Những bổ sung quan trọng DNS” tại Trang 4 của RFC 6840 (02-2013) liệt kê các tài liệu được coi là cốt lõi của các tài liệu giao thức DNS không được chỉ ra tại mục 11 của tiêu chuẩn này.

A.2.1 Hỗ trợ NSEC3

RFC 5155 mô tả việc sử dụng và xử lý các bản ghi NSEC3 và NSEC3 PARAM đối với chứng cứ không tồn tại đã bị làm hỏng. Những bổ sung hợp lý này được khuyến khích trong đó bao gồm hỗ trợ cho NSEC3 bởi vì một số zone có thể xác định được sử dụng nó. Những bổ sung không hỗ trợ xác minh hồi đáp bằng các sử dụng NSEC3 bị ngăn cản trong việc xác thực phần lớn không gian DNS.

[RFC 5155] xem xét phần họ tiêu chuẩn bảo mật DNS được mô tả tại mục 11 của tiêu chuẩn này đối với việc hỗ trợ NSEC3.

A.2.2 Hỗ trợ SHA-2

[RFC 4509] mô tả việc sử dụng SHA-256 bằng thuật toán phân loại trong các bản ghi DS. [RFC 5702] mô tả việc sử dụng thuật toán RSASHA256 và SRASHA512 trong các bản ghi DNSKEY và RRSIG.

...

...

...

[RFC 4509] và [RFC 5702] xem xét phần Họ tiêu chuẩn bảo mật DNS được mô tả tại mục 11 của tiêu chuẩn này đối với việc hỗ trợ SHA-2.

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

[1] [RFC 4033] “DNS Security Introduction and Requirements", (03-2005).

[2] [RFC 6014] “Cryptographic Algorithm Identifier Allocation for DNSSEC”, (10-2010).

[3] [RFC 6840] “Clarifications and Implementation Notes for DNS Security (DNSSEC)”, (02-2013).

MỤC LỤC

1  Phạm vi áp dụng

...

...

...

3  Thuật ngữ, định nghĩa và chữ viết tắt

3.1  Định nghĩa

3.2  Chữ viết tắt

4  Dịch vụ cung cấp bởi bảo mật DNS

4.1 Xác thực nguồn gốc dữ liệu và toàn vẹn dữ liệu

4.2 Tên xác thực và loại không tồn tại xác thực

5  Dịch vụ không cung cấp bởi bảo mật DNS

6  Phạm vi của DNSSEC

7  Các yêu cầu đối với Resolver

...

...

...

9  Các yêu cầu đối với zone

9.1  Các giá trị TTL so với thời gian hiệu lực của RRSIG

9.2  Các yêu cầu mới về phụ thuộc thời gian trong các zone

10  Các yêu cầu đối với máy chủ tên miền

11  Họ tài liệu bảo mật DNS

12  Các yêu cầu của IANA

13  Các yêu cầu đối với bảo mật

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

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

...

...

...