TCVN 11818:2017

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ậtnhậ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ậtnhậ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ậtnhậ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:
AD

Dữ liệu chứng thực

Authentic Data

AXFR

Đồng bộ toàn phần

Full Zone Transfer/ Authoritative Transfer

CD

Kiểm tra vô hiệu hóa

Checking Disabled

CNAME

Tên miền chính tắc

Canonical Name

DNAME

Tên miền chuyển giao

Delegation Name

DNS

Hệ thống tên miền

Domain Name System

DNSKEY Khóa công khai DNS

DNS Public KEY

DNSSEC Phần mở rộng bảo mật DNS

DNS Security Extensions

DO

DNSSEC OK

DS

Ký chuyển giao

Delegation Signer

EDNS

Các cơ chế mở rộng cho DNS

Extension Mechanisms for DNS

IANA

Tổ chức cấp phát số hiệu Internet Internet Assigned Numbers Authority

IXFR

Đồng bộ một phần

Incremental Zone Transfer

NS

Máy chủ tên miền

Name Server


NSEC

Bảo mật kế tiếp

Next Secure

OPT

Tùy chọn

Option

QCLASS Lớp của truy vấn

Query CLASS

QNAME Tên miền đích

Qualified NAME (a target domain name)

QTYPE

Loại của truy vấn

Query TYPE.

RCODE

Mã trả lời

Response CODE

RDATA

Dữ liệu thay thế

Repair DATA

RR

Bản ghi tài nguyên

Resource Record

RRSIG

Chữ ký bản ghi tài nguyên

Resource Record Signature

SCLASS QCLASS của truy vấn tìm kiếm

the QCLASS of the search request

SNAME

Tên miền cần tìm kiếm

the domain name we are searching for

SOA

(Bản ghi tài nguyên) xuất phát (của
Start of (a zone of) Authority
một zone) có thẩm quyền

STYPE

QTYPE của truy vấn tìm kiếm

the QTYPE of the search request

TC

Bị cắt

Truncated

TTL

Thời gian tồn tại

Time to Live

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 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 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 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 SecurityAware 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ò SecurityAware 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 SecurityAware 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 SecurityOblivious 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 securityoblivious 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 securityoblivious 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ợ.

FILE ĐƯỢC ĐÍNH KÈM THEO VĂN BẢN


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