1 Network Working Group R. Arends
2 Request for Comments: 4035 Telematica Instituut
3 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
4 3755, 3757, 3845 ISC
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
RFC6840, "Clarifications and Implementation Notes for DNSSEC", updates RFC 4035 in many places throughout the document.
RFC6014 says that it updates RFC 4035, and talks about RFC 4035 in a few places, but doesn't seem to update any of the material in RFC 4035.
5 Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
6 3007, 3597, 3226 VeriSign
7 Category: Standards Track D. Massey
8 Colorado State University
9 S. Rose
10 NIST
11 March 2005
12
13
14 Protocol Modifications for the DNS Security Extensions
15
16 Status of This Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24 Copyright Notice
25
26 Copyright (C) The Internet Society (2005).
27
28 Abstract
29
30 This document is part of a family of documents that describe the DNS
31 Security Extensions (DNSSEC). The DNS Security Extensions are a
32 collection of new resource records and protocol modifications that
33 add data origin authentication and data integrity to the DNS. This
34 document describes the DNSSEC protocol modifications. This document
35 defines the concept of a signed zone, along with the requirements for
36 serving and resolving by using DNSSEC. These techniques allow a
37 security-aware resolver to authenticate both DNS resource records and
38 authoritative DNS error indications.
39
40 This document obsoletes RFC 2535 and incorporates changes from all
41 updates to RFC 2535.
42
43
44
45
46
47
48
49
50
51
52 Arends, et al. Standards Track [Page 1]
53 RFC 4035 DNSSEC Protocol Modifications March 2005
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Background and Related Documents . . . . . . . . . . . . 4
60 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
61 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
63 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
64 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
65 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
66 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
67 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
68 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
69 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
70 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
71 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
72 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
73 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
74 3.1.4. Including DS RRs in a Response . . . . . . . . . 14
75 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
76 3.1.6. The AD and CD Bits in an Authoritative Response. 16
77 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
78 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
79 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
80 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
81 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
82 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
83 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
84 4.2. Signature Verification Support . . . . . . . . . . . . . 19
85 4.3. Determining Security Status of Data . . . . . . . . . . 20
86 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
87 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
88 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
89 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
90 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
91 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
92 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
93 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
94 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
95 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
96 5.1. Special Considerations for Islands of Security . . . . . 26
97 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
98 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
99 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
100 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
101 5.3.3. Checking the Signature . . . . . . . . . . . . . 31
102 5.3.4. Authenticating a Wildcard Expanded RRset
103 Positive Response. . . . . . . . . . . . . . . . 32
104
105
106
107 Arends, et al. Standards Track [Page 2]
108 RFC 4035 DNSSEC Protocol Modifications March 2005
109
110
111 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
112 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
113 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
116 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
117 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
118 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
119 9.2. Informative References . . . . . . . . . . . . . . . . . 35
120 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
121 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
122 B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
123 B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
124 B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
125 B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
126 B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
127 B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
128 B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
129 B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
130 C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
131 C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
132 C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
133 C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
134 C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
135 C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
136 C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
137 C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
138 C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
139 C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
141 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
142
143 1. Introduction
144
145 The DNS Security Extensions (DNSSEC) are a collection of new resource
146 records and protocol modifications that add data origin
147 authentication and data integrity to the DNS. This document defines
148 the DNSSEC protocol modifications. Section 2 of this document
149 defines the concept of a signed zone and lists the requirements for
150 zone signing. Section 3 describes the modifications to authoritative
151 name server behavior necessary for handling signed zones. Section 4
152 describes the behavior of entities that include security-aware
153 resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
154 to authenticate a response.
155
156
157
158
159
160
161
162 Arends, et al. Standards Track [Page 3]
163 RFC 4035 DNSSEC Protocol Modifications March 2005
164
165
166 1.1. Background and Related Documents
167
168 This document is part of a family of documents defining DNSSEC that
169 should be read together as a set.
170
171 [RFC4033] contains an introduction to DNSSEC and definitions of
172 common terms; the reader is assumed to be familiar with this
173 document. [RFC4033] also contains a list of other documents updated
174 by and obsoleted by this document set.
175
176 [RFC4034] defines the DNSSEC resource records.
177
178 The reader is also assumed to be familiar with the basic DNS concepts
179 described in [RFC1034], [RFC1035], and the subsequent documents that
180 update them; particularly, [RFC2181] and [RFC2308].
181
182 This document defines the DNSSEC protocol operations.
183
184 1.2. Reserved Words
185
186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
188 document are to be interpreted as described in [RFC2119].
189
190 2. Zone Signing
191
192 DNSSEC introduces the concept of signed zones. A signed zone
193 includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
194 Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
195 according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
196 respectively. A zone that does not include these records according
197 to the rules in this section is an unsigned zone.
198
199 DNSSEC requires a change to the definition of the CNAME resource
200 record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG
201 and NSEC RRs to appear at the same owner name as does a CNAME RR.
202
203 DNSSEC specifies the placement of two new RR types, NSEC and DS,
204 which can be placed at the parental side of a zone cut (that is, at a
205 delegation point). This is an exception to the general prohibition
206 against putting data in the parent zone at a zone cut. Section 2.6
207 describes this change.
208
209
210
211
212
213
214
215
216
217 Arends, et al. Standards Track [Page 4]
218 RFC 4035 DNSSEC Protocol Modifications March 2005
219
220
221 2.1. Including DNSKEY RRs in a Zone
222
223 To sign a zone, the zone's administrator generates one or more
224 public/private key pairs and uses the private key(s) to sign
225 authoritative RRsets in the zone. For each private key used to
226 create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
227 containing the corresponding public key. A zone key DNSKEY RR MUST
228 have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
229 of [RFC4034]). Public keys associated with other DNS operations MAY
230 be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
231 be used to verify RRSIGs.
232
233 If the zone administrator intends a signed zone to be usable other
234 than as an island of security, the zone apex MUST contain at least
235 one DNSKEY RR to act as a secure entry point into the zone. This
236 secure entry point could then be used as the target of a secure
237 delegation via a corresponding DS RR in the parent zone (see
238 [RFC4034]).
239
240 2.2. Including RRSIG RRs in a Zone
241
242 For each authoritative RRset in a signed zone, there MUST be at least
243 one RRSIG record that meets the following requirements:
244
245 o The RRSIG owner name is equal to the RRset owner name.
246
247 o The RRSIG class is equal to the RRset class.
248
249 o The RRSIG Type Covered field is equal to the RRset type.
250
251 o The RRSIG Original TTL field is equal to the TTL of the RRset.
252
253 o The RRSIG RR's TTL is equal to the TTL of the RRset.
254
255 o The RRSIG Labels field is equal to the number of labels in the
256 RRset owner name, not counting the null root label and not
257 counting the leftmost label if it is a wildcard.
258
259 o The RRSIG Signer's Name field is equal to the name of the zone
260 containing the RRset.
261
262 o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
263 zone key DNSKEY record at the zone apex.
264
265 The process for constructing the RRSIG RR for a given RRset is
266 described in [RFC4034]. An RRset MAY have multiple RRSIG RRs
267 associated with it. Note that as RRSIG RRs are closely tied to the
268 RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
269
270
271
272 Arends, et al. Standards Track [Page 5]
273 RFC 4035 DNSSEC Protocol Modifications March 2005
274
275
276 RR types, do not form RRsets. In particular, the TTL values among
277 RRSIG RRs with a common owner name do not follow the RRset rules
278 described in [RFC2181].
279
280 An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
281 add no value and would create an infinite loop in the signing
282 process.
283
284 The NS RRset that appears at the zone apex name MUST be signed, but
285 the NS RRsets that appear at delegation points (that is, the NS
286 RRsets in the parent zone that delegate the name to the child zone's
287 name servers) MUST NOT be signed. Glue address RRsets associated
288 with delegations MUST NOT be signed.
289
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
290 There MUST be an RRSIG for each RRset using at least one DNSKEY of
291 each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
292 itself MUST be signed by each algorithm appearing in the DS RRset
293 located at the delegating parent (if any).
294
Section 5.11 of RFC6840 says:
The last paragraph of Section 2.2 of [RFC4035] includes rules describing which algorithms must be used to sign a zone. Since these rules have been confusing, they are restated using different language here: The DS RRset and DNSKEY RRset are used to signal which algorithms are used to sign a zone. The presence of an algorithm in either a zone's DS or DNSKEY RRset signals that that algorithm is used to sign the entire zone. A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset. It is possible to add algorithms at the DNSKEY that aren't in the DS record, but not vice versa. If more than one key of the same algorithm is in the DNSKEY RRset, it is sufficient to sign each RRset with any subset of these DNSKEYs. It is acceptable to sign some RRsets with one subset of keys (or key) and other RRsets with a different subset, so long as at least one DNSKEY of each algorithm is used to sign each RRset. Likewise, if there are DS records for multiple keys of the same algorithm, any subset of those may appear in the DNSKEY RRset. This requirement applies to servers, not validators. Validators SHOULD accept any single valid path. They SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work. A validator MAY have a configuration option to perform a signature completeness test to support troubleshooting.
295 2.3. Including NSEC RRs in a Zone
296
297 Each owner name in the zone that has authoritative data or a
298 delegation point NS RRset MUST have an NSEC resource record. The
299 format of NSEC RRs and the process for constructing the NSEC RR for a
300 given name is described in [RFC4034].
301
Section 3 of RFC4470 says:
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set. This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at names that did not exist before the zone was signed.
302 The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
303 value field in the zone SOA RR.
304
305 An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
306 RRset at any particular owner name. That is, the signing process
307 MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
308 the owner name of any RRset before the zone was signed. The main
309 reasons for this are a desire for namespace consistency between
310 signed and unsigned versions of the same zone and a desire to reduce
311 the risk of response inconsistency in security oblivious recursive
312 name servers.
313
314 The type bitmap of every NSEC resource record in a signed zone MUST
315 indicate the presence of both the NSEC record itself and its
316 corresponding RRSIG record.
317
318 The difference between the set of owner names that require RRSIG
319 records and the set of owner names that require NSEC records is
320 subtle and worth highlighting. RRSIG records are present at the
321 owner names of all authoritative RRsets. NSEC records are present at
322 the owner names of all names for which the signed zone is
323 authoritative and also at the owner names of delegations from the
324
325
326
327 Arends, et al. Standards Track [Page 6]
328 RFC 4035 DNSSEC Protocol Modifications March 2005
329
330
331 signed zone to its children. Neither NSEC nor RRSIG records are
332 present (in the parent zone) at the owner names of glue address
333 RRsets. Note, however, that this distinction is for the most part
334 visible only during the zone signing process, as NSEC RRsets are
335 authoritative data and are therefore signed. Thus, any owner name
336 that has an NSEC RRset will have RRSIG RRs as well in the signed
337 zone.
338
339 The bitmap for the NSEC RR at a delegation point requires special
340 attention. Bits corresponding to the delegation NS RRset and any
341 RRsets for which the parent zone has authoritative data MUST be set;
342 bits corresponding to any non-NS RRset for which the parent is not
343 authoritative MUST be clear.
344
345 2.4. Including DS RRs in a Zone
346
347 The DS resource record establishes authentication chains between DNS
348 zones. A DS RRset SHOULD be present at a delegation point when the
349 child zone is signed. The DS RRset MAY contain multiple records,
350 each referencing a public key in the child zone used to verify the
351 RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS
352 RRsets MUST NOT appear at a zone's apex.
353
354 A DS RR SHOULD point to a DNSKEY RR that is present in the child's
355 apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
356 by the corresponding private key. DS RRs that fail to meet these
357 conditions are not useful for validation, but because the DS RR and
358 its corresponding DNSKEY RR are in different zones, and because the
359 DNS is only loosely consistent, temporary mismatches can occur.
360
361 The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
362 (that is, the NS RRset from the same zone containing the DS RRset).
363
364 Construction of a DS RR requires knowledge of the corresponding
365 DNSKEY RR in the child zone, which implies communication between the
366 child and parent zones. This communication is an operational matter
367 not covered by this document.
368
369 2.5. Changes to the CNAME Resource Record
370
371 If a CNAME RRset is present at a name in a signed zone, appropriate
372 RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
373 name for secure dynamic update purposes is also allowed ([RFC3007]).
374 Other types MUST NOT be present at that name.
375
376 This is a modification to the original CNAME definition given in
377 [RFC1034]. The original definition of the CNAME RR did not allow any
378 other types to coexist with a CNAME record, but a signed zone
379
380
381
382 Arends, et al. Standards Track [Page 7]
383 RFC 4035 DNSSEC Protocol Modifications March 2005
384
385
386 requires NSEC and RRSIG RRs for every authoritative name. To resolve
387 this conflict, this specification modifies the definition of the
388 CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
389
390 2.6. DNSSEC RR Types Appearing at Zone Cuts
391
392 DNSSEC introduced two new RR types that are unusual in that they can
393 appear at the parental side of a zone cut. At the parental side of a
394 zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
395 the owner name. A DS RR could also be present if the zone being
396 delegated is signed and seeks to have a chain of authentication to
397 the parent zone. This is an exception to the original DNS
398 specification ([RFC1034]), which states that only NS RRsets could
399 appear at the parental side of a zone cut.
400
401 This specification updates the original DNS specification to allow
402 NSEC and DS RR types at the parent side of a zone cut. These RRsets
403 are authoritative for the parent when they appear at the parent side
404 of a zone cut.
405
406 2.7. Example of a Secure Zone
407
408 Appendix A shows a complete example of a small signed zone.
409
410 3. Serving
411
412 This section describes the behavior of entities that include
413 security-aware name server functions. In many cases such functions
414 will be part of a security-aware recursive name server, but a
415 security-aware authoritative name server has some of the same
416 requirements. Functions specific to security-aware recursive name
417 servers are described in Section 3.2; functions specific to
418 authoritative servers are described in Section 3.1.
419
420 In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
421 are as used in [RFC1034].
422
423 A security-aware name server MUST support the EDNS0 ([RFC2671])
424 message size extension, MUST support a message size of at least 1220
425 octets, and SHOULD support a message size of 4000 octets. As IPv6
426 packets can only be fragmented by the source host, a security aware
427 name server SHOULD take steps to ensure that UDP datagrams it
428 transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
429 MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460],
430 and [RFC3226] for further discussion of packet size and fragmentation
431 issues.
432
433
434
435
436
437 Arends, et al. Standards Track [Page 8]
438 RFC 4035 DNSSEC Protocol Modifications March 2005
439
440
441 A security-aware name server that receives a DNS query that does not
442 include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
443 treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
444 MUST NOT perform any of the additional processing described below.
445 Because the DS RR type has the peculiar property of only existing in
446 the parent zone at delegation points, DS RRs always require some
447 special processing, as described in Section 3.1.4.1.
448
449 Security aware name servers that receive explicit queries for
450 security RR types that match the content of more than one zone that
451 it serves (for example, NSEC and RRSIG RRs above and below a
452 delegation point where the server is authoritative for both zones)
453 should behave self-consistently. As long as the response is always
454 consistent for each query to the name server, the name server MAY
455 return one of the following:
456
457 o The above-delegation RRsets.
458 o The below-delegation RRsets.
459 o Both above and below-delegation RRsets.
460 o Empty answer section (no records).
461 o Some other response.
462 o An error.
463
464 DNSSEC allocates two new bits in the DNS message header: the CD
465 (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
466 is controlled by resolvers; a security-aware name server MUST copy
467 the CD bit from a query into the corresponding response. The AD bit
468 is controlled by name servers; a security-aware name server MUST
469 ignore the setting of the AD bit in queries. See Sections 3.1.6,
470 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
471
472 A security aware name server that synthesizes CNAME RRs from DNAME
473 RRs as described in [RFC2672] SHOULD NOT generate signatures for the
474 synthesized CNAME RRs.
475
476 3.1. Authoritative Name Servers
477
478 Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
479 pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
480 server for a signed zone MUST include additional RRSIG, NSEC, and DS
481 RRs, according to the following rules:
482
483 o RRSIG RRs that can be used to authenticate a response MUST be
484 included in the response according to the rules in Section 3.1.1.
485
486
487
488
489
490
491
492 Arends, et al. Standards Track [Page 9]
493 RFC 4035 DNSSEC Protocol Modifications March 2005
494
495
496 o NSEC RRs that can be used to provide authenticated denial of
497 existence MUST be included in the response automatically according
498 to the rules in Section 3.1.3.
499
500 o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
501 be included in referrals automatically according to the rules in
502 Section 3.1.4.
503
504 These rules only apply to responses where the semantics convey
505 information about the presence or absence of resource records. That
506 is, these rules are not intended to rule out responses such as RCODE
507 4 ("Not Implemented") or RCODE 5 ("Refused").
508
509 DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
510 discusses zone transfer requirements.
511
512 3.1.1. Including RRSIG RRs in a Response
513
514 When responding to a query that has the DO bit set, a security-aware
515 authoritative name server SHOULD attempt to send RRSIG RRs that a
516 security-aware resolver can use to authenticate the RRsets in the
517 response. A name server SHOULD make every attempt to keep the RRset
518 and its associated RRSIG(s) together in a response. Inclusion of
519 RRSIG RRs in a response is subject to the following rules:
520
521 o When placing a signed RRset in the Answer section, the name server
522 MUST also place its RRSIG RRs in the Answer section. The RRSIG
523 RRs have a higher priority for inclusion than any other RRsets
524 that may have to be included. If space does not permit inclusion
525 of these RRSIG RRs, the name server MUST set the TC bit.
526
527 o When placing a signed RRset in the Authority section, the name
528 server MUST also place its RRSIG RRs in the Authority section.
529 The RRSIG RRs have a higher priority for inclusion than any other
530 RRsets that may have to be included. If space does not permit
531 inclusion of these RRSIG RRs, the name server MUST set the TC bit.
532
533 o When placing a signed RRset in the Additional section, the name
534 server MUST also place its RRSIG RRs in the Additional section.
535 If space does not permit inclusion of both the RRset and its
536 associated RRSIG RRs, the name server MAY retain the RRset while
537 dropping the RRSIG RRs. If this happens, the name server MUST NOT
538 set the TC bit solely because these RRSIG RRs didn't fit.
539
540
541
542
543
544
545
546
547 Arends, et al. Standards Track [Page 10]
548 RFC 4035 DNSSEC Protocol Modifications March 2005
549
550
551 3.1.2. Including DNSKEY RRs in a Response
552
553 When responding to a query that has the DO bit set and that requests
554 the SOA or NS RRs at the apex of a signed zone, a security-aware
555 authoritative name server for that zone MAY return the zone apex
556 DNSKEY RRset in the Additional section. In this situation, the
557 DNSKEY RRset and associated RRSIG RRs have lower priority than does
558 any other information that would be placed in the additional section.
559 The name server SHOULD NOT include the DNSKEY RRset unless there is
560 enough space in the response message for both the DNSKEY RRset and
561 its associated RRSIG RR(s). If there is not enough space to include
562 these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
563 NOT set the TC bit solely because these RRs didn't fit (see Section
564 3.1.1).
565
566 3.1.3. Including NSEC RRs in a Response
567
568 When responding to a query that has the DO bit set, a security-aware
569 authoritative name server for a signed zone MUST include NSEC RRs in
570 each of the following cases:
571
572 No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
573 but does not contain any RRsets that exactly match <SNAME, SCLASS,
574 STYPE>.
575
576 Name Error: The zone does not contain any RRsets that match <SNAME,
577 SCLASS> either exactly or via wildcard name expansion.
578
579 Wildcard Answer: The zone does not contain any RRsets that exactly
580 match <SNAME, SCLASS> but does contain an RRset that matches
581 <SNAME, SCLASS, STYPE> via wildcard name expansion.
582
583 Wildcard No Data: The zone does not contain any RRsets that exactly
584 match <SNAME, SCLASS> and does contain one or more RRsets that
585 match <SNAME, SCLASS> via wildcard name expansion, but does not
586 contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
587 name expansion.
588
589 In each of these cases, the name server includes NSEC RRs in the
590 response to prove that an exact match for <SNAME, SCLASS, STYPE> was
591 not present in the zone and that the response that the name server is
592 returning is correct given the data in the zone.
593
594
595
596
597
598
599
600
601
602 Arends, et al. Standards Track [Page 11]
603 RFC 4035 DNSSEC Protocol Modifications March 2005
604
605
606 3.1.3.1. Including NSEC RRs: No Data Response
607
608 If the zone contains RRsets matching <SNAME, SCLASS> but contains no
609 RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
610 include the NSEC RR for <SNAME, SCLASS> along with its associated
611 RRSIG RR(s) in the Authority section of the response (see Section
612 3.1.1). If space does not permit inclusion of the NSEC RR or its
613 associated RRSIG RR(s), the name server MUST set the TC bit (see
614 Section 3.1.1).
615
616 Since the search name exists, wildcard name expansion does not apply
617 to this query, and a single signed NSEC RR suffices to prove that the
618 requested RR type does not exist.
619
620 3.1.3.2. Including NSEC RRs: Name Error Response
621
622 If the zone does not contain any RRsets matching <SNAME, SCLASS>
623 either exactly or via wildcard name expansion, then the name server
624 MUST include the following NSEC RRs in the Authority section, along
625 with their associated RRSIG RRs:
626
627 o An NSEC RR proving that there is no exact match for <SNAME,
628 SCLASS>.
629
630 o An NSEC RR proving that the zone contains no RRsets that would
631 match <SNAME, SCLASS> via wildcard name expansion.
632
633 In some cases, a single NSEC RR may prove both of these points. If
634 it does, the name server SHOULD only include the NSEC RR and its
635 RRSIG RR(s) once in the Authority section.
636
637 If space does not permit inclusion of these NSEC and RRSIG RRs, the
638 name server MUST set the TC bit (see Section 3.1.1).
639
640 The owner names of these NSEC and RRSIG RRs are not subject to
641 wildcard name expansion when these RRs are included in the Authority
642 section of the response.
643
644 Note that this form of response includes cases in which SNAME
645 corresponds to an empty non-terminal name within the zone (a name
646 that is not the owner name for any RRset but that is the parent name
647 of one or more RRsets).
648
649 3.1.3.3. Including NSEC RRs: Wildcard Answer Response
650
651 If the zone does not contain any RRsets that exactly match <SNAME,
652 SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
653 via wildcard name expansion, the name server MUST include the
654
655
656
657 Arends, et al. Standards Track [Page 12]
658 RFC 4035 DNSSEC Protocol Modifications March 2005
659
660
661 wildcard-expanded answer and the corresponding wildcard-expanded
662 RRSIG RRs in the Answer section and MUST include in the Authority
663 section an NSEC RR and associated RRSIG RR(s) proving that the zone
664 does not contain a closer match for <SNAME, SCLASS>. If space does
665 not permit inclusion of the answer, NSEC and RRSIG RRs, the name
666 server MUST set the TC bit (see Section 3.1.1).
667
668 3.1.3.4. Including NSEC RRs: Wildcard No Data Response
669
670 This case is a combination of the previous cases. The zone does not
671 contain an exact match for <SNAME, SCLASS>, and although the zone
672 does contain RRsets that match <SNAME, SCLASS> via wildcard
673 expansion, none of those RRsets matches STYPE. The name server MUST
674 include the following NSEC RRs in the Authority section, along with
675 their associated RRSIG RRs:
676
677 o An NSEC RR proving that there are no RRsets matching STYPE at the
678 wildcard owner name that matched <SNAME, SCLASS> via wildcard
679 expansion.
680
681 o An NSEC RR proving that there are no RRsets in the zone that would
682 have been a closer match for <SNAME, SCLASS>.
683
684 In some cases, a single NSEC RR may prove both of these points. If
685 it does, the name server SHOULD only include the NSEC RR and its
686 RRSIG RR(s) once in the Authority section.
687
688 The owner names of these NSEC and RRSIG RRs are not subject to
689 wildcard name expansion when these RRs are included in the Authority
690 section of the response.
691
692 If space does not permit inclusion of these NSEC and RRSIG RRs, the
693 name server MUST set the TC bit (see Section 3.1.1).
694
695 3.1.3.5. Finding the Right NSEC RRs
696
697 As explained above, there are several situations in which a
698 security-aware authoritative name server has to locate an NSEC RR
699 that proves that no RRsets matching a particular SNAME exist.
700 Locating such an NSEC RR within an authoritative zone is relatively
701 simple, at least in concept. The following discussion assumes that
702 the name server is authoritative for the zone that would have held
703 the non-existent RRsets matching SNAME. The algorithm below is
704 written for clarity, not for efficiency.
705
706 To find the NSEC that proves that no RRsets matching name N exist in
707 the zone Z that would have held them, construct a sequence, S,
708 consisting of the owner names of every RRset in Z, sorted into
709
710
711
712 Arends, et al. Standards Track [Page 13]
713 RFC 4035 DNSSEC Protocol Modifications March 2005
714
715
716 canonical order ([RFC4034]), with no duplicate names. Find the name
717 M that would have immediately preceded N in S if any RRsets with
718 owner name N had existed. M is the owner name of the NSEC RR that
719 proves that no RRsets exist with owner name N.
720
721 The algorithm for finding the NSEC RR that proves that a given name
722 is not covered by any applicable wildcard is similar but requires an
723 extra step. More precisely, the algorithm for finding the NSEC
724 proving that no RRsets exist with the applicable wildcard name is
725 precisely the same as the algorithm for finding the NSEC RR that
726 proves that RRsets with any other owner name do not exist. The part
727 that's missing is a method of determining the name of the non-
728 existent applicable wildcard. In practice, this is easy, because the
729 authoritative name server has already checked for the presence of
730 precisely this wildcard name as part of step (1)(c) of the normal
731 lookup algorithm described in Section 4.3.2 of [RFC1034].
732
733 3.1.4. Including DS RRs in a Response
734
735 When responding to a query that has the DO bit set, a security-aware
736 authoritative name server returning a referral includes DNSSEC data
737 along with the NS RRset.
738
739 If a DS RRset is present at the delegation point, the name server
740 MUST return both the DS RRset and its associated RRSIG RR(s) in the
741 Authority section along with the NS RRset.
742
743 If no DS RRset is present at the delegation point, the name server
744 MUST return both the NSEC RR that proves that the DS RRset is not
745 present and the NSEC RR's associated RRSIG RR(s) along with the NS
746 RRset. The name server MUST place the NS RRset before the NSEC RRset
747 and its associated RRSIG RR(s).
748
749 Including these DS, NSEC, and RRSIG RRs increases the size of
750 referral messages and may cause some or all glue RRs to be omitted.
751 If space does not permit inclusion of the DS or NSEC RRset and
752 associated RRSIG RRs, the name server MUST set the TC bit (see
753 Section 3.1.1).
754
755 3.1.4.1. Responding to Queries for DS RRs
756
757 The DS resource record type is unusual in that it appears only on the
758 parent zone's side of a zone cut. For example, the DS RRset for the
759 delegation of "foo.example" is stored in the "example" zone rather
760 than in the "foo.example" zone. This requires special processing
761 rules for both name servers and resolvers, as the name server for the
762 child zone is authoritative for the name at the zone cut by the
763 normal DNS rules but the child zone does not contain the DS RRset.
764
765
766
767 Arends, et al. Standards Track [Page 14]
768 RFC 4035 DNSSEC Protocol Modifications March 2005
769
770
771 A security-aware resolver sends queries to the parent zone when
772 looking for a needed DS RR at a delegation point (see Section 4.2).
773 However, special rules are necessary to avoid confusing
774 security-oblivious resolvers which might become involved in
775 processing such a query (for example, in a network configuration that
776 forces a security-aware resolver to channel its queries through a
777 security-oblivious recursive name server). The rest of this section
778 describes how a security-aware name server processes DS queries in
779 order to avoid this problem.
780
RFC9077 updates many RFCs to clarify how TTLs are calculated
when using DNSSEC. For RFC 4035, it replaces:
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.
with:
The TTL of the NSEC RR that is returned MUST be the lesser of the MINIMUM field of the SOA record and the TTL of the SOA itself. This matches the definition of the TTL for negative responses in [RFC2308]. Because some signers incrementally update the NSEC chain, a transient inconsistency between the observed and expected TTL MAY exist.
781 The need for special processing by a security-aware name server only
782 arises when all the following conditions are met:
783
784 o The name server has received a query for the DS RRset at a zone
785 cut.
786
787 o The name server is authoritative for the child zone.
788
789 o The name server is not authoritative for the parent zone.
790
791 o The name server does not offer recursion.
792
793 In all other cases, the name server either has some way of obtaining
794 the DS RRset or could not have been expected to have the DS RRset
795 even by the pre-DNSSEC processing rules, so the name server can
796 return either the DS RRset or an error response according to the
797 normal processing rules.
798
799 If all the above conditions are met, however, the name server is
800 authoritative for SNAME but cannot supply the requested RRset. In
801 this case, the name server MUST return an authoritative "no data"
802 response showing that the DS RRset does not exist in the child zone's
803 apex. See Appendix B.8 for an example of such a response.
804
805 3.1.5. Responding to Queries for Type AXFR or IXFR
806
807 DNSSEC does not change the DNS zone transfer process. A signed zone
808 will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
809 records have no special meaning with respect to a zone transfer
810 operation.
811
812 An authoritative name server is not required to verify that a zone is
813 properly signed before sending or accepting a zone transfer.
814 However, an authoritative name server MAY choose to reject the entire
815 zone transfer if the zone fails to meet any of the signing
816 requirements described in Section 2. The primary objective of a zone
817 transfer is to ensure that all authoritative name servers have
818 identical copies of the zone. An authoritative name server that
819
820
821
822 Arends, et al. Standards Track [Page 15]
823 RFC 4035 DNSSEC Protocol Modifications March 2005
824
825
826 chooses to perform its own zone validation MUST NOT selectively
827 reject some RRs and accept others.
828
829 DS RRsets appear only on the parental side of a zone cut and are
830 authoritative data in the parent zone. As with any other
831 authoritative RRset, the DS RRset MUST be included in zone transfers
832 of the zone in which the RRset is authoritative data. In the case of
833 the DS RRset, this is the parent zone.
834
835 NSEC RRs appear in both the parent and child zones at a zone cut and
836 are authoritative data in both the parent and child zones. The
837 parental and child NSEC RRs at a zone cut are never identical to each
838 other, as the NSEC RR in the child zone's apex will always indicate
839 the presence of the child zone's SOA RR whereas the parental NSEC RR
840 at the zone cut will never indicate the presence of an SOA RR. As
841 with any other authoritative RRs, NSEC RRs MUST be included in zone
842 transfers of the zone in which they are authoritative data. The
843 parental NSEC RR at a zone cut MUST be included in zone transfers of
844 the parent zone, and the NSEC at the zone apex of the child zone MUST
845 be included in zone transfers of the child zone.
846
847 RRSIG RRs appear in both the parent and child zones at a zone cut and
848 are authoritative in whichever zone contains the authoritative RRset
849 for which the RRSIG RR provides the signature. That is, the RRSIG RR
850 for a DS RRset or a parental NSEC RR at a zone cut will be
851 authoritative in the parent zone, and the RRSIG for any RRset in the
852 child zone's apex will be authoritative in the child zone. Parental
853 and child RRSIG RRs at a zone cut will never be identical to each
854 other, as the Signer's Name field of an RRSIG RR in the child zone's
855 apex will indicate a DNSKEY RR in the child zone's apex whereas the
856 same field of a parental RRSIG RR at the zone cut will indicate a
857 DNSKEY RR in the parent zone's apex. As with any other authoritative
858 RRs, RRSIG RRs MUST be included in zone transfers of the zone in
859 which they are authoritative data.
860
861 3.1.6. The AD and CD Bits in an Authoritative Response
862
863 The CD and AD bits are designed for use in communication between
864 security-aware resolvers and security-aware recursive name servers.
865 These bits are for the most part not relevant to query processing by
866 security-aware authoritative name servers.
867
868 A security-aware name server does not perform signature validation
869 for authoritative data during query processing, even when the CD bit
870 is clear. A security-aware name server SHOULD clear the CD bit when
871 composing an authoritative response.
872
873
874
875
876
877 Arends, et al. Standards Track [Page 16]
878 RFC 4035 DNSSEC Protocol Modifications March 2005
879
880
881 A security-aware name server MUST NOT set the AD bit in a response
882 unless the name server considers all RRsets in the Answer and
883 Authority sections of the response to be authentic. A security-aware
884 name server's local policy MAY consider data from an authoritative
885 zone to be authentic without further validation. However, the name
886 server MUST NOT do so unless the name server obtained the
887 authoritative zone via secure means (such as a secure zone transfer
888 mechanism) and MUST NOT do so unless this behavior has been
889 configured explicitly.
890
891 A security-aware name server that supports recursion MUST follow the
892 rules for the CD and AD bits given in Section 3.2 when generating a
893 response that involves data obtained via recursion.
894
895 3.2. Recursive Name Servers
896
897 As explained in [RFC4033], a security-aware recursive name server is
898 an entity that acts in both the security-aware name server and
899 security-aware resolver roles. This section uses the terms "name
900 server side" and "resolver side" to refer to the code within a
901 security-aware recursive name server that implements the
902 security-aware name server role and the code that implements the
903 security-aware resolver role, respectively.
904
905 The resolver side follows the usual rules for caching and negative
906 caching that would apply to any security-aware resolver.
907
908 3.2.1. The DO Bit
909
910 The resolver side of a security-aware recursive name server MUST set
911 the DO bit when sending requests, regardless of the state of the DO
912 bit in the initiating request received by the name server side. If
913 the DO bit in an initiating query is not set, the name server side
914 MUST strip any authenticating DNSSEC RRs from the response but MUST
915 NOT strip any DNSSEC RR types that the initiating query explicitly
916 requested.
917
The need for special processing by a security-aware name server only
arises when all the following conditions are met:
o The name server has received a query for the DS RRset at a zone
cut.
o The name server is authoritative for the child zone.
o The name server is not authoritative for the parent zone.
o The name server does not offer recursion.
The need for special processing by a security-aware name server only
arises when all the following conditions are met:
o The name server has received a query for the DS RRset at a zone
cut.
o The name server is authoritative for the child zone.
o The name server is not authoritative for the parent zoneany zone above the
child's apex.
o The name server does not offer recursion.
918 3.2.2. The CD Bit
919
920 The CD bit exists in order to allow a security-aware resolver to
921 disable signature validation in a security-aware name server's
922 processing of a particular query.
923
924 The name server side MUST copy the setting of the CD bit from a query
925 to the corresponding response.
926
927 The name server side of a security-aware recursive name server MUST
928 pass the state of the CD bit to the resolver side along with the rest
929
930
931
932 Arends, et al. Standards Track [Page 17]
933 RFC 4035 DNSSEC Protocol Modifications March 2005
934
935
936 of an initiating query, so that the resolver side will know whether
937 it is required to verify the response data it returns to the name
938 server side. If the CD bit is set, it indicates that the originating
939 resolver is willing to perform whatever authentication its local
940 policy requires. Thus, the resolver side of the recursive name
941 server need not perform authentication on the RRsets in the response.
942 When the CD bit is set, the recursive name server SHOULD, if
943 possible, return the requested data to the originating resolver, even
944 if the recursive name server's local authentication policy would
945 reject the records in question. That is, by setting the CD bit, the
946 originating resolver has indicated that it takes responsibility for
947 performing its own authentication, and the recursive name server
948 should not interfere.
949
950 If the resolver side implements a BAD cache (see Section 4.7) and the
951 name server side receives a query that matches an entry in the
952 resolver side's BAD cache, the name server side's response depends on
953 the state of the CD bit in the original query. If the CD bit is set,
954 the name server side SHOULD return the data from the BAD cache; if
955 the CD bit is not set, the name server side MUST return RCODE 2
956 (server failure).
957
958 The intent of the above rule is to provide the raw data to clients
959 that are capable of performing their own signature verification
960 checks while protecting clients that depend on the resolver side of a
961 security-aware recursive name server to perform such checks. Several
962 of the possible reasons why signature validation might fail involve
963 conditions that may not apply equally to the recursive name server
964 and the client that invoked it. For example, the recursive name
965 server's clock may be set incorrectly, or the client may have
966 knowledge of a relevant island of security that the recursive name
967 server does not share. In such cases, "protecting" a client that is
968 capable of performing its own signature validation from ever seeing
969 the "bad" data does not help the client.
970
Section 5.9 of RFC6840 says:
When processing a request with the Checking Disabled (CD) bit set, a resolver SHOULD attempt to return all response data, even data that has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a resolver processing a request with the CD bit set to set the CD bit on its upstream queries. This document further specifies that validating resolvers SHOULD set the CD bit on every upstream query. This is regardless of whether the CD bit was set on the incoming query or whether it has a trust anchor at or above the QNAME. [RFC4035] is ambiguous about what to do when a cached response was obtained with the CD bit unset, a case that only arises when the resolver chooses not to set the CD bit on all upstream queries, as specified above. In the typical case, no new query is required, nor does the cache need to track the state of the CD bit used to make a given query. The problem arises when the cached response is a server failure (RCODE 2), which may indicate that the requested data failed DNSSEC validation at an upstream validating resolver. ([RFC2308] permits caching of server failures for up to five minutes.) In these cases, a new query with the CD bit set is required.
Be sure to read Appendix B of RFC6840, which details the logic behind the recommendation to alwas set the CD bit on queries.
971 3.2.3. The AD Bit
972
973 The name server side of a security-aware recursive name server MUST
974 NOT set the AD bit in a response unless the name server considers all
975 RRsets in the Answer and Authority sections of the response to be
976 authentic. The name server side SHOULD set the AD bit if and only if
977 the resolver side considers all RRsets in the Answer section and any
978 relevant negative response RRs in the Authority section to be
979 authentic. The resolver side MUST follow the procedure described in
980 Section 5 to determine whether the RRs in question are authentic.
981 However, for backward compatibility, a recursive name server MAY set
982 the AD bit when a response includes unsigned CNAME RRs if those CNAME
983
984
985
986
987 Arends, et al. Standards Track [Page 18]
988 RFC 4035 DNSSEC Protocol Modifications March 2005
989
990
991 RRs demonstrably could have been synthesized from an authentic DNAME
992 RR that is also included in the response according to the synthesis
993 rules described in [RFC2672].
994
995 3.3. Example DNSSEC Responses
996
997 See Appendix B for example response packets.
998
999 4. Resolving
1000
1001 This section describes the behavior of entities that include
1002 security-aware resolver functions. In many cases such functions will
1003 be part of a security-aware recursive name server, but a stand-alone
1004 security-aware resolver has many of the same requirements. Functions
1005 specific to security-aware recursive name servers are described in
1006 Section 3.2.
1007
1008 4.1. EDNS Support
1009
1010 A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
1011 pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
1012
1013 A security-aware resolver MUST support a message size of at least
1014 1220 octets, SHOULD support a message size of 4000 octets, and MUST
1015 use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
1016 to advertise the message size that it is willing to accept. A
1017 security-aware resolver's IP layer MUST handle fragmented UDP packets
1018 correctly regardless of whether any such fragmented packets were
1019 received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and
1020 [RFC3226] for discussion of these requirements.
1021
Section 5.8 of RFC6840 says:
Section 3.2.3 of [RFC4035] describes under which conditions a validating resolver should set or clear the AD bit in a response. In order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit.
1022 4.2. Signature Verification Support
1023
1024 A security-aware resolver MUST support the signature verification
1025 mechanisms described in Section 5 and SHOULD apply them to every
1026 received response, except when:
1027
1028 o the security-aware resolver is part of a security-aware recursive
1029 name server, and the response is the result of recursion on behalf
1030 of a query received with the CD bit set;
1031
1032 o the response is the result of a query generated directly via some
1033 form of application interface that instructed the security-aware
1034 resolver not to perform validation for this query; or
1035
1036 o validation for this query has been disabled by local policy.
1037
1038
1039
1040
1041
1042 Arends, et al. Standards Track [Page 19]
1043 RFC 4035 DNSSEC Protocol Modifications March 2005
1044
1045
1046 A security-aware resolver's support for signature verification MUST
1047 include support for verification of wildcard owner names.
1048
1049 Security-aware resolvers MAY query for missing security RRs in an
1050 attempt to perform validation; implementations that choose to do so
1051 must be aware that the answers received may not be sufficient to
1052 validate the original response. For example, a zone update may have
1053 changed (or deleted) the desired information between the original and
1054 follow-up queries.
1055
1056 When attempting to retrieve missing NSEC RRs that reside on the
1057 parental side at a zone cut, a security-aware iterative-mode resolver
1058 MUST query the name servers for the parent zone, not the child zone.
1059
1060 When attempting to retrieve a missing DS, a security-aware
1061 iterative-mode resolver MUST query the name servers for the parent
1062 zone, not the child zone. As explained in Section 3.1.4.1,
1063 security-aware name servers need to apply special processing rules to
1064 handle the DS RR, and in some situations the resolver may also need
1065 to apply special rules to locate the name servers for the parent zone
1066 if the resolver does not already have the parent's NS RRset. To
1067 locate the parent NS RRset, the resolver can start with the
1068 delegation name, strip off the leftmost label, and query for an NS
1069 RRset by that name. If no NS RRset is present at that name, the
1070 resolver then strips off the leftmost remaining label and retries the
1071 query for that name, repeating this process of walking up the tree
1072 until it either finds the NS RRset or runs out of labels.
1073
1074 4.3. Determining Security Status of Data
1075
1076 A security-aware resolver MUST be able to determine whether it should
1077 expect a particular RRset to be signed. More precisely, a
1078 security-aware resolver must be able to distinguish between four
1079 cases:
1080
1081 Secure: An RRset for which the resolver is able to build a chain of
1082 signed DNSKEY and DS RRs from a trusted security anchor to the
1083 RRset. In this case, the RRset should be signed and is subject to
1084 signature validation, as described above.
1085
1086 Insecure: An RRset for which the resolver knows that it has no chain
1087 of signed DNSKEY and DS RRs from any trusted starting point to the
1088 RRset. This can occur when the target RRset lies in an unsigned
1089 zone or in a descendent of an unsigned zone. In this case, the
1090 RRset may or may not be signed, but the resolver will not be able
1091 to verify the signature.
1092
1093
1094
1095
1096
1097 Arends, et al. Standards Track [Page 20]
1098 RFC 4035 DNSSEC Protocol Modifications March 2005
1099
1100
1101 Bogus: An RRset for which the resolver believes that it ought to be
1102 able to establish a chain of trust but for which it is unable to
1103 do so, either due to signatures that for some reason fail to
1104 validate or due to missing data that the relevant DNSSEC RRs
1105 indicate should be present. This case may indicate an attack but
1106 may also indicate a configuration error or some form of data
1107 corruption.
1108
1109 Indeterminate: An RRset for which the resolver is not able to
1110 determine whether the RRset should be signed, as the resolver is
1111 not able to obtain the necessary DNSSEC RRs. This can occur when
1112 the security-aware resolver is not able to contact security-aware
1113 name servers for the relevant zones.
1114
1115 4.4. Configured Trust Anchors
1116
1117 A security-aware resolver MUST be capable of being configured with at
1118 least one trusted public key or DS RR and SHOULD be capable of being
1119 configured with multiple trusted public keys or DS RRs. Since a
1120 security-aware resolver will not be able to validate signatures
1121 without such a configured trust anchor, the resolver SHOULD have some
1122 reasonably robust mechanism for obtaining such keys when it boots;
1123 examples of such a mechanism would be some form of non-volatile
1124 storage (such as a disk drive) or some form of trusted local network
1125 configuration mechanism.
1126
1127 Note that trust anchors also cover key material that is updated in a
1128 secure manner. This secure manner could be through physical media, a
1129 key exchange protocol, or some other out-of-band means.
1130
1131 4.5. Response Caching
1132
1133 A security-aware resolver SHOULD cache each response as a single
1134 atomic entry containing the entire answer, including the named RRset
1135 and any associated DNSSEC RRs. The resolver SHOULD discard the
1136 entire atomic entry when any of the RRs contained in it expire. In
1137 most cases the appropriate cache index for the atomic entry will be
1138 the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
1139 form described in Section 3.1.3.2 the appropriate cache index will be
1140 the double <QNAME,QCLASS>.
1141
1142 The reason for these recommendations is that, between the initial
1143 query and the expiration of the data from the cache, the
1144 authoritative data might have been changed (for example, via dynamic
1145 update).
1146
1147
1148
1149
1150
1151
1152 Arends, et al. Standards Track [Page 21]
1153 RFC 4035 DNSSEC Protocol Modifications March 2005
1154
1155
1156 There are two situations for which this is relevant:
1157
1158 1. By using the RRSIG record, it is possible to deduce that an
1159 answer was synthesized from a wildcard. A security-aware
1160 recursive name server could store this wildcard data and use it
1161 to generate positive responses to queries other than the name for
1162 which the original answer was first received.
1163
1164 2. NSEC RRs received to prove the non-existence of a name could be
1165 reused by a security-aware resolver to prove the non-existence of
1166 any name in the name range it spans.
1167
Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries.
Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so MUST be aware that the answers received may not be sufficient to validate the original response. For example, a zone update may have changed (or deleted) the desired information between the original and follow-up queries.
"MUST" is a key word according to RFC 2119/BCP 14 and should be capitalized. --VERIFIER NOTES-- As it appears to the original authors, remaining members of dnsext mailing list, and myself as INT AD, the "must" here is not normative and should be kept in lowercase. See also: https://mailarchive.ietf.org/arch/msg/dnsext/1PZ58ajXFj_RodKgHzus6d6UB- U/
1168 In theory, a resolver could use wildcards or NSEC RRs to generate
1169 positive and negative responses (respectively) until the TTL or
1170 signatures on the records in question expire. However, it seems
1171 prudent for resolvers to avoid blocking new authoritative data or
1172 synthesizing new data on their own. Resolvers that follow this
1173 recommendation will have a more consistent view of the namespace.
1174
The abstract of RFC8198 says
"This document updates RFC 4035 by allowing validating resolvers to
generate negative answers based upon NSEC/NSEC3 records and positive
answers in the presence of wildcards."
In specific, it replaces this pargraph ("In theory, a resolver...") with:
Once the records are validated, DNSSEC-enabled validating resolvers SHOULD use wildcards and NSEC/NSEC3 resource records to generate positive and negative responses until the effective TTLs or signatures for those records expire.
1175 4.6. Handling of the CD and AD Bits
1176
1177 A security-aware resolver MAY set a query's CD bit in order to
1178 indicate that the resolver takes responsibility for performing
1179 whatever authentication its local policy requires on the RRsets in
1180 the response. See Section 3.2 for the effect this bit has on the
1181 behavior of security-aware recursive name servers.
1182
1183 A security-aware resolver MUST clear the AD bit when composing query
1184 messages to protect against buggy name servers that blindly copy
1185 header bits that they do not understand from the query message to the
1186 response message.
1187
1188 A resolver MUST disregard the meaning of the CD and AD bits in a
1189 response unless the response was obtained by using a secure channel
1190 or the resolver was specifically configured to regard the message
1191 header bits without using a secure channel.
1192
Section 5.7 of RFC6840 says:
The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit.
Further, Section 5.8 of RFC6840 says:
Section 3.2.3 of [RFC4035] describes under which conditions a validating resolver should set or clear the AD bit in a response. In order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit.
1193 4.7. Caching BAD Data
1194
1195 While many validation errors will be transient, some are likely to be
1196 more persistent, such as those caused by administrative error
1197 (failure to re-sign a zone, clock skew, and so forth). Since
1198 requerying will not help in these cases, validating resolvers might
1199 generate a significant amount of unnecessary DNS traffic as a result
1200 of repeated queries for RRsets with persistent validation failures.
1201
1202 To prevent such unnecessary DNS traffic, security-aware resolvers MAY
1203 cache data with invalid signatures, with some restrictions.
1204
1205
1206
1207 Arends, et al. Standards Track [Page 22]
1208 RFC 4035 DNSSEC Protocol Modifications March 2005
1209
1210
1211 Conceptually, caching such data is similar to negative caching
1212 ([RFC2308]), except that instead of caching a valid negative
1213 response, the resolver is caching the fact that a particular answer
1214 failed to validate. This document refers to a cache of data with
1215 invalid signatures as a "BAD cache".
1216
1217 Resolvers that implement a BAD cache MUST take steps to prevent the
1218 cache from being useful as a denial-of-service attack amplifier,
1219 particularly the following:
1220
1221 o Since RRsets that fail to validate do not have trustworthy TTLs,
1222 the implementation MUST assign a TTL. This TTL SHOULD be small,
1223 in order to mitigate the effect of caching the results of an
1224 attack.
1225
1226 o In order to prevent caching of a transient validation failure
1227 (which might be the result of an attack), resolvers SHOULD track
1228 queries that result in validation failures and SHOULD only answer
1229 from the BAD cache after the number of times that responses to
1230 queries for that particular <QNAME, QTYPE, QCLASS> have failed to
1231 validate exceeds a threshold value.
1232
1233 Resolvers MUST NOT return RRsets from the BAD cache unless the
1234 resolver is not required to validate the signatures of the RRsets in
1235 question under the rules given in Section 4.2 of this document. See
1236 Section 3.2.2 for discussion of how the responses returned by a
1237 security-aware recursive name server interact with a BAD cache.
1238
1239 4.8. Synthesized CNAMEs
1240
1241 A validating security-aware resolver MUST treat the signature of a
1242 valid signed DNAME RR as also covering unsigned CNAME RRs that could
1243 have been synthesized from the DNAME RR, as described in [RFC2672],
1244 at least to the extent of not rejecting a response message solely
1245 because it contains such CNAME RRs. The resolver MAY retain such
1246 CNAME RRs in its cache or in the answers it hands back, but is not
1247 required to do so.
1248
1249 4.9. Stub Resolvers
1250
1251 A security-aware stub resolver MUST support the DNSSEC RR types, at
1252 least to the extent of not mishandling responses just because they
1253 contain DNSSEC RRs.
1254
1255
1256
1257
1258
1259
1260
1261
1262 Arends, et al. Standards Track [Page 23]
1263 RFC 4035 DNSSEC Protocol Modifications March 2005
1264
1265
1266 4.9.1. Handling of the DO Bit
1267
1268 A non-validating security-aware stub resolver MAY include the DNSSEC
1269 RRs returned by a security-aware recursive name server as part of the
1270 data that the stub resolver hands back to the application that
1271 invoked it, but is not required to do so. A non-validating stub
1272 resolver that seeks to do this will need to set the DO bit in order
1273 to receive DNSSEC RRs from the recursive name server.
1274
1275 A validating security-aware stub resolver MUST set the DO bit,
1276 because otherwise it will not receive the DNSSEC RRs it needs to
1277 perform signature validation.
1278
1279 4.9.2. Handling of the CD Bit
1280
1281 A non-validating security-aware stub resolver SHOULD NOT set the CD
1282 bit when sending queries unless it is requested by the application
1283 layer, as by definition, a non-validating stub resolver depends on
1284 the security-aware recursive name server to perform validation on its
1285 behalf.
1286
1287 A validating security-aware stub resolver SHOULD set the CD bit,
1288 because otherwise the security-aware recursive name server will
1289 answer the query using the name server's local policy, which may
1290 prevent the stub resolver from receiving data that would be
1291 acceptable to the stub resolver's local policy.
1292
1293 4.9.3. Handling of the AD Bit
1294
1295 A non-validating security-aware stub resolver MAY chose to examine
1296 the setting of the AD bit in response messages that it receives in
1297 order to determine whether the security-aware recursive name server
1298 that sent the response claims to have cryptographically verified the
1299 data in the Answer and Authority sections of the response message.
1300 Note, however, that the responses received by a security-aware stub
1301 resolver are heavily dependent on the local policy of the
1302 security-aware recursive name server. Therefore, there may be little
1303 practical value in checking the status of the AD bit, except perhaps
1304 as a debugging aid. In any case, a security-aware stub resolver MUST
1305 NOT place any reliance on signature validation allegedly performed on
1306 its behalf, except when the security-aware stub resolver obtained the
1307 data in question from a trusted security-aware recursive name server
1308 via a secure channel.
1309
1310 A validating security-aware stub resolver SHOULD NOT examine the
1311 setting of the AD bit in response messages, as, by definition, the
1312 stub resolver performs its own signature validation regardless of the
1313 setting of the AD bit.
1314
1315
1316
1317 Arends, et al. Standards Track [Page 24]
1318 RFC 4035 DNSSEC Protocol Modifications March 2005
1319
1320
Section 3.1 of RFC6840 says:
Section 4.7 of [RFC4035] permits security-aware resolvers to implement a BAD cache. That guidance has changed: security-aware resolvers SHOULD implement a BAD cache as described in [RFC4035]. This change in guidance is based on operational experience with DNSSEC administrative errors leading to significant increases in DNS traffic, with an accompanying realization that such events are more likely and more damaging than originally supposed. An example of one such event is documented in "Rolling Over DNSSEC Keys" [Huston].
1321 5. Authenticating DNS Responses
1322
1323 To use DNSSEC RRs for authentication, a security-aware resolver
1324 requires configured knowledge of at least one authenticated DNSKEY or
1325 DS RR. The process for obtaining and authenticating this initial
1326 trust anchor is achieved via some external mechanism. For example, a
1327 resolver could use some off-line authenticated exchange to obtain a
1328 zone's DNSKEY RR or to obtain a DS RR that identifies and
1329 authenticates a zone's DNSKEY RR. The remainder of this section
1330 assumes that the resolver has somehow obtained an initial set of
1331 trust anchors.
1332
1333 An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
1334 RRset. To authenticate an apex DNSKEY RRset by using an initial key,
1335 the resolver MUST:
1336
1337 1. verify that the initial DNSKEY RR appears in the apex DNSKEY
1338 RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
1339 bit 7) set; and
1340
1341 2. verify that there is some RRSIG RR that covers the apex DNSKEY
1342 RRset, and that the combination of the RRSIG RR and the initial
1343 DNSKEY RR authenticates the DNSKEY RRset. The process for using
1344 an RRSIG RR to authenticate an RRset is described in Section 5.3.
1345
1346 Once the resolver has authenticated the apex DNSKEY RRset by using an
1347 initial DNSKEY RR, delegations from that zone can be authenticated by
1348 using DS RRs. This allows a resolver to start from an initial key
1349 and use DS RRsets to proceed recursively down the DNS tree, obtaining
1350 other apex DNSKEY RRsets. If the resolver were configured with a
1351 root DNSKEY RR, and if every delegation had a DS RR associated with
1352 it, then the resolver could obtain and validate any apex DNSKEY
1353 RRset. The process of using DS RRs to authenticate referrals is
1354 described in Section 5.2.
1355
1356 Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
1357 DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
1358 RRsets in the zone once the resolver has authenticated a zone's apex
1359 DNSKEY RRset. Section 5.4 shows how the resolver can use
1360 authenticated NSEC RRsets from the zone to prove that an RRset is not
1361 present in the zone.
1362
1363 When a resolver indicates support for DNSSEC (by setting the DO bit),
1364 a security-aware name server should attempt to provide the necessary
1365 DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
1366 However, a security-aware resolver may still receive a response that
1367 lacks the appropriate DNSSEC RRs, whether due to configuration issues
1368 such as an upstream security-oblivious recursive name server that
1369
1370
1371
1372 Arends, et al. Standards Track [Page 25]
1373 RFC 4035 DNSSEC Protocol Modifications March 2005
1374
1375
1376 accidentally interferes with DNSSEC RRs or due to a deliberate attack
1377 in which an adversary forges a response, strips DNSSEC RRs from a
1378 response, or modifies a query so that DNSSEC RRs appear not to be
1379 requested. The absence of DNSSEC data in a response MUST NOT by
1380 itself be taken as an indication that no authentication information
1381 exists.
1382
1383 A resolver SHOULD expect authentication information from signed
1384 zones. A resolver SHOULD believe that a zone is signed if the
1385 resolver has been configured with public key information for the
1386 zone, or if the zone's parent is signed and the delegation from the
1387 parent contains a DS RRset.
1388
1389 5.1. Special Considerations for Islands of Security
1390
1391 Islands of security (see [RFC4033]) are signed zones for which it is
1392 not possible to construct an authentication chain to the zone from
1393 its parent. Validating signatures within an island of security
1394 requires that the validator have some other means of obtaining an
1395 initial authenticated zone key for the island. If a validator cannot
1396 obtain such a key, it SHOULD switch to operating as if the zones in
1397 the island of security are unsigned.
1398
1399 All the normal processes for validating responses apply to islands of
1400 security. The only difference between normal validation and
1401 validation within an island of security is in how the validator
1402 obtains a trust anchor for the authentication chain.
1403
Section 4.3 of RFC6840 says:
Section 5 of [RFC4035] says nothing explicit about validating responses based on (or that should be based on) CNAMEs. When validating a NOERROR/NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the bit for the query type. Without this check, an attacker could successfully transform a positive CNAME response into a NOERROR/NODATA response by (for example) simply stripping the CNAME RRset from the response. A naive validator would then note that the QTYPE was not present in the matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was set; thus, the response should have been a positive CNAME response.
1404 5.2. Authenticating Referrals
1405
1406 Once the apex DNSKEY RRset for a signed parent zone has been
1407 authenticated, DS RRsets can be used to authenticate the delegation
1408 to a signed child zone. A DS RR identifies a DNSKEY RR in the child
1409 zone's apex DNSKEY RRset and contains a cryptographic digest of the
1410 child zone's DNSKEY RR. Use of a strong cryptographic digest
1411 algorithm ensures that it is computationally infeasible for an
1412 adversary to generate a DNSKEY RR that matches the digest. Thus,
1413 authenticating the digest allows a resolver to authenticate the
1414 matching DNSKEY RR. The resolver can then use this child DNSKEY RR
1415 to authenticate the entire child apex DNSKEY RRset.
1416
1417 Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
1418 can be authenticated if all of the following hold:
1419
1420 o The DS RR has been authenticated using some DNSKEY RR in the
1421 parent's apex DNSKEY RRset (see Section 5.3).
1422
1423
1424
1425
1426
1427 Arends, et al. Standards Track [Page 26]
1428 RFC 4035 DNSSEC Protocol Modifications March 2005
1429
1430
1431 o The Algorithm and Key Tag in the DS RR match the Algorithm field
1432 and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
1433 RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
1434 using the digest algorithm specified in the DS RR's Digest Type
1435 field, the resulting digest value matches the Digest field of the
1436 DS RR.
1437
1438 o The matching DNSKEY RR in the child zone has the Zone Flag bit
1439 set, the corresponding private key has signed the child zone's
1440 apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
1441 child zone's apex DNSKEY RRset.
1442
1443 If the referral from the parent zone did not contain a DS RRset, the
1444 response should have included a signed NSEC RRset proving that no DS
1445 RRset exists for the delegated name (see Section 3.1.4). A
1446 security-aware resolver MUST query the name servers for the parent
1447 zone for the DS RRset if the referral includes neither a DS RRset nor
1448 a NSEC RRset proving that the DS RRset does not exist (see Section
1449 4).
1450
1451 If the validator authenticates an NSEC RRset that proves that no DS
1452 RRset is present for this zone, then there is no authentication path
1453 leading from the parent to the child. If the resolver has an initial
1454 DNSKEY or DS RR that belongs to the child zone or to any delegation
1455 below the child zone, this initial DNSKEY or DS RR MAY be used to
1456 re-establish an authentication path. If no such initial DNSKEY or DS
1457 RR exists, the validator cannot authenticate RRsets in or below the
1458 child zone.
1459
Section 4.4 of RFC6840 says:
Section 5.2 of [RFC4035] specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also MUST check for the presence of the NS bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation), or alternately make sure that the delegation is covered by an NSEC3 RR with the Opt-Out flag set. Without this check, an attacker could reuse an NSEC or NSEC3 RR matching a non-delegation name to spoof an unsigned delegation at that name. This would claim that an existing signed RRset (or set of signed RRsets) is below an unsigned delegation, thus not signed and vulnerable to further attack.
Section 5.3 of RFC6840 gives an extensive discussion of how to handle zones that are signed with private algorithms. It extends the processing given in Section 5.2 of RFC 4035.
1460 If the validator does not support any of the algorithms listed in an
1461 authenticated DS RRset, then the resolver has no supported
1462 authentication path leading from the parent to the child. The
1463 resolver should treat this case as it would the case of an
1464 authenticated NSEC RRset proving that no DS RRset exists, as
1465 described above.
1466
1467 Note that, for a signed delegation, there are two NSEC RRs associated
1468 with the delegated name. One NSEC RR resides in the parent zone and
1469 can be used to prove whether a DS RRset exists for the delegated
1470 name. The second NSEC RR resides in the child zone and identifies
1471 which RRsets are present at the apex of the child zone. The parent
1472 NSEC RR and child NSEC RR can always be distinguished because the SOA
1473 bit will be set in the child NSEC RR and clear in the parent NSEC RR.
1474 A security-aware resolver MUST use the parent NSEC RR when attempting
1475 to prove that a DS RRset does not exist.
1476
1477
1478
1479
1480
1481
1482 Arends, et al. Standards Track [Page 27]
1483 RFC 4035 DNSSEC Protocol Modifications March 2005
1484
1485
1486 If the resolver does not support any of the algorithms listed in an
1487 authenticated DS RRset, then the resolver will not be able to verify
1488 the authentication path to the child zone. In this case, the
1489 resolver SHOULD treat the child zone as if it were unsigned.
1490
Section 5.2 of RFC6840 says:
In other words, when determining the security status of a zone, a validator disregards any authenticated DS records that specify unknown or unsupported DNSKEY algorithms. If none are left, the zone is treated as if it were unsigned. This document modifies the above text to additionally disregard authenticated DS records using unknown or unsupported message digest algorithms.
1491 5.3. Authenticating an RRset with an RRSIG RR
1492
1493 A validator can use an RRSIG RR and its corresponding DNSKEY RR to
1494 attempt to authenticate RRsets. The validator first checks the RRSIG
1495 RR to verify that it covers the RRset, has a valid time interval, and
1496 identifies a valid DNSKEY RR. The validator then constructs the
1497 canonical form of the signed data by appending the RRSIG RDATA
1498 (excluding the Signature Field) with the canonical form of the
1499 covered RRset. Finally, the validator uses the public key and
1500 signature to authenticate the signed data. Sections 5.3.1, 5.3.2,
1501 and 5.3.3 describe each step in detail.
1502
1503 5.3.1. Checking the RRSIG RR Validity
1504
1505 A security-aware resolver can use an RRSIG RR to authenticate an
1506 RRset if all of the following conditions hold:
1507
1508 o The RRSIG RR and the RRset MUST have the same owner name and the
1509 same class.
1510
1511 o The RRSIG RR's Signer's Name field MUST be the name of the zone
1512 that contains the RRset.
1513
1514 o The RRSIG RR's Type Covered field MUST equal the RRset's type.
1515
1516 o The number of labels in the RRset owner name MUST be greater than
1517 or equal to the value in the RRSIG RR's Labels field.
1518
1519 o The validator's notion of the current time MUST be less than or
1520 equal to the time listed in the RRSIG RR's Expiration field.
1521
1522 o The validator's notion of the current time MUST be greater than or
1523 equal to the time listed in the RRSIG RR's Inception field.
1524
1525 o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
1526 match the owner name, algorithm, and key tag for some DNSKEY RR in
1527 the zone's apex DNSKEY RRset.
1528
1529 o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
1530 RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
1531 set.
1532
1533
1534
1535
1536
1537 Arends, et al. Standards Track [Page 28]
1538 RFC 4035 DNSSEC Protocol Modifications March 2005
1539
1540
1541 It is possible for more than one DNSKEY RR to match the conditions
1542 above. In this case, the validator cannot predetermine which DNSKEY
1543 RR to use to authenticate the signature, and it MUST try each
1544 matching DNSKEY RR until either the signature is validated or the
1545 validator has run out of matching public keys to try.
1546
1547 Note that this authentication process is only meaningful if the
1548 validator authenticates the DNSKEY RR before using it to validate
1549 signatures. The matching DNSKEY RR is considered to be authentic if:
1550
1551 o the apex DNSKEY RRset containing the DNSKEY RR is considered
1552 authentic; or
1553
1554 o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
1555 and the DNSKEY RR either matches an authenticated DS RR from the
1556 parent zone or matches a trust anchor.
1557
1558 5.3.2. Reconstructing the Signed Data
1559
1560 Once the RRSIG RR has met the validity requirements described in
1561 Section 5.3.1, the validator has to reconstruct the original signed
1562 data. The original signed data includes RRSIG RDATA (excluding the
1563 Signature field) and the canonical form of the RRset. Aside from
1564 being ordered, the canonical form of the RRset might also differ from
1565 the received RRset due to DNS name compression, decremented TTLs, or
1566 wildcard expansion. The validator should use the following to
1567 reconstruct the original signed data:
1568
1569 signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
1570
1571 "|" denotes concatenation
1572
1573 RRSIG_RDATA is the wire format of the RRSIG RDATA fields
1574 with the Signature field excluded and the Signer's Name
1575 in canonical form.
1576
1577 RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
1578
1579 name is calculated according to the function below
1580
1581 class is the RRset's class
1582
1583 type is the RRset type and all RRs in the class
1584
1585 OrigTTL is the value from the RRSIG Original TTL field
1586
1587 All names in the RDATA field are in canonical form
1588
1589
1590
1591
1592 Arends, et al. Standards Track [Page 29]
1593 RFC 4035 DNSSEC Protocol Modifications March 2005
1594
1595
1596 The set of all RR(i) is sorted into canonical order.
1597
1598 To calculate the name:
1599 let rrsig_labels = the value of the RRSIG Labels field
1600
1601 let fqdn = RRset's fully qualified domain name in
1602 canonical form
1603
1604 let fqdn_labels = Label count of the fqdn above.
1605
1606 if rrsig_labels = fqdn_labels,
1607 name = fqdn
1608
1609 if rrsig_labels < fqdn_labels,
1610 name = "*." | the rightmost rrsig_label labels of the
1611 fqdn
1612
1613 if rrsig_labels > fqdn_labels
1614 the RRSIG RR did not pass the necessary validation
1615 checks and MUST NOT be used to authenticate this
1616 RRset.
1617
1618 The canonical forms for names and RRsets are defined in [RFC4034].
1619
1620 NSEC RRsets at a delegation boundary require special processing.
1621 There are two distinct NSEC RRsets associated with a signed delegated
1622 name. One NSEC RRset resides in the parent zone, and specifies which
1623 RRsets are present at the parent zone. The second NSEC RRset resides
1624 at the child zone and identifies which RRsets are present at the apex
1625 in the child zone. The parent NSEC RRset and child NSEC RRset can
1626 always be distinguished as only a child NSEC RR will indicate that an
1627 SOA RRset exists at the name. When reconstructing the original NSEC
1628 RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
1629 be combined with NSEC RRs from the child zone. When reconstructing
1630 the original NSEC RRset for the apex of the child zone, the NSEC RRs
1631 MUST NOT be combined with NSEC RRs from the parent zone.
1632
1633 Note that each of the two NSEC RRsets at a delegation point has a
1634 corresponding RRSIG RR with an owner name matching the delegated
1635 name, and each of these RRSIG RRs is authoritative data associated
1636 with the same zone that contains the corresponding NSEC RRset. If
1637 necessary, a resolver can tell these RRSIG RRs apart by checking the
1638 Signer's Name field.
1639
1640
1641
1642
1643
1644
1645
1646
1647 Arends, et al. Standards Track [Page 30]
1648 RFC 4035 DNSSEC Protocol Modifications March 2005
1649
1650
Section 4.2 of RFC6840 says:
[RFC4035] does not address how to validate responses when QTYPE=*. As described in Section 6.2.2 of [RFC1034], a proper response to QTYPE=* may include a subset of the RRsets at a given name. That is, it is not necessary to include all RRsets at the QNAME in the response. When validating a response to QTYPE=*, all received RRsets that match QNAME and QCLASS MUST be validated. If any of those RRsets fail validation, the answer is considered Bogus. If there are no RRsets matching QNAME and QCLASS, that fact MUST be validated according to the rules in Section 5.4 of [RFC4035] (as clarified in this document). To be clear, a validator must not expect to receive all records at the QNAME in response to QTYPE=*.
1651 5.3.3. Checking the Signature
1652
1653 Once the resolver has validated the RRSIG RR as described in Section
1654 5.3.1 and reconstructed the original signed data as described in
1655 Section 5.3.2, the validator can attempt to use the cryptographic
1656 signature to authenticate the signed data, and thus (finally!)
1657 authenticate the RRset.
1658
1659 The Algorithm field in the RRSIG RR identifies the cryptographic
1660 algorithm used to generate the signature. The signature itself is
1661 contained in the Signature field of the RRSIG RDATA, and the public
1662 key used to verify the signature is contained in the Public Key field
1663 of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034]
1664 provides a list of algorithm types and provides pointers to the
1665 documents that define each algorithm's use.
1666
1667 Note that it is possible for more than one DNSKEY RR to match the
1668 conditions in Section 5.3.1. In this case, the validator can only
1669 determine which DNSKEY RR is correct by trying each matching public
1670 key until the validator either succeeds in validating the signature
1671 or runs out of keys to try.
1672
1673 If the Labels field of the RRSIG RR is not equal to the number of
1674 labels in the RRset's fully qualified owner name, then the RRset is
1675 either invalid or the result of wildcard expansion. The resolver
1676 MUST verify that wildcard expansion was applied properly before
1677 considering the RRset to be authentic. Section 5.3.4 describes how
1678 to determine whether a wildcard was applied properly.
1679
1680 If other RRSIG RRs also cover this RRset, the local resolver security
1681 policy determines whether the resolver also has to test these RRSIG
1682 RRs and how to resolve conflicts if these RRSIG RRs lead to differing
1683 results.
1684
1685 If the resolver accepts the RRset as authentic, the validator MUST
1686 set the TTL of the RRSIG RR and each RR in the authenticated RRset to
1687 a value no greater than the minimum of:
1688
1689 o the RRset's TTL as received in the response;
1690
1691 o the RRSIG RR's TTL as received in the response;
1692
1693 o the value in the RRSIG RR's Original TTL field; and
1694
1695 o the difference of the RRSIG RR's Signature Expiration time and the
1696 current time.
1697
1698
1699
1700
1701
1702 Arends, et al. Standards Track [Page 31]
1703 RFC 4035 DNSSEC Protocol Modifications March 2005
1704
1705
1706 5.3.4. Authenticating a Wildcard Expanded RRset Positive Response
1707
1708 If the number of labels in an RRset's owner name is greater than the
1709 Labels field of the covering RRSIG RR, then the RRset and its
1710 covering RRSIG RR were created as a result of wildcard expansion.
1711 Once the validator has verified the signature, as described in
1712 Section 5.3, it must take additional steps to verify the non-
1713 existence of an exact match or closer wildcard match for the query.
1714 Section 5.4 discusses these steps.
1715
1716 Note that the response received by the resolver should include all
1717 NSEC RRs needed to authenticate the response (see Section 3.1.3).
1718
Section 5.4 of RFC6840 says:
When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035] suggests that "the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results". This document specifies that a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation. If a resolver adopts a more restrictive policy, there's a danger that properly signed data might unnecessarily fail validation due to cache timing issues. Furthermore, certain zone management techniques, like the Double Signature Zone Signing Key Rollover method described in Section 4.2.1.2 of [RFC6781], will not work reliably. Such a resolver is also vulnerable to malicious insertion of gibberish signatures.
1719 5.4. Authenticated Denial of Existence
1720
1721 A resolver can use authenticated NSEC RRs to prove that an RRset is
1722 not present in a signed zone. Security-aware name servers should
1723 automatically include any necessary NSEC RRs for signed zones in
1724 their responses to security-aware resolvers.
1725
1726 Denial of existence is determined by the following rules:
1727
1728 o If the requested RR name matches the owner name of an
1729 authenticated NSEC RR, then the NSEC RR's type bit map field lists
1730 all RR types present at that owner name, and a resolver can prove
1731 that the requested RR type does not exist by checking for the RR
1732 type in the bit map. If the number of labels in an authenticated
1733 NSEC RR's owner name equals the Labels field of the covering RRSIG
1734 RR, then the existence of the NSEC RR proves that wildcard
1735 expansion could not have been used to match the request.
1736
1737 o If the requested RR name would appear after an authenticated NSEC
1738 RR's owner name and before the name listed in that NSEC RR's Next
1739 Domain Name field according to the canonical DNS name order
1740 defined in [RFC4034], then no RRsets with the requested name exist
1741 in the zone. However, it is possible that a wildcard could be
1742 used to match the requested RR owner name and type, so proving
1743 that the requested RRset does not exist also requires proving that
1744 no possible wildcard RRset exists that could have been used to
1745 generate a positive response.
1746
1747 In addition, security-aware resolvers MUST authenticate the NSEC
1748 RRsets that comprise the non-existence proof as described in Section
1749 5.3.
1750
1751 To prove the non-existence of an RRset, the resolver must be able to
1752 verify both that the queried RRset does not exist and that no
1753 relevant wildcard RRset exists. Proving this may require more than
1754
1755
1756
1757 Arends, et al. Standards Track [Page 32]
1758 RFC 4035 DNSSEC Protocol Modifications March 2005
1759
1760
1761 one NSEC RRset from the zone. If the complete set of necessary NSEC
1762 RRsets is not present in a response (perhaps due to message
1763 truncation), then a security-aware resolver MUST resend the query in
1764 order to attempt to obtain the full collection of NSEC RRs necessary
1765 to verify the non-existence of the requested RRset. As with all DNS
1766 operations, however, the resolver MUST bound the work it puts into
1767 answering any particular query.
1768
1769 Since a validated NSEC RR proves the existence of both itself and its
1770 corresponding RRSIG RR, a validator MUST ignore the settings of the
1771 NSEC and RRSIG bits in an NSEC RR.
1772
1773 5.5. Resolver Behavior When Signatures Do Not Validate
1774
1775 If for whatever reason none of the RRSIGs can be validated, the
1776 response SHOULD be considered BAD. If the validation was being done
1777 to service a recursive query, the name server MUST return RCODE 2 to
1778 the originating client. However, it MUST return the full response if
1779 and only if the original query had the CD bit set. Also see Section
1780 4.7 on caching responses that do not validate.
1781
1782 5.6. Authentication Example
1783
1784 Appendix C shows an example of the authentication process.
1785
1786 6. IANA Considerations
1787
1788 [RFC4034] contains a review of the IANA considerations introduced by
1789 DNSSEC. The following are additional IANA considerations discussed
1790 in this document:
1791
1792 [RFC2535] reserved the CD and AD bits in the message header. The
1793 meaning of the AD bit was redefined in [RFC3655], and the meaning of
1794 both the CD and AD bit are restated in this document. No new bits in
1795 the DNS message header are defined in this document.
1796
1797 [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
1798 and defined its use. The use is restated but not altered in this
1799 document.
1800
1801 7. Security Considerations
1802
1803 This document describes how the DNS security extensions use public
1804 key cryptography to sign and authenticate DNS resource record sets.
1805 Please see [RFC4033] for terminology and general security
1806 considerations related to DNSSEC; see [RFC4034] for considerations
1807 specific to the DNSSEC resource record types.
1808
1809
1810
1811
1812 Arends, et al. Standards Track [Page 33]
1813 RFC 4035 DNSSEC Protocol Modifications March 2005
1814
1815
1816 An active attacker who can set the CD bit in a DNS query message or
1817 the AD bit in a DNS response message can use these bits to defeat the
1818 protection that DNSSEC attempts to provide to security-oblivious
1819 recursive-mode resolvers. For this reason, use of these control bits
1820 by a security-aware recursive-mode resolver requires a secure
1821 channel. See Sections 3.2.2 and 4.9 for further discussion.
1822
1823 The protocol described in this document attempts to extend the
1824 benefits of DNSSEC to security-oblivious stub resolvers. However, as
1825 recovery from validation failures is likely to be specific to
1826 particular applications, the facilities that DNSSEC provides for stub
1827 resolvers may prove inadequate. Operators of security-aware
1828 recursive name servers will have to pay close attention to the
1829 behavior of the applications that use their services when choosing a
1830 local validation policy; failure to do so could easily result in the
1831 recursive name server accidentally denying service to the clients it
1832 is intended to support.
1833
1834 8. Acknowledgements
1835
1836 This document was created from the input and ideas of the members of
1837 the DNS Extensions Working Group and working group mailing list. The
1838 editors would like to express their thanks for the comments and
1839 suggestions received during the revision of these security extension
1840 specifications. Although explicitly listing everyone who has
1841 contributed during the decade in which DNSSEC has been under
1842 development would be impossible, [RFC4033] includes a list of some of
1843 the participants who were kind enough to comment on these documents.
1844
1845 9. References
1846
1847 9.1. Normative References
1848
1849 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1850 STD 13, RFC 1034, November 1987.
1851
1852 [RFC1035] Mockapetris, P., "Domain names - implementation and
1853 specification", STD 13, RFC 1035, November 1987.
1854
1855 [RFC1122] Braden, R., "Requirements for Internet Hosts -
1856 Communication Layers", STD 3, RFC 1122, October 1989.
1857
1858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1859 Requirement Levels", BCP 14, RFC 2119, March 1997.
1860
1861 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1862 Specification", RFC 2181, July 1997.
1863
1864
1865
1866
1867 Arends, et al. Standards Track [Page 34]
1868 RFC 4035 DNSSEC Protocol Modifications March 2005
1869
1870
1871 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1872 (IPv6) Specification", RFC 2460, December 1998.
1873
1874 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
1875 2671, August 1999.
1876
1877 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
1878 2672, August 1999.
1879
1880 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
1881 3225, December 2001.
1882
1883 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
1884 message size requirements", RFC 3226, December 2001.
1885
1886 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1887 Rose, "DNS Security Introduction and Requirements", RFC
1888 4033, March 2005.
1889
1890 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1891 Rose, "Resource Records for DNS Security Extensions", RFC
1892 4034, March 2005.
1893
1894 9.2. Informative References
1895
1896 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1897 NCACHE)", RFC 2308, March 1998.
1898
1899 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
1900 Extensions", RFC 2535, March 1999.
1901
1902 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
1903 Update", RFC 3007, November 2000.
1904
1905 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
1906 Authenticated Data (AD) bit", RFC 3655, November 2003.
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922 Arends, et al. Standards Track [Page 35]
1923 RFC 4035 DNSSEC Protocol Modifications March 2005
1924
1925
1926 Appendix A. Signed Zone Example
1927
1928 The following example shows a (small) complete signed zone.
1929
1930 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1931 1081539377
1932 3600
1933 300
1934 3600000
1935 3600
1936 )
1937 3600 RRSIG SOA 5 1 3600 20040509183619 (
1938 20040409183619 38519 example.
1939 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
1940 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
1941 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
1942 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
1943 jV7j86HyQgM5e7+miRAz8V01b0I= )
1944 3600 NS ns1.example.
1945 3600 NS ns2.example.
1946 3600 RRSIG NS 5 1 3600 20040509183619 (
1947 20040409183619 38519 example.
1948 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
1949 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
1950 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
1951 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
1952 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
1953 3600 MX 1 xx.example.
1954 3600 RRSIG MX 5 1 3600 20040509183619 (
1955 20040409183619 38519 example.
1956 HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
1957 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
1958 VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
1959 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
1960 W6OISukd1EQt7a0kygkg+PEDxdI= )
1961 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
1962 3600 RRSIG NSEC 5 1 3600 20040509183619 (
1963 20040409183619 38519 example.
1964 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
1965 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
1966 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
1967 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
1968 jfFJ5arXf4nPxp/kEowGgBRzY/U= )
1969 3600 DNSKEY 256 3 5 (
1970 AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
1971 rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
1972 k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
1973 vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
1974
1975
1976
1977 Arends, et al. Standards Track [Page 36]
1978 RFC 4035 DNSSEC Protocol Modifications March 2005
1979
1980
1981 ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
1982 )
1983 3600 DNSKEY 257 3 5 (
1984 AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
1985 LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
1986 syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
1987 RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
1988 Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
1989 )
1990 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
1991 20040409183619 9465 example.
1992 ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
1993 xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
1994 XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
1995 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
1996 NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
1997 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
1998 20040409183619 38519 example.
1999 eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
2000 DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
2001 bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
2002 eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
2003 7z5OXogYVaFzHKillDt3HRxHIZM= )
2004 a.example. 3600 IN NS ns1.a.example.
2005 3600 IN NS ns2.a.example.
2006 3600 DS 57855 5 1 (
2007 B6DCD485719ADCA18E5F3D48A2331627FDD3
2008 636B )
2009 3600 RRSIG DS 5 2 3600 20040509183619 (
2010 20040409183619 38519 example.
2011 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
2012 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
2013 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
2014 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
2015 Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
2016 3600 NSEC ai.example. NS DS RRSIG NSEC
2017 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2018 20040409183619 38519 example.
2019 cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
2020 U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
2021 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
2022 BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
2023 sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
2024 ns1.a.example. 3600 IN A 192.0.2.5
2025 ns2.a.example. 3600 IN A 192.0.2.6
2026 ai.example. 3600 IN A 192.0.2.9
2027 3600 RRSIG A 5 2 3600 20040509183619 (
2028 20040409183619 38519 example.
2029
2030
2031
2032 Arends, et al. Standards Track [Page 37]
2033 RFC 4035 DNSSEC Protocol Modifications March 2005
2034
2035
2036 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
2037 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
2038 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
2039 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
2040 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
2041 3600 HINFO "KLH-10" "ITS"
2042 3600 RRSIG HINFO 5 2 3600 20040509183619 (
2043 20040409183619 38519 example.
2044 Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
2045 e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
2046 ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
2047 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
2048 FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
2049 3600 AAAA 2001:db8::f00:baa9
2050 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2051 20040409183619 38519 example.
2052 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
2053 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
2054 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
2055 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
2056 sZM6QjBBLmukH30+w1z3h8PUP2o= )
2057 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
2058 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2059 20040409183619 38519 example.
2060 QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
2061 CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
2062 P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
2063 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
2064 AhS+JOVfDI/79QtyTI0SaDWcg8U= )
2065 b.example. 3600 IN NS ns1.b.example.
2066 3600 IN NS ns2.b.example.
2067 3600 NSEC ns1.example. NS RRSIG NSEC
2068 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2069 20040409183619 38519 example.
2070 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
2071 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
2072 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
2073 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
2074 vhRXgWT7OuFXldoCG6TfVFMs9xE= )
2075 ns1.b.example. 3600 IN A 192.0.2.7
2076 ns2.b.example. 3600 IN A 192.0.2.8
2077 ns1.example. 3600 IN A 192.0.2.1
2078 3600 RRSIG A 5 2 3600 20040509183619 (
2079 20040409183619 38519 example.
2080 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
2081 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
2082 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
2083 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
2084
2085
2086
2087 Arends, et al. Standards Track [Page 38]
2088 RFC 4035 DNSSEC Protocol Modifications March 2005
2089
2090
2091 v/iVXSYC0b7mPSU+EOlknFpVECs= )
2092 3600 NSEC ns2.example. A RRSIG NSEC
2093 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2094 20040409183619 38519 example.
2095 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
2096 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
2097 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
2098 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
2099 IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
2100 ns2.example. 3600 IN A 192.0.2.2
2101 3600 RRSIG A 5 2 3600 20040509183619 (
2102 20040409183619 38519 example.
2103 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
2104 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
2105 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
2106 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
2107 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
2108 3600 NSEC *.w.example. A RRSIG NSEC
2109 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2110 20040409183619 38519 example.
2111 N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
2112 VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
2113 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
2114 l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
2115 Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
2116 *.w.example. 3600 IN MX 1 ai.example.
2117 3600 RRSIG MX 5 2 3600 20040509183619 (
2118 20040409183619 38519 example.
2119 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
2120 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
2121 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
2122 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
2123 4kX18MMR34i8lC36SR5xBni8vHI= )
2124 3600 NSEC x.w.example. MX RRSIG NSEC
2125 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2126 20040409183619 38519 example.
2127 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
2128 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
2129 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
2130 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
2131 s1InQ2UoIv6tJEaaKkP701j8OLA= )
2132 x.w.example. 3600 IN MX 1 xx.example.
2133 3600 RRSIG MX 5 3 3600 20040509183619 (
2134 20040409183619 38519 example.
2135 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
2136 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
2137 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
2138 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
2139
2140
2141
2142 Arends, et al. Standards Track [Page 39]
2143 RFC 4035 DNSSEC Protocol Modifications March 2005
2144
2145
2146 jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
2147 3600 NSEC x.y.w.example. MX RRSIG NSEC
2148 3600 RRSIG NSEC 5 3 3600 20040509183619 (
2149 20040409183619 38519 example.
2150 aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
2151 vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
2152 mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
2153 NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
2154 IjgiM8PXkBQtxPq37wDKALkyn7Q= )
2155 x.y.w.example. 3600 IN MX 1 xx.example.
2156 3600 RRSIG MX 5 4 3600 20040509183619 (
2157 20040409183619 38519 example.
2158 k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
2159 t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
2160 q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
2161 GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
2162 +gLcMZBnHJ326nb/TOOmrqNmQQE= )
2163 3600 NSEC xx.example. MX RRSIG NSEC
2164 3600 RRSIG NSEC 5 4 3600 20040509183619 (
2165 20040409183619 38519 example.
2166 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
2167 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
2168 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
2169 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
2170 QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
2171 xx.example. 3600 IN A 192.0.2.10
2172 3600 RRSIG A 5 2 3600 20040509183619 (
2173 20040409183619 38519 example.
2174 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
2175 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
2176 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
2177 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
2178 kbIDV6GPPSZVusnZU6OMgdgzHV4= )
2179 3600 HINFO "KLH-10" "TOPS-20"
2180 3600 RRSIG HINFO 5 2 3600 20040509183619 (
2181 20040409183619 38519 example.
2182 GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
2183 t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
2184 BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
2185 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
2186 RgNvuwbioFSEuv2pNlkq0goYxNY= )
2187 3600 AAAA 2001:db8::f00:baaa
2188 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2189 20040409183619 38519 example.
2190 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
2191 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
2192 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
2193 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
2194
2195
2196
2197 Arends, et al. Standards Track [Page 40]
2198 RFC 4035 DNSSEC Protocol Modifications March 2005
2199
2200
2201 xS9cL2QgW7FChw16mzlkH6/vsfs= )
2202 3600 NSEC example. A HINFO AAAA RRSIG NSEC
2203 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2204 20040409183619 38519 example.
2205 ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
2206 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
2207 mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
2208 asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
2209 GghLahumFIpg4MO3LS/prgzVVWo= )
2210
2211 The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
2212 Flags indicate that each of these DNSKEY RRs is a zone key. One of
2213 these DNSKEY RRs also has the SEP flag set and has been used to sign
2214 the apex DNSKEY RRset; this is the key that should be hashed to
2215 generate a DS record to be inserted into the parent zone. The other
2216 DNSKEY is used to sign all the other RRsets in the zone.
2217
2218 The zone includes a wildcard entry, "*.w.example". Note that the
2219 name "*.w.example" is used in constructing NSEC chains, and that the
2220 RRSIG covering the "*.w.example" MX RRset has a label count of 2.
2221
2222 The zone also includes two delegations. The delegation to
2223 "b.example" includes an NS RRset, glue address records, and an NSEC
2224 RR; note that only the NSEC RRset is signed. The delegation to
2225 "a.example" provides a DS RR; note that only the NSEC and DS RRsets
2226 are signed.
2227
2228 Appendix B. Example Responses
2229
2230 The examples in this section show response messages using the signed
2231 zone example in Appendix A.
2232
2233 B.1. Answer
2234
2235 A successful query to an authoritative server.
2236
2237 ;; Header: QR AA DO RCODE=0
2238 ;;
2239 ;; Question
2240 x.w.example. IN MX
2241
2242 ;; Answer
2243 x.w.example. 3600 IN MX 1 xx.example.
2244 x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
2245 20040409183619 38519 example.
2246 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
2247 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
2248 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
2249
2250
2251
2252 Arends, et al. Standards Track [Page 41]
2253 RFC 4035 DNSSEC Protocol Modifications March 2005
2254
2255
2256 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
2257 jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
2258
2259 ;; Authority
2260 example. 3600 NS ns1.example.
2261 example. 3600 NS ns2.example.
2262 example. 3600 RRSIG NS 5 1 3600 20040509183619 (
2263 20040409183619 38519 example.
2264 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
2265 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
2266 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
2267 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
2268 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
2269
2270 ;; Additional
2271 xx.example. 3600 IN A 192.0.2.10
2272 xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2273 20040409183619 38519 example.
2274 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
2275 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
2276 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
2277 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
2278 kbIDV6GPPSZVusnZU6OMgdgzHV4= )
2279 xx.example. 3600 AAAA 2001:db8::f00:baaa
2280 xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2281 20040409183619 38519 example.
2282 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
2283 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
2284 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
2285 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
2286 xS9cL2QgW7FChw16mzlkH6/vsfs= )
2287 ns1.example. 3600 IN A 192.0.2.1
2288 ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2289 20040409183619 38519 example.
2290 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
2291 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
2292 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
2293 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
2294 v/iVXSYC0b7mPSU+EOlknFpVECs= )
2295 ns2.example. 3600 IN A 192.0.2.2
2296 ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2297 20040409183619 38519 example.
2298 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
2299 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
2300 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
2301 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
2302 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
2303
2304
2305
2306
2307 Arends, et al. Standards Track [Page 42]
2308 RFC 4035 DNSSEC Protocol Modifications March 2005
2309
2310
2311 B.2. Name Error
2312
2313 An authoritative name error. The NSEC RRs prove that the name does
2314 not exist and that no covering wildcard exists.
2315
2316 ;; Header: QR AA DO RCODE=3
2317 ;;
2318 ;; Question
2319 ml.example. IN A
2320
2321 ;; Answer
2322 ;; (empty)
2323
2324 ;; Authority
2325 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2326 1081539377
2327 3600
2328 300
2329 3600000
2330 3600
2331 )
2332 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2333 20040409183619 38519 example.
2334 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2335 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2336 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2337 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2338 jV7j86HyQgM5e7+miRAz8V01b0I= )
2339 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
2340 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2341 20040409183619 38519 example.
2342 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
2343 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
2344 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
2345 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
2346 vhRXgWT7OuFXldoCG6TfVFMs9xE= )
2347 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
2348 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
2349 20040409183619 38519 example.
2350 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
2351 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
2352 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
2353 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
2354 jfFJ5arXf4nPxp/kEowGgBRzY/U= )
2355
2356 ;; Additional
2357 ;; (empty)
2358
2359
2360
2361
2362 Arends, et al. Standards Track [Page 43]
2363 RFC 4035 DNSSEC Protocol Modifications March 2005
2364
2365
2366 B.3. No Data Error
2367
2368 A "no data" response. The NSEC RR proves that the name exists and
2369 that the requested RR type does not.
2370
2371 ;; Header: QR AA DO RCODE=0
2372 ;;
2373 ;; Question
2374 ns1.example. IN MX
2375
2376 ;; Answer
2377 ;; (empty)
2378
2379 ;; Authority
2380 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2381 1081539377
2382 3600
2383 300
2384 3600000
2385 3600
2386 )
2387 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2388 20040409183619 38519 example.
2389 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2390 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2391 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2392 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2393 jV7j86HyQgM5e7+miRAz8V01b0I= )
2394 ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
2395 ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2396 20040409183619 38519 example.
2397 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
2398 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
2399 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
2400 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
2401 IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
2402
2403 ;; Additional
2404 ;; (empty)
2405
2406 B.4. Referral to Signed Zone
2407
2408 Referral to a signed zone. The DS RR contains the data which the
2409 resolver will need to validate the corresponding DNSKEY RR in the
2410 child zone's apex.
2411
2412 ;; Header: QR DO RCODE=0
2413 ;;
2414
2415
2416
2417 Arends, et al. Standards Track [Page 44]
2418 RFC 4035 DNSSEC Protocol Modifications March 2005
2419
2420
2421 ;; Question
2422 mc.a.example. IN MX
2423
2424 ;; Answer
2425 ;; (empty)
2426
2427 ;; Authority
2428 a.example. 3600 IN NS ns1.a.example.
2429 a.example. 3600 IN NS ns2.a.example.
2430 a.example. 3600 DS 57855 5 1 (
2431 B6DCD485719ADCA18E5F3D48A2331627FDD3
2432 636B )
2433 a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
2434 20040409183619 38519 example.
2435 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
2436 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
2437 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
2438 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
2439 Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
2440
2441 ;; Additional
2442 ns1.a.example. 3600 IN A 192.0.2.5
2443 ns2.a.example. 3600 IN A 192.0.2.6
2444
2445 B.5. Referral to Unsigned Zone
2446
2447 Referral to an unsigned zone. The NSEC RR proves that no DS RR for
2448 this delegation exists in the parent zone.
2449
2450 ;; Header: QR DO RCODE=0
2451 ;;
2452 ;; Question
2453 mc.b.example. IN MX
2454
2455 ;; Answer
2456 ;; (empty)
2457
2458 ;; Authority
2459 b.example. 3600 IN NS ns1.b.example.
2460 b.example. 3600 IN NS ns2.b.example.
2461 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
2462 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2463 20040409183619 38519 example.
2464 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
2465 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
2466 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
2467 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
2468 vhRXgWT7OuFXldoCG6TfVFMs9xE= )
2469
2470
2471
2472 Arends, et al. Standards Track [Page 45]
2473 RFC 4035 DNSSEC Protocol Modifications March 2005
2474
2475
2476 ;; Additional
2477 ns1.b.example. 3600 IN A 192.0.2.7
2478 ns2.b.example. 3600 IN A 192.0.2.8
2479
2480 B.6. Wildcard Expansion
2481
2482 A successful query that was answered via wildcard expansion. The
2483 label count in the answer's RRSIG RR indicates that a wildcard RRset
2484 was expanded to produce this response, and the NSEC RR proves that no
2485 closer match exists in the zone.
2486
2487 ;; Header: QR AA DO RCODE=0
2488 ;;
2489 ;; Question
2490 a.z.w.example. IN MX
2491
2492 ;; Answer
2493 a.z.w.example. 3600 IN MX 1 ai.example.
2494 a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
2495 20040409183619 38519 example.
2496 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
2497 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
2498 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
2499 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
2500 4kX18MMR34i8lC36SR5xBni8vHI= )
2501
2502 ;; Authority
2503 example. 3600 NS ns1.example.
2504 example. 3600 NS ns2.example.
2505 example. 3600 RRSIG NS 5 1 3600 20040509183619 (
2506 20040409183619 38519 example.
2507 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
2508 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
2509 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
2510 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
2511 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
2512 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
2513 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
2514 20040409183619 38519 example.
2515 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
2516 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
2517 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
2518 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
2519 QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
2520
2521 ;; Additional
2522 ai.example. 3600 IN A 192.0.2.9
2523 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2524
2525
2526
2527 Arends, et al. Standards Track [Page 46]
2528 RFC 4035 DNSSEC Protocol Modifications March 2005
2529
2530
2531 20040409183619 38519 example.
2532 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
2533 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
2534 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
2535 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
2536 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
2537 ai.example. 3600 AAAA 2001:db8::f00:baa9
2538 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2539 20040409183619 38519 example.
2540 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
2541 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
2542 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
2543 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
2544 sZM6QjBBLmukH30+w1z3h8PUP2o= )
2545
2546 B.7. Wildcard No Data Error
2547
2548 A "no data" response for a name covered by a wildcard. The NSEC RRs
2549 prove that the matching wildcard name does not have any RRs of the
2550 requested type and that no closer match exists in the zone.
2551
2552 ;; Header: QR AA DO RCODE=0
2553 ;;
2554 ;; Question
2555 a.z.w.example. IN AAAA
2556
2557 ;; Answer
2558 ;; (empty)
2559
2560 ;; Authority
2561 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2562 1081539377
2563 3600
2564 300
2565 3600000
2566 3600
2567 )
2568 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2569 20040409183619 38519 example.
2570 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2571 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2572 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2573 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2574 jV7j86HyQgM5e7+miRAz8V01b0I= )
2575 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
2576 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
2577 20040409183619 38519 example.
2578 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
2579
2580
2581
2582 Arends, et al. Standards Track [Page 47]
2583 RFC 4035 DNSSEC Protocol Modifications March 2005
2584
2585
2586 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
2587 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
2588 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
2589 QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
2590 *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
2591 *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2592 20040409183619 38519 example.
2593 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
2594 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
2595 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
2596 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
2597 s1InQ2UoIv6tJEaaKkP701j8OLA= )
2598
2599 ;; Additional
2600 ;; (empty)
2601
2602 B.8. DS Child Zone No Data Error
2603
2604 A "no data" response for a QTYPE=DS query that was mistakenly sent to
2605 a name server for the child zone.
2606
2607 ;; Header: QR AA DO RCODE=0
2608 ;;
2609 ;; Question
2610 example. IN DS
2611
2612 ;; Answer
2613 ;; (empty)
2614
2615 ;; Authority
2616 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2617 1081539377
2618 3600
2619 300
2620 3600000
2621 3600
2622 )
2623 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2624 20040409183619 38519 example.
2625 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2626 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2627 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2628 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2629 jV7j86HyQgM5e7+miRAz8V01b0I= )
2630 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
2631 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
2632 20040409183619 38519 example.
2633 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
2634
2635
2636
2637 Arends, et al. Standards Track [Page 48]
2638 RFC 4035 DNSSEC Protocol Modifications March 2005
2639
2640
2641 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
2642 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
2643 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
2644 jfFJ5arXf4nPxp/kEowGgBRzY/U= )
2645
2646 ;; Additional
2647 ;; (empty)
2648
2649 Appendix C. Authentication Examples
2650
2651 The examples in this section show how the response messages in
2652 Appendix B are authenticated.
2653
Section 4.1 of RFC6840 says:
Section 5.4 of [RFC4035] under-specifies the algorithm for checking nonexistence proofs. In particular, the algorithm as presented would allow a validator to interpret an NSEC or NSEC3 RR from an ancestor zone as proving the nonexistence of an RR in a child zone. An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: o the NS bit set, o the Start of Authority (SOA) bit clear, and o a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR. Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut, which include all RRs at that (original) owner name other than DS RRs, and all RRs below that owner name regardless of type. Similarly, the algorithm would also allow an NSEC RR at the same owner name as a DNAME RR, or an NSEC3 RR at the same original owner name as a DNAME, to prove the nonexistence of names beneath that DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's (original) owner name.
2654 C.1. Authenticating an Answer
2655
2656 The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
2657 The corresponding RRSIG indicates that the MX RRset was signed by an
2658 "example" DNSKEY with algorithm 5 and key tag 38519. The resolver
2659 needs the corresponding DNSKEY RR in order to authenticate this
2660 answer. The discussion below describes how a resolver might obtain
2661 this DNSKEY RR.
2662
2663 The RRSIG indicates the original TTL of the MX RRset was 3600, and,
2664 for the purpose of authentication, the current TTL is replaced by
2665 3600. The RRSIG labels field value of 3 indicates that the answer
2666 was not the result of wildcard expansion. The "x.w.example.com" MX
2667 RRset is placed in canonical form, and, assuming the current time
2668 falls between the signature inception and expiration dates, the
2669 signature is authenticated.
2670
2671 C.1.1. Authenticating the Example DNSKEY RR
2672
2673 This example shows the logical authentication process that starts
2674 from the a configured root DNSKEY (or DS RR) and moves down the tree
2675 to authenticate the desired "example" DNSKEY RR. Note that the
2676 logical order is presented for clarity. An implementation may choose
2677 to construct the authentication as referrals are received or to
2678 construct the authentication chain only after all RRsets have been
2679 obtained, or in any other combination it sees fit. The example here
2680 demonstrates only the logical process and does not dictate any
2681 implementation rules.
2682
2683 We assume the resolver starts with a configured DNSKEY RR for the
2684 root zone (or a configured DS RR for the root zone). The resolver
2685 checks whether this configured DNSKEY RR is present in the root
2686 DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
2687 DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
2688 RRset, and whether the signature lifetime is valid. If all these
2689
2690
2691
2692 Arends, et al. Standards Track [Page 49]
2693 RFC 4035 DNSSEC Protocol Modifications March 2005
2694
2695
2696 conditions are met, all keys in the DNSKEY RRset are considered
2697 authenticated. The resolver then uses one (or more) of the root
2698 DNSKEY RRs to authenticate the "example" DS RRset. Note that the
2699 resolver may have to query the root zone to obtain the root DNSKEY
2700 RRset or "example" DS RRset.
2701
2702 Once the DS RRset has been authenticated using the root DNSKEY, the
2703 resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
2704 RR that matches one of the authenticated "example" DS RRs. If such a
2705 matching "example" DNSKEY is found, the resolver checks whether this
2706 DNSKEY RR has signed the "example" DNSKEY RRset and the signature
2707 lifetime is valid. If these conditions are met, all keys in the
2708 "example" DNSKEY RRset are considered authenticated.
2709
2710 Finally, the resolver checks that some DNSKEY RR in the "example"
2711 DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
2712 DNSKEY is used to authenticate the RRSIG included in the response.
2713 If multiple "example" DNSKEY RRs match this algorithm and key tag,
2714 then each DNSKEY RR is tried, and the answer is authenticated if any
2715 of the matching DNSKEY RRs validate the signature as described above.
2716
2717 C.2. Name Error
2718
2719 The query in Appendix B.2 returned NSEC RRs that prove that the
2720 requested data does not exist and no wildcard applies. The negative
2721 reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
2722 authenticated in a manner identical to that of the MX RRset discussed
2723 above.
2724
2725 C.3. No Data Error
2726
2727 The query in Appendix B.3 returned an NSEC RR that proves that the
2728 requested name exists, but the requested RR type does not exist. The
2729 negative reply is authenticated by verifying the NSEC RR. The NSEC
2730 RR is authenticated in a manner identical to that of the MX RRset
2731 discussed above.
2732
2733 C.4. Referral to Signed Zone
2734
2735 The query in Appendix B.4 returned a referral to the signed
2736 "a.example." zone. The DS RR is authenticated in a manner identical
2737 to that of the MX RRset discussed above. This DS RR is used to
2738 authenticate the "a.example" DNSKEY RRset.
2739
2740 Once the "a.example" DS RRset has been authenticated using the
2741 "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
2742 for some "a.example" DNSKEY RR that matches the DS RR. If such a
2743 matching "a.example" DNSKEY is found, the resolver checks whether
2744
2745
2746
2747 Arends, et al. Standards Track [Page 50]
2748 RFC 4035 DNSSEC Protocol Modifications March 2005
2749
2750
2751 this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
2752 the signature lifetime is valid. If all these conditions are met,
2753 all keys in the "a.example" DNSKEY RRset are considered
2754 authenticated.
2755
2756 C.5. Referral to Unsigned Zone
2757
2758 The query in Appendix B.5 returned a referral to an unsigned
2759 "b.example." zone. The NSEC proves that no authentication leads from
2760 "example" to "b.example", and the NSEC RR is authenticated in a
2761 manner identical to that of the MX RRset discussed above.
2762
Section 6.3 of RFC6840 says:
The text in Appendix C.1 of [RFC4035] refers to the examples in Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example". This is painfully obvious in the second paragraph where it states that the RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. This is true for "x.w.example" but not for "x.w.example.com", which of course has a label count of 4 (antithetically, a label count of 3 would imply the answer was the result of a wildcard expansion).
2763 C.6. Wildcard Expansion
2764
2765 The query in Appendix B.6 returned an answer that was produced as a
2766 result of wildcard expansion. The answer section contains a wildcard
2767 RRset expanded as it would be in a traditional DNS response, and the
2768 corresponding RRSIG indicates that the expanded wildcard MX RRset was
2769 signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
2770 The RRSIG indicates that the original TTL of the MX RRset was 3600,
2771 and, for the purpose of authentication, the current TTL is replaced
2772 by 3600. The RRSIG labels field value of 2 indicates that the answer
2773 is the result of wildcard expansion, as the "a.z.w.example" name
2774 contains 4 labels. The name "a.z.w.w.example" is replaced by
2775 "*.w.example", the MX RRset is placed in canonical form, and,
2776 assuming that the current time falls between the signature inception
2777 and expiration dates, the signature is authenticated.
2778
2779 The NSEC proves that no closer match (exact or closer wildcard) could
2780 have been used to answer this query, and the NSEC RR must also be
2781 authenticated before the answer is considered valid.
2782
2783 C.7. Wildcard No Data Error
2784
2785 The query in Appendix B.7 returned NSEC RRs that prove that the
2786 requested data does not exist and no wildcard applies. The negative
2787 reply is authenticated by verifying both NSEC RRs.
2788
Section 6.3 of RFC6840 says:
The first paragraph of Appendix C.6 of [RFC4035] also has a minor error: the reference to "a.z.w.w.example" should instead be "a.z.w.example", as in the previous line.
2789 C.8. DS Child Zone No Data Error
2790
2791 The query in Appendix B.8 returned NSEC RRs that shows the requested
2792 was answered by a child server ("example" server). The NSEC RR
2793 indicates the presence of an SOA RR, showing that the answer is from
2794 the child . Queries for the "example" DS RRset should be sent to the
2795 parent servers ("root" servers).
2796
2797
2798
2799
2800
2801
2802 Arends, et al. Standards Track [Page 51]
2803 RFC 4035 DNSSEC Protocol Modifications March 2005
2804
2805
2806 Authors' Addresses
2807
2808 Roy Arends
2809 Telematica Instituut
2810 Brouwerijstraat 1
2811 7523 XC Enschede
2812 NL
2813
2814 EMail: roy.arends@telin.nl
2815
2816
2817 Rob Austein
2818 Internet Systems Consortium
2819 950 Charter Street
2820 Redwood City, CA 94063
2821 USA
2822
2823 EMail: sra@isc.org
2824
2825
2826 Matt Larson
2827 VeriSign, Inc.
2828 21345 Ridgetop Circle
2829 Dulles, VA 20166-6503
2830 USA
2831
2832 EMail: mlarson@verisign.com
2833
2834
2835 Dan Massey
2836 Colorado State University
2837 Department of Computer Science
2838 Fort Collins, CO 80523-1873
2839
2840 EMail: massey@cs.colostate.edu
2841
2842
2843 Scott Rose
2844 National Institute for Standards and Technology
2845 100 Bureau Drive
2846 Gaithersburg, MD 20899-8920
2847 USA
2848
2849 EMail: scott.rose@nist.gov
2850
2851
2852
2853
2854
2855
2856
2857 Arends, et al. Standards Track [Page 52]
2858 RFC 4035 DNSSEC Protocol Modifications March 2005
2859
2860
2861 Full Copyright Statement
2862
2863 Copyright (C) The Internet Society (2005).
2864
2865 This document is subject to the rights, licenses and restrictions
2866 contained in BCP 78, and except as set forth therein, the authors
2867 retain all their rights.
2868
2869 This document and the information contained herein are provided on an
2870 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2871 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2872 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2873 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2874 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2875 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2876
2877 Intellectual Property
2878
2879 The IETF takes no position regarding the validity or scope of any
2880 Intellectual Property Rights or other rights that might be claimed to
2881 pertain to the implementation or use of the technology described in
2882 this document or the extent to which any license under such rights
2883 might or might not be available; nor does it represent that it has
2884 made any independent effort to identify any such rights. Information
2885 on the procedures with respect to rights in RFC documents can be
2886 found in BCP 78 and BCP 79.
2887
2888 Copies of IPR disclosures made to the IETF Secretariat and any
2889 assurances of licenses to be made available, or the result of an
2890 attempt made to obtain a general license or permission for the use of
2891 such proprietary rights by implementers or users of this
2892 specification can be obtained from the IETF on-line IPR repository at
2893 http://www.ietf.org/ipr.
2894
2895 The IETF invites any interested party to bring to its attention any
2896 copyrights, patents or patent applications, or other proprietary
2897 rights that may cover technology that may be required to implement
2898 this standard. Please address the information to the IETF at ietf-
2899 ipr@ietf.org.
2900
2901 Acknowledgement
2902
2903 Funding for the RFC Editor function is currently provided by the
2904 Internet Society.
2905
2906
2907
2908
2909
2910
2911
2912 Arends, et al. Standards Track [Page 53]
2913
Section 6.1 of RFC6840 says:
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers for a parent zone but does not state how to find those servers. Specific instructions can be found in Section 4.2 of [RFC4035].