20040409183619 38519 example.
oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
;; Additional
ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6
B.5. Referral to Unsigned Zone
Referral to an unsigned zone. The NSEC RR proves that no DS RR for
this delegation exists in the parent zone.
;; Header: QR DO RCODE=0
;;
;; Question
mc.b.example. IN MX
;; Answer
;; (empty)
;; Authority
b.example. 3600 IN NS ns1.b.example.
b.example. 3600 IN NS ns2.b.example.
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
;; Additional
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
B.6. Wildcard Expansion
A successful query that was answered via wildcard expansion. The
label count in the answer’s RRSIG RR indicates that a wildcard RRset
was expanded to produce this response, and the NSEC RR proves that no
closer match exists in the zone.
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN MX
;; Answer
a.z.w.example. 3600 IN MX 1 ai.example.
a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
20040409183619 38519 example.
OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
4kX18MMR34i8lC36SR5xBni8vHI= )
;; Authority
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
example. 3600 RRSIG NS 5 1 3600 20040509183619 (
20040409183619 38519 example.
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
0HjMeRaZB/FRPGfJPajngcq6Kwg= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example.
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
;; Additional
ai.example. 3600 IN A 192.0.2.9
ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20040409183619 38519 example.
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example.
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
sZM6QjBBLmukH30+w1z3h8PUP2o= )
B.7. Wildcard No Data Error
A "no data" response for a name covered by a wildcard. The NSEC RRs
prove that the matching wildcard name does not have any RRs of the
requested type and that no closer match exists in the zone.
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN AAAA
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20040409183619 38519 example.
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
*.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20040409183619 38519 example.
r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
s1InQ2UoIv6tJEaaKkP701j8OLA= )
;; Additional
;; (empty)
B.8. DS Child Zone No Data Error
A "no data" response for a QTYPE=DS query that was mistakenly sent to
a name server for the child zone.
;; Header: QR AA DO RCODE=0
;;
;; Question
example. IN DS
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1081539377
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20040409183619 38519 example.
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
jV7j86HyQgM5e7+miRAz8V01b0I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20040409183619 38519 example.
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; Additional
;; (empty)
Appendix C. Authentication Examples
The examples in this section show how the response messages in
Appendix B are authenticated.
C.1. Authenticating an Answer
The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
The corresponding RRSIG indicates that the MX RRset was signed by an
"example" DNSKEY with algorithm 5 and key tag 38519. The resolver
needs the corresponding DNSKEY RR in order to authenticate this
answer. The discussion below describes how a resolver might obtain
this DNSKEY RR.
The RRSIG indicates the original TTL of the MX RRset was 3600, and,
for the purpose of authentication, the current TTL is replaced by
3600. The RRSIG labels field value of 3 indicates that the answer
was not the result of wildcard expansion. The "x.w.example.com" MX
RRset is placed in canonical form, and, assuming the current time
falls between the signature inception and expiration dates, the
signature is authenticated.
C.1.1. Authenticating the Example DNSKEY RR
This example shows the logical authentication process that starts
from the a configured root DNSKEY (or DS RR) and moves down the tree
to authenticate the desired "example" DNSKEY RR. Note that the
logical order is presented for clarity. An implementation may choose
to construct the authentication as referrals are received or to
construct the authentication chain only after all RRsets have been
obtained, or in any other combination it sees fit. The example here
demonstrates only the logical process and does not dictate any
implementation rules.
We assume the resolver starts with a configured DNSKEY RR for the
root zone (or a configured DS RR for the root zone). The resolver
checks whether this configured DNSKEY RR is present in the root
DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
RRset, and whether the signature lifetime is valid. If all these
conditions are met, all keys in the DNSKEY RRset are considered
authenticated. The resolver then uses one (or more) of the root
DNSKEY RRs to authenticate the "example" DS RRset. Note that the
resolver may have to query the root zone to obtain the root DNSKEY
RRset or "example" DS RRset.
Once the DS RRset has been authenticated using the root DNSKEY, the
resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
RR that matches one of the authenticated "example" DS RRs. If such a
matching "example" DNSKEY is found, the resolver checks whether this
DNSKEY RR has signed the "example" DNSKEY RRset and the signature
lifetime is valid. If these conditions are met, all keys in the
"example" DNSKEY RRset are considered authenticated.
Finally, the resolver checks that some DNSKEY RR in the "example"
DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
DNSKEY is used to authenticate the RRSIG included in the response.
If multiple "example" DNSKEY RRs match this algorithm and key tag,
then each DNSKEY RR is tried, and the answer is authenticated if any
of the matching DNSKEY RRs validate the signature as described above.
C.2. Name Error
The query in Appendix B.2 returned NSEC RRs that prove that the
requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
authenticated in a manner identical to that of the MX RRset discussed
above.
C.3. No Data Error
The query in Appendix B.3 returned an NSEC RR that proves that the
requested name exists, but the requested RR type does not exist. The
negative reply is authenticated by verifying the NSEC RR. The NSEC
RR is authenticated in a manner identical to that of the MX RRset
discussed above.
C.4. Referral to Signed Zone
The query in Appendix B.4 returned a referral to the signed
"a.example." zone. The DS RR is authenticated in a manner identical
to that of the MX RRset discussed above. This DS RR is used to
authenticate the "a.example" DNSKEY RRset.
Once the "a.example" DS RRset has been authenticated using the
"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
for some "a.example" DNSKEY RR that matches the DS RR. If such a
matching "a.example" DNSKEY is found, the resolver checks whether
this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
the signature lifetime is valid. If all these conditions are met,
all keys in the "a.example" DNSKEY RRset are considered
authenticated.
C.5. Referral to Unsigned Zone
The query in Appendix B.5 returned a referral to an unsigned
"b.example." zone. The NSEC proves that no authentication leads from
"example" to "b.example", and the NSEC RR is authenticated in a
manner identical to that of the MX RRset discussed above.
C.6. Wildcard Expansion
The query in Appendix B.6 returned an answer that was produced as a
result of wildcard expansion. The answer section contains a wildcard
RRset expanded as it would be in a traditional DNS response, and the
corresponding RRSIG indicates that the expanded wildcard MX RRset was
signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
The RRSIG indicates that the original TTL of the MX RRset was 3600,
and, for the purpose of authentication, the current TTL is replaced
by 3600. The RRSIG labels field value of 2 indicates that the answer
is the result of wildcard expansion, as the "a.z.w.example" name
contains 4 labels. The name "a.z.w.w.example" is replaced by
"*.w.example", the MX RRset is placed in canonical form, and,
assuming that the current time falls between the signature inception
and expiration dates, the signature is authenticated.
The NSEC proves that no closer match (exact or closer wildcard) could
have been used to answer this query, and the NSEC RR must also be
authenticated before the answer is considered valid.
C.7. Wildcard No Data Error
The query in Appendix B.7 returned NSEC RRs that prove that the
requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs.
C.8. DS Child Zone No Data Error
The query in Appendix B.8 returned NSEC RRs that shows the requested
was answered by a child server ("example" server). The NSEC RR
indicates the presence of an SOA RR, showing that the answer is from
the child . Queries for the "example" DS RRset should be sent to the
parent servers ("root" servers).
Authors’ Addresses
Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC Enschede
NL
EMail: roy.arends@telin.nl
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873
EMail: massey@cs.colostate.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.