7 Network Working Group R. Arends
8 Request for Comments: 4035 Telematica Instituut
9 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
11 Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
12 3007, 3597, 3226 VeriSign
13 Category: Standards Track D. Massey
14 Colorado State University
20 Protocol Modifications for the DNS Security Extensions
24 This document specifies an Internet standards track protocol for the
25 Internet community, and requests discussion and suggestions for
26 improvements. Please refer to the current edition of the "Internet
27 Official Protocol Standards" (STD 1) for the standardization state
28 and status of this protocol. Distribution of this memo is unlimited.
32 Copyright (C) The Internet Society (2005).
36 This document is part of a family of documents that describe the DNS
37 Security Extensions (DNSSEC). The DNS Security Extensions are a
38 collection of new resource records and protocol modifications that
39 add data origin authentication and data integrity to the DNS. This
40 document describes the DNSSEC protocol modifications. This document
41 defines the concept of a signed zone, along with the requirements for
42 serving and resolving by using DNSSEC. These techniques allow a
43 security-aware resolver to authenticate both DNS resource records and
44 authoritative DNS error indications.
46 This document obsoletes RFC 2535 and incorporates changes from all
58 Arends, et al. Standards Track [Page 1]
60 RFC 4035 DNSSEC Protocol Modifications March 2005
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. Background and Related Documents . . . . . . . . . . . . 4
67 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
68 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
70 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
71 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
72 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
73 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
74 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
75 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
76 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
78 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
79 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
80 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
81 3.1.4. Including DS RRs in a Response . . . . . . . . . 14
82 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
83 3.1.6. The AD and CD Bits in an Authoritative Response. 16
84 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
85 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
86 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
87 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
88 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
89 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
90 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
91 4.2. Signature Verification Support . . . . . . . . . . . . . 19
92 4.3. Determining Security Status of Data . . . . . . . . . . 20
93 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
94 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
95 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
96 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
97 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
98 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
99 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
100 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
101 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
102 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
103 5.1. Special Considerations for Islands of Security . . . . . 26
104 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
105 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
106 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
107 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
108 5.3.3. Checking the Signature . . . . . . . . . . . . . 31
109 5.3.4. Authenticating a Wildcard Expanded RRset
110 Positive Response. . . . . . . . . . . . . . . . 32
114 Arends, et al. Standards Track [Page 2]
116 RFC 4035 DNSSEC Protocol Modifications March 2005
119 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
120 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
121 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
122 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
123 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
124 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
125 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
126 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
127 9.2. Informative References . . . . . . . . . . . . . . . . . 35
128 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
129 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
130 B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
131 B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
132 B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
133 B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
134 B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
135 B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
136 B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
137 B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
138 C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
139 C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
140 C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
141 C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
142 C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
143 C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
144 C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
145 C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
146 C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
147 C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
149 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
153 The DNS Security Extensions (DNSSEC) are a collection of new resource
154 records and protocol modifications that add data origin
155 authentication and data integrity to the DNS. This document defines
156 the DNSSEC protocol modifications. Section 2 of this document
157 defines the concept of a signed zone and lists the requirements for
158 zone signing. Section 3 describes the modifications to authoritative
159 name server behavior necessary for handling signed zones. Section 4
160 describes the behavior of entities that include security-aware
161 resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
162 to authenticate a response.
170 Arends, et al. Standards Track [Page 3]
172 RFC 4035 DNSSEC Protocol Modifications March 2005
175 1.1. Background and Related Documents
177 This document is part of a family of documents defining DNSSEC that
178 should be read together as a set.
180 [RFC4033] contains an introduction to DNSSEC and definitions of
181 common terms; the reader is assumed to be familiar with this
182 document. [RFC4033] also contains a list of other documents updated
183 by and obsoleted by this document set.
185 [RFC4034] defines the DNSSEC resource records.
187 The reader is also assumed to be familiar with the basic DNS concepts
188 described in [RFC1034], [RFC1035], and the subsequent documents that
189 update them; particularly, [RFC2181] and [RFC2308].
191 This document defines the DNSSEC protocol operations.
195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
197 document are to be interpreted as described in [RFC2119].
201 DNSSEC introduces the concept of signed zones. A signed zone
202 includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
203 Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
204 according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
205 respectively. A zone that does not include these records according
206 to the rules in this section is an unsigned zone.
208 DNSSEC requires a change to the definition of the CNAME resource
209 record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG
210 and NSEC RRs to appear at the same owner name as does a CNAME RR.
212 DNSSEC specifies the placement of two new RR types, NSEC and DS,
213 which can be placed at the parental side of a zone cut (that is, at a
214 delegation point). This is an exception to the general prohibition
215 against putting data in the parent zone at a zone cut. Section 2.6
216 describes this change.
226 Arends, et al. Standards Track [Page 4]
228 RFC 4035 DNSSEC Protocol Modifications March 2005
231 2.1. Including DNSKEY RRs in a Zone
233 To sign a zone, the zone's administrator generates one or more
234 public/private key pairs and uses the private key(s) to sign
235 authoritative RRsets in the zone. For each private key used to
236 create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
237 containing the corresponding public key. A zone key DNSKEY RR MUST
238 have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
239 of [RFC4034]). Public keys associated with other DNS operations MAY
240 be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
241 be used to verify RRSIGs.
243 If the zone administrator intends a signed zone to be usable other
244 than as an island of security, the zone apex MUST contain at least
245 one DNSKEY RR to act as a secure entry point into the zone. This
246 secure entry point could then be used as the target of a secure
247 delegation via a corresponding DS RR in the parent zone (see
250 2.2. Including RRSIG RRs in a Zone
252 For each authoritative RRset in a signed zone, there MUST be at least
253 one RRSIG record that meets the following requirements:
255 o The RRSIG owner name is equal to the RRset owner name.
257 o The RRSIG class is equal to the RRset class.
259 o The RRSIG Type Covered field is equal to the RRset type.
261 o The RRSIG Original TTL field is equal to the TTL of the RRset.
263 o The RRSIG RR's TTL is equal to the TTL of the RRset.
265 o The RRSIG Labels field is equal to the number of labels in the
266 RRset owner name, not counting the null root label and not
267 counting the leftmost label if it is a wildcard.
269 o The RRSIG Signer's Name field is equal to the name of the zone
270 containing the RRset.
272 o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
273 zone key DNSKEY record at the zone apex.
275 The process for constructing the RRSIG RR for a given RRset is
276 described in [RFC4034]. An RRset MAY have multiple RRSIG RRs
277 associated with it. Note that as RRSIG RRs are closely tied to the
278 RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
282 Arends, et al. Standards Track [Page 5]
284 RFC 4035 DNSSEC Protocol Modifications March 2005
287 RR types, do not form RRsets. In particular, the TTL values among
288 RRSIG RRs with a common owner name do not follow the RRset rules
289 described in [RFC2181].
291 An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
292 add no value and would create an infinite loop in the signing
295 The NS RRset that appears at the zone apex name MUST be signed, but
296 the NS RRsets that appear at delegation points (that is, the NS
297 RRsets in the parent zone that delegate the name to the child zone's
298 name servers) MUST NOT be signed. Glue address RRsets associated
299 with delegations MUST NOT be signed.
301 There MUST be an RRSIG for each RRset using at least one DNSKEY of
302 each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
303 itself MUST be signed by each algorithm appearing in the DS RRset
304 located at the delegating parent (if any).
306 2.3. Including NSEC RRs in a Zone
308 Each owner name in the zone that has authoritative data or a
309 delegation point NS RRset MUST have an NSEC resource record. The
310 format of NSEC RRs and the process for constructing the NSEC RR for a
311 given name is described in [RFC4034].
313 The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
314 value field in the zone SOA RR.
316 An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
317 RRset at any particular owner name. That is, the signing process
318 MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
319 the owner name of any RRset before the zone was signed. The main
320 reasons for this are a desire for namespace consistency between
321 signed and unsigned versions of the same zone and a desire to reduce
322 the risk of response inconsistency in security oblivious recursive
325 The type bitmap of every NSEC resource record in a signed zone MUST
326 indicate the presence of both the NSEC record itself and its
327 corresponding RRSIG record.
329 The difference between the set of owner names that require RRSIG
330 records and the set of owner names that require NSEC records is
331 subtle and worth highlighting. RRSIG records are present at the
332 owner names of all authoritative RRsets. NSEC records are present at
333 the owner names of all names for which the signed zone is
334 authoritative and also at the owner names of delegations from the
338 Arends, et al. Standards Track [Page 6]
340 RFC 4035 DNSSEC Protocol Modifications March 2005
343 signed zone to its children. Neither NSEC nor RRSIG records are
344 present (in the parent zone) at the owner names of glue address
345 RRsets. Note, however, that this distinction is for the most part
346 visible only during the zone signing process, as NSEC RRsets are
347 authoritative data and are therefore signed. Thus, any owner name
348 that has an NSEC RRset will have RRSIG RRs as well in the signed
351 The bitmap for the NSEC RR at a delegation point requires special
352 attention. Bits corresponding to the delegation NS RRset and any
353 RRsets for which the parent zone has authoritative data MUST be set;
354 bits corresponding to any non-NS RRset for which the parent is not
355 authoritative MUST be clear.
357 2.4. Including DS RRs in a Zone
359 The DS resource record establishes authentication chains between DNS
360 zones. A DS RRset SHOULD be present at a delegation point when the
361 child zone is signed. The DS RRset MAY contain multiple records,
362 each referencing a public key in the child zone used to verify the
363 RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS
364 RRsets MUST NOT appear at a zone's apex.
366 A DS RR SHOULD point to a DNSKEY RR that is present in the child's
367 apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
368 by the corresponding private key. DS RRs that fail to meet these
369 conditions are not useful for validation, but because the DS RR and
370 its corresponding DNSKEY RR are in different zones, and because the
371 DNS is only loosely consistent, temporary mismatches can occur.
373 The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
374 (that is, the NS RRset from the same zone containing the DS RRset).
376 Construction of a DS RR requires knowledge of the corresponding
377 DNSKEY RR in the child zone, which implies communication between the
378 child and parent zones. This communication is an operational matter
379 not covered by this document.
381 2.5. Changes to the CNAME Resource Record
383 If a CNAME RRset is present at a name in a signed zone, appropriate
384 RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
385 name for secure dynamic update purposes is also allowed ([RFC3007]).
386 Other types MUST NOT be present at that name.
388 This is a modification to the original CNAME definition given in
389 [RFC1034]. The original definition of the CNAME RR did not allow any
390 other types to coexist with a CNAME record, but a signed zone
394 Arends, et al. Standards Track [Page 7]
396 RFC 4035 DNSSEC Protocol Modifications March 2005
399 requires NSEC and RRSIG RRs for every authoritative name. To resolve
400 this conflict, this specification modifies the definition of the
401 CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
403 2.6. DNSSEC RR Types Appearing at Zone Cuts
405 DNSSEC introduced two new RR types that are unusual in that they can
406 appear at the parental side of a zone cut. At the parental side of a
407 zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
408 the owner name. A DS RR could also be present if the zone being
409 delegated is signed and seeks to have a chain of authentication to
410 the parent zone. This is an exception to the original DNS
411 specification ([RFC1034]), which states that only NS RRsets could
412 appear at the parental side of a zone cut.
414 This specification updates the original DNS specification to allow
415 NSEC and DS RR types at the parent side of a zone cut. These RRsets
416 are authoritative for the parent when they appear at the parent side
419 2.7. Example of a Secure Zone
421 Appendix A shows a complete example of a small signed zone.
425 This section describes the behavior of entities that include
426 security-aware name server functions. In many cases such functions
427 will be part of a security-aware recursive name server, but a
428 security-aware authoritative name server has some of the same
429 requirements. Functions specific to security-aware recursive name
430 servers are described in Section 3.2; functions specific to
431 authoritative servers are described in Section 3.1.
433 In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
434 are as used in [RFC1034].
436 A security-aware name server MUST support the EDNS0 ([RFC2671])
437 message size extension, MUST support a message size of at least 1220
438 octets, and SHOULD support a message size of 4000 octets. As IPv6
439 packets can only be fragmented by the source host, a security aware
440 name server SHOULD take steps to ensure that UDP datagrams it
441 transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
442 MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460],
443 and [RFC3226] for further discussion of packet size and fragmentation
450 Arends, et al. Standards Track [Page 8]
452 RFC 4035 DNSSEC Protocol Modifications March 2005
455 A security-aware name server that receives a DNS query that does not
456 include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
457 treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
458 MUST NOT perform any of the additional processing described below.
459 Because the DS RR type has the peculiar property of only existing in
460 the parent zone at delegation points, DS RRs always require some
461 special processing, as described in Section 3.1.4.1.
463 Security aware name servers that receive explicit queries for
464 security RR types that match the content of more than one zone that
465 it serves (for example, NSEC and RRSIG RRs above and below a
466 delegation point where the server is authoritative for both zones)
467 should behave self-consistently. As long as the response is always
468 consistent for each query to the name server, the name server MAY
469 return one of the following:
471 o The above-delegation RRsets.
472 o The below-delegation RRsets.
473 o Both above and below-delegation RRsets.
474 o Empty answer section (no records).
475 o Some other response.
478 DNSSEC allocates two new bits in the DNS message header: the CD
479 (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
480 is controlled by resolvers; a security-aware name server MUST copy
481 the CD bit from a query into the corresponding response. The AD bit
482 is controlled by name servers; a security-aware name server MUST
483 ignore the setting of the AD bit in queries. See Sections 3.1.6,
484 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
486 A security aware name server that synthesizes CNAME RRs from DNAME
487 RRs as described in [RFC2672] SHOULD NOT generate signatures for the
488 synthesized CNAME RRs.
490 3.1. Authoritative Name Servers
492 Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
493 pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
494 server for a signed zone MUST include additional RRSIG, NSEC, and DS
495 RRs, according to the following rules:
497 o RRSIG RRs that can be used to authenticate a response MUST be
498 included in the response according to the rules in Section 3.1.1.
506 Arends, et al. Standards Track [Page 9]
508 RFC 4035 DNSSEC Protocol Modifications March 2005
511 o NSEC RRs that can be used to provide authenticated denial of
512 existence MUST be included in the response automatically according
513 to the rules in Section 3.1.3.
515 o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
516 be included in referrals automatically according to the rules in
519 These rules only apply to responses where the semantics convey
520 information about the presence or absence of resource records. That
521 is, these rules are not intended to rule out responses such as RCODE
522 4 ("Not Implemented") or RCODE 5 ("Refused").
524 DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
525 discusses zone transfer requirements.
527 3.1.1. Including RRSIG RRs in a Response
529 When responding to a query that has the DO bit set, a security-aware
530 authoritative name server SHOULD attempt to send RRSIG RRs that a
531 security-aware resolver can use to authenticate the RRsets in the
532 response. A name server SHOULD make every attempt to keep the RRset
533 and its associated RRSIG(s) together in a response. Inclusion of
534 RRSIG RRs in a response is subject to the following rules:
536 o When placing a signed RRset in the Answer section, the name server
537 MUST also place its RRSIG RRs in the Answer section. The RRSIG
538 RRs have a higher priority for inclusion than any other RRsets
539 that may have to be included. If space does not permit inclusion
540 of these RRSIG RRs, the name server MUST set the TC bit.
542 o When placing a signed RRset in the Authority section, the name
543 server MUST also place its RRSIG RRs in the Authority section.
544 The RRSIG RRs have a higher priority for inclusion than any other
545 RRsets that may have to be included. If space does not permit
546 inclusion of these RRSIG RRs, the name server MUST set the TC bit.
548 o When placing a signed RRset in the Additional section, the name
549 server MUST also place its RRSIG RRs in the Additional section.
550 If space does not permit inclusion of both the RRset and its
551 associated RRSIG RRs, the name server MAY retain the RRset while
552 dropping the RRSIG RRs. If this happens, the name server MUST NOT
553 set the TC bit solely because these RRSIG RRs didn't fit.
562 Arends, et al. Standards Track [Page 10]
564 RFC 4035 DNSSEC Protocol Modifications March 2005
567 3.1.2. Including DNSKEY RRs in a Response
569 When responding to a query that has the DO bit set and that requests
570 the SOA or NS RRs at the apex of a signed zone, a security-aware
571 authoritative name server for that zone MAY return the zone apex
572 DNSKEY RRset in the Additional section. In this situation, the
573 DNSKEY RRset and associated RRSIG RRs have lower priority than does
574 any other information that would be placed in the additional section.
575 The name server SHOULD NOT include the DNSKEY RRset unless there is
576 enough space in the response message for both the DNSKEY RRset and
577 its associated RRSIG RR(s). If there is not enough space to include
578 these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
579 NOT set the TC bit solely because these RRs didn't fit (see Section
582 3.1.3. Including NSEC RRs in a Response
584 When responding to a query that has the DO bit set, a security-aware
585 authoritative name server for a signed zone MUST include NSEC RRs in
586 each of the following cases:
588 No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
589 but does not contain any RRsets that exactly match <SNAME, SCLASS,
592 Name Error: The zone does not contain any RRsets that match <SNAME,
593 SCLASS> either exactly or via wildcard name expansion.
595 Wildcard Answer: The zone does not contain any RRsets that exactly
596 match <SNAME, SCLASS> but does contain an RRset that matches
597 <SNAME, SCLASS, STYPE> via wildcard name expansion.
599 Wildcard No Data: The zone does not contain any RRsets that exactly
600 match <SNAME, SCLASS> and does contain one or more RRsets that
601 match <SNAME, SCLASS> via wildcard name expansion, but does not
602 contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
605 In each of these cases, the name server includes NSEC RRs in the
606 response to prove that an exact match for <SNAME, SCLASS, STYPE> was
607 not present in the zone and that the response that the name server is
608 returning is correct given the data in the zone.
618 Arends, et al. Standards Track [Page 11]
620 RFC 4035 DNSSEC Protocol Modifications March 2005
623 3.1.3.1. Including NSEC RRs: No Data Response
625 If the zone contains RRsets matching <SNAME, SCLASS> but contains no
626 RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
627 include the NSEC RR for <SNAME, SCLASS> along with its associated
628 RRSIG RR(s) in the Authority section of the response (see Section
629 3.1.1). If space does not permit inclusion of the NSEC RR or its
630 associated RRSIG RR(s), the name server MUST set the TC bit (see
633 Since the search name exists, wildcard name expansion does not apply
634 to this query, and a single signed NSEC RR suffices to prove that the
635 requested RR type does not exist.
637 3.1.3.2. Including NSEC RRs: Name Error Response
639 If the zone does not contain any RRsets matching <SNAME, SCLASS>
640 either exactly or via wildcard name expansion, then the name server
641 MUST include the following NSEC RRs in the Authority section, along
642 with their associated RRSIG RRs:
644 o An NSEC RR proving that there is no exact match for <SNAME,
647 o An NSEC RR proving that the zone contains no RRsets that would
648 match <SNAME, SCLASS> via wildcard name expansion.
650 In some cases, a single NSEC RR may prove both of these points. If
651 it does, the name server SHOULD only include the NSEC RR and its
652 RRSIG RR(s) once in the Authority section.
654 If space does not permit inclusion of these NSEC and RRSIG RRs, the
655 name server MUST set the TC bit (see Section 3.1.1).
657 The owner names of these NSEC and RRSIG RRs are not subject to
658 wildcard name expansion when these RRs are included in the Authority
659 section of the response.
661 Note that this form of response includes cases in which SNAME
662 corresponds to an empty non-terminal name within the zone (a name
663 that is not the owner name for any RRset but that is the parent name
664 of one or more RRsets).
666 3.1.3.3. Including NSEC RRs: Wildcard Answer Response
668 If the zone does not contain any RRsets that exactly match <SNAME,
669 SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
670 via wildcard name expansion, the name server MUST include the
674 Arends, et al. Standards Track [Page 12]
676 RFC 4035 DNSSEC Protocol Modifications March 2005
679 wildcard-expanded answer and the corresponding wildcard-expanded
680 RRSIG RRs in the Answer section and MUST include in the Authority
681 section an NSEC RR and associated RRSIG RR(s) proving that the zone
682 does not contain a closer match for <SNAME, SCLASS>. If space does
683 not permit inclusion of the answer, NSEC and RRSIG RRs, the name
684 server MUST set the TC bit (see Section 3.1.1).
686 3.1.3.4. Including NSEC RRs: Wildcard No Data Response
688 This case is a combination of the previous cases. The zone does not
689 contain an exact match for <SNAME, SCLASS>, and although the zone
690 does contain RRsets that match <SNAME, SCLASS> via wildcard
691 expansion, none of those RRsets matches STYPE. The name server MUST
692 include the following NSEC RRs in the Authority section, along with
693 their associated RRSIG RRs:
695 o An NSEC RR proving that there are no RRsets matching STYPE at the
696 wildcard owner name that matched <SNAME, SCLASS> via wildcard
699 o An NSEC RR proving that there are no RRsets in the zone that would
700 have been a closer match for <SNAME, SCLASS>.
702 In some cases, a single NSEC RR may prove both of these points. If
703 it does, the name server SHOULD only include the NSEC RR and its
704 RRSIG RR(s) once in the Authority section.
706 The owner names of these NSEC and RRSIG RRs are not subject to
707 wildcard name expansion when these RRs are included in the Authority
708 section of the response.
710 If space does not permit inclusion of these NSEC and RRSIG RRs, the
711 name server MUST set the TC bit (see Section 3.1.1).
713 3.1.3.5. Finding the Right NSEC RRs
715 As explained above, there are several situations in which a
716 security-aware authoritative name server has to locate an NSEC RR
717 that proves that no RRsets matching a particular SNAME exist.
718 Locating such an NSEC RR within an authoritative zone is relatively
719 simple, at least in concept. The following discussion assumes that
720 the name server is authoritative for the zone that would have held
721 the non-existent RRsets matching SNAME. The algorithm below is
722 written for clarity, not for efficiency.
724 To find the NSEC that proves that no RRsets matching name N exist in
725 the zone Z that would have held them, construct a sequence, S,
726 consisting of the owner names of every RRset in Z, sorted into
730 Arends, et al. Standards Track [Page 13]
732 RFC 4035 DNSSEC Protocol Modifications March 2005
735 canonical order ([RFC4034]), with no duplicate names. Find the name
736 M that would have immediately preceded N in S if any RRsets with
737 owner name N had existed. M is the owner name of the NSEC RR that
738 proves that no RRsets exist with owner name N.
740 The algorithm for finding the NSEC RR that proves that a given name
741 is not covered by any applicable wildcard is similar but requires an
742 extra step. More precisely, the algorithm for finding the NSEC
743 proving that no RRsets exist with the applicable wildcard name is
744 precisely the same as the algorithm for finding the NSEC RR that
745 proves that RRsets with any other owner name do not exist. The part
746 that's missing is a method of determining the name of the non-
747 existent applicable wildcard. In practice, this is easy, because the
748 authoritative name server has already checked for the presence of
749 precisely this wildcard name as part of step (1)(c) of the normal
750 lookup algorithm described in Section 4.3.2 of [RFC1034].
752 3.1.4. Including DS RRs in a Response
754 When responding to a query that has the DO bit set, a security-aware
755 authoritative name server returning a referral includes DNSSEC data
756 along with the NS RRset.
758 If a DS RRset is present at the delegation point, the name server
759 MUST return both the DS RRset and its associated RRSIG RR(s) in the
760 Authority section along with the NS RRset.
762 If no DS RRset is present at the delegation point, the name server
763 MUST return both the NSEC RR that proves that the DS RRset is not
764 present and the NSEC RR's associated RRSIG RR(s) along with the NS
765 RRset. The name server MUST place the NS RRset before the NSEC RRset
766 and its associated RRSIG RR(s).
768 Including these DS, NSEC, and RRSIG RRs increases the size of
769 referral messages and may cause some or all glue RRs to be omitted.
770 If space does not permit inclusion of the DS or NSEC RRset and
771 associated RRSIG RRs, the name server MUST set the TC bit (see
774 3.1.4.1. Responding to Queries for DS RRs
776 The DS resource record type is unusual in that it appears only on the
777 parent zone's side of a zone cut. For example, the DS RRset for the
778 delegation of "foo.example" is stored in the "example" zone rather
779 than in the "foo.example" zone. This requires special processing
780 rules for both name servers and resolvers, as the name server for the
781 child zone is authoritative for the name at the zone cut by the
782 normal DNS rules but the child zone does not contain the DS RRset.
786 Arends, et al. Standards Track [Page 14]
788 RFC 4035 DNSSEC Protocol Modifications March 2005
791 A security-aware resolver sends queries to the parent zone when
792 looking for a needed DS RR at a delegation point (see Section 4.2).
793 However, special rules are necessary to avoid confusing
794 security-oblivious resolvers which might become involved in
795 processing such a query (for example, in a network configuration that
796 forces a security-aware resolver to channel its queries through a
797 security-oblivious recursive name server). The rest of this section
798 describes how a security-aware name server processes DS queries in
799 order to avoid this problem.
801 The need for special processing by a security-aware name server only
802 arises when all the following conditions are met:
804 o The name server has received a query for the DS RRset at a zone
807 o The name server is authoritative for the child zone.
809 o The name server is not authoritative for the parent zone.
811 o The name server does not offer recursion.
813 In all other cases, the name server either has some way of obtaining
814 the DS RRset or could not have been expected to have the DS RRset
815 even by the pre-DNSSEC processing rules, so the name server can
816 return either the DS RRset or an error response according to the
817 normal processing rules.
819 If all the above conditions are met, however, the name server is
820 authoritative for SNAME but cannot supply the requested RRset. In
821 this case, the name server MUST return an authoritative "no data"
822 response showing that the DS RRset does not exist in the child zone's
823 apex. See Appendix B.8 for an example of such a response.
825 3.1.5. Responding to Queries for Type AXFR or IXFR
827 DNSSEC does not change the DNS zone transfer process. A signed zone
828 will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
829 records have no special meaning with respect to a zone transfer
832 An authoritative name server is not required to verify that a zone is
833 properly signed before sending or accepting a zone transfer.
834 However, an authoritative name server MAY choose to reject the entire
835 zone transfer if the zone fails to meet any of the signing
836 requirements described in Section 2. The primary objective of a zone
837 transfer is to ensure that all authoritative name servers have
838 identical copies of the zone. An authoritative name server that
842 Arends, et al. Standards Track [Page 15]
844 RFC 4035 DNSSEC Protocol Modifications March 2005
847 chooses to perform its own zone validation MUST NOT selectively
848 reject some RRs and accept others.
850 DS RRsets appear only on the parental side of a zone cut and are
851 authoritative data in the parent zone. As with any other
852 authoritative RRset, the DS RRset MUST be included in zone transfers
853 of the zone in which the RRset is authoritative data. In the case of
854 the DS RRset, this is the parent zone.
856 NSEC RRs appear in both the parent and child zones at a zone cut and
857 are authoritative data in both the parent and child zones. The
858 parental and child NSEC RRs at a zone cut are never identical to each
859 other, as the NSEC RR in the child zone's apex will always indicate
860 the presence of the child zone's SOA RR whereas the parental NSEC RR
861 at the zone cut will never indicate the presence of an SOA RR. As
862 with any other authoritative RRs, NSEC RRs MUST be included in zone
863 transfers of the zone in which they are authoritative data. The
864 parental NSEC RR at a zone cut MUST be included in zone transfers of
865 the parent zone, and the NSEC at the zone apex of the child zone MUST
866 be included in zone transfers of the child zone.
868 RRSIG RRs appear in both the parent and child zones at a zone cut and
869 are authoritative in whichever zone contains the authoritative RRset
870 for which the RRSIG RR provides the signature. That is, the RRSIG RR
871 for a DS RRset or a parental NSEC RR at a zone cut will be
872 authoritative in the parent zone, and the RRSIG for any RRset in the
873 child zone's apex will be authoritative in the child zone. Parental
874 and child RRSIG RRs at a zone cut will never be identical to each
875 other, as the Signer's Name field of an RRSIG RR in the child zone's
876 apex will indicate a DNSKEY RR in the child zone's apex whereas the
877 same field of a parental RRSIG RR at the zone cut will indicate a
878 DNSKEY RR in the parent zone's apex. As with any other authoritative
879 RRs, RRSIG RRs MUST be included in zone transfers of the zone in
880 which they are authoritative data.
882 3.1.6. The AD and CD Bits in an Authoritative Response
884 The CD and AD bits are designed for use in communication between
885 security-aware resolvers and security-aware recursive name servers.
886 These bits are for the most part not relevant to query processing by
887 security-aware authoritative name servers.
889 A security-aware name server does not perform signature validation
890 for authoritative data during query processing, even when the CD bit
891 is clear. A security-aware name server SHOULD clear the CD bit when
892 composing an authoritative response.
898 Arends, et al. Standards Track [Page 16]
900 RFC 4035 DNSSEC Protocol Modifications March 2005
903 A security-aware name server MUST NOT set the AD bit in a response
904 unless the name server considers all RRsets in the Answer and
905 Authority sections of the response to be authentic. A security-aware
906 name server's local policy MAY consider data from an authoritative
907 zone to be authentic without further validation. However, the name
908 server MUST NOT do so unless the name server obtained the
909 authoritative zone via secure means (such as a secure zone transfer
910 mechanism) and MUST NOT do so unless this behavior has been
911 configured explicitly.
913 A security-aware name server that supports recursion MUST follow the
914 rules for the CD and AD bits given in Section 3.2 when generating a
915 response that involves data obtained via recursion.
917 3.2. Recursive Name Servers
919 As explained in [RFC4033], a security-aware recursive name server is
920 an entity that acts in both the security-aware name server and
921 security-aware resolver roles. This section uses the terms "name
922 server side" and "resolver side" to refer to the code within a
923 security-aware recursive name server that implements the
924 security-aware name server role and the code that implements the
925 security-aware resolver role, respectively.
927 The resolver side follows the usual rules for caching and negative
928 caching that would apply to any security-aware resolver.
932 The resolver side of a security-aware recursive name server MUST set
933 the DO bit when sending requests, regardless of the state of the DO
934 bit in the initiating request received by the name server side. If
935 the DO bit in an initiating query is not set, the name server side
936 MUST strip any authenticating DNSSEC RRs from the response but MUST
937 NOT strip any DNSSEC RR types that the initiating query explicitly
942 The CD bit exists in order to allow a security-aware resolver to
943 disable signature validation in a security-aware name server's
944 processing of a particular query.
946 The name server side MUST copy the setting of the CD bit from a query
947 to the corresponding response.
949 The name server side of a security-aware recursive name server MUST
950 pass the state of the CD bit to the resolver side along with the rest
954 Arends, et al. Standards Track [Page 17]
956 RFC 4035 DNSSEC Protocol Modifications March 2005
959 of an initiating query, so that the resolver side will know whether
960 it is required to verify the response data it returns to the name
961 server side. If the CD bit is set, it indicates that the originating
962 resolver is willing to perform whatever authentication its local
963 policy requires. Thus, the resolver side of the recursive name
964 server need not perform authentication on the RRsets in the response.
965 When the CD bit is set, the recursive name server SHOULD, if
966 possible, return the requested data to the originating resolver, even
967 if the recursive name server's local authentication policy would
968 reject the records in question. That is, by setting the CD bit, the
969 originating resolver has indicated that it takes responsibility for
970 performing its own authentication, and the recursive name server
971 should not interfere.
973 If the resolver side implements a BAD cache (see Section 4.7) and the
974 name server side receives a query that matches an entry in the
975 resolver side's BAD cache, the name server side's response depends on
976 the state of the CD bit in the original query. If the CD bit is set,
977 the name server side SHOULD return the data from the BAD cache; if
978 the CD bit is not set, the name server side MUST return RCODE 2
981 The intent of the above rule is to provide the raw data to clients
982 that are capable of performing their own signature verification
983 checks while protecting clients that depend on the resolver side of a
984 security-aware recursive name server to perform such checks. Several
985 of the possible reasons why signature validation might fail involve
986 conditions that may not apply equally to the recursive name server
987 and the client that invoked it. For example, the recursive name
988 server's clock may be set incorrectly, or the client may have
989 knowledge of a relevant island of security that the recursive name
990 server does not share. In such cases, "protecting" a client that is
991 capable of performing its own signature validation from ever seeing
992 the "bad" data does not help the client.
996 The name server side of a security-aware recursive name server MUST
997 NOT set the AD bit in a response unless the name server considers all
998 RRsets in the Answer and Authority sections of the response to be
999 authentic. The name server side SHOULD set the AD bit if and only if
1000 the resolver side considers all RRsets in the Answer section and any
1001 relevant negative response RRs in the Authority section to be
1002 authentic. The resolver side MUST follow the procedure described in
1003 Section 5 to determine whether the RRs in question are authentic.
1004 However, for backward compatibility, a recursive name server MAY set
1005 the AD bit when a response includes unsigned CNAME RRs if those CNAME
1010 Arends, et al. Standards Track [Page 18]
1012 RFC 4035 DNSSEC Protocol Modifications March 2005
1015 RRs demonstrably could have been synthesized from an authentic DNAME
1016 RR that is also included in the response according to the synthesis
1017 rules described in [RFC2672].
1019 3.3. Example DNSSEC Responses
1021 See Appendix B for example response packets.
1025 This section describes the behavior of entities that include
1026 security-aware resolver functions. In many cases such functions will
1027 be part of a security-aware recursive name server, but a stand-alone
1028 security-aware resolver has many of the same requirements. Functions
1029 specific to security-aware recursive name servers are described in
1034 A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
1035 pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
1037 A security-aware resolver MUST support a message size of at least
1038 1220 octets, SHOULD support a message size of 4000 octets, and MUST
1039 use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
1040 to advertise the message size that it is willing to accept. A
1041 security-aware resolver's IP layer MUST handle fragmented UDP packets
1042 correctly regardless of whether any such fragmented packets were
1043 received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and
1044 [RFC3226] for discussion of these requirements.
1046 4.2. Signature Verification Support
1048 A security-aware resolver MUST support the signature verification
1049 mechanisms described in Section 5 and SHOULD apply them to every
1050 received response, except when:
1052 o the security-aware resolver is part of a security-aware recursive
1053 name server, and the response is the result of recursion on behalf
1054 of a query received with the CD bit set;
1056 o the response is the result of a query generated directly via some
1057 form of application interface that instructed the security-aware
1058 resolver not to perform validation for this query; or
1060 o validation for this query has been disabled by local policy.
1066 Arends, et al. Standards Track [Page 19]
1068 RFC 4035 DNSSEC Protocol Modifications March 2005
1071 A security-aware resolver's support for signature verification MUST
1072 include support for verification of wildcard owner names.
1074 Security-aware resolvers MAY query for missing security RRs in an
1075 attempt to perform validation; implementations that choose to do so
1076 must be aware that the answers received may not be sufficient to
1077 validate the original response. For example, a zone update may have
1078 changed (or deleted) the desired information between the original and
1081 When attempting to retrieve missing NSEC RRs that reside on the
1082 parental side at a zone cut, a security-aware iterative-mode resolver
1083 MUST query the name servers for the parent zone, not the child zone.
1085 When attempting to retrieve a missing DS, a security-aware
1086 iterative-mode resolver MUST query the name servers for the parent
1087 zone, not the child zone. As explained in Section 3.1.4.1,
1088 security-aware name servers need to apply special processing rules to
1089 handle the DS RR, and in some situations the resolver may also need
1090 to apply special rules to locate the name servers for the parent zone
1091 if the resolver does not already have the parent's NS RRset. To
1092 locate the parent NS RRset, the resolver can start with the
1093 delegation name, strip off the leftmost label, and query for an NS
1094 RRset by that name. If no NS RRset is present at that name, the
1095 resolver then strips off the leftmost remaining label and retries the
1096 query for that name, repeating this process of walking up the tree
1097 until it either finds the NS RRset or runs out of labels.
1099 4.3. Determining Security Status of Data
1101 A security-aware resolver MUST be able to determine whether it should
1102 expect a particular RRset to be signed. More precisely, a
1103 security-aware resolver must be able to distinguish between four
1106 Secure: An RRset for which the resolver is able to build a chain of
1107 signed DNSKEY and DS RRs from a trusted security anchor to the
1108 RRset. In this case, the RRset should be signed and is subject to
1109 signature validation, as described above.
1111 Insecure: An RRset for which the resolver knows that it has no chain
1112 of signed DNSKEY and DS RRs from any trusted starting point to the
1113 RRset. This can occur when the target RRset lies in an unsigned
1114 zone or in a descendent of an unsigned zone. In this case, the
1115 RRset may or may not be signed, but the resolver will not be able
1116 to verify the signature.
1122 Arends, et al. Standards Track [Page 20]
1124 RFC 4035 DNSSEC Protocol Modifications March 2005
1127 Bogus: An RRset for which the resolver believes that it ought to be
1128 able to establish a chain of trust but for which it is unable to
1129 do so, either due to signatures that for some reason fail to
1130 validate or due to missing data that the relevant DNSSEC RRs
1131 indicate should be present. This case may indicate an attack but
1132 may also indicate a configuration error or some form of data
1135 Indeterminate: An RRset for which the resolver is not able to
1136 determine whether the RRset should be signed, as the resolver is
1137 not able to obtain the necessary DNSSEC RRs. This can occur when
1138 the security-aware resolver is not able to contact security-aware
1139 name servers for the relevant zones.
1141 4.4. Configured Trust Anchors
1143 A security-aware resolver MUST be capable of being configured with at
1144 least one trusted public key or DS RR and SHOULD be capable of being
1145 configured with multiple trusted public keys or DS RRs. Since a
1146 security-aware resolver will not be able to validate signatures
1147 without such a configured trust anchor, the resolver SHOULD have some
1148 reasonably robust mechanism for obtaining such keys when it boots;
1149 examples of such a mechanism would be some form of non-volatile
1150 storage (such as a disk drive) or some form of trusted local network
1151 configuration mechanism.
1153 Note that trust anchors also cover key material that is updated in a
1154 secure manner. This secure manner could be through physical media, a
1155 key exchange protocol, or some other out-of-band means.
1157 4.5. Response Caching
1159 A security-aware resolver SHOULD cache each response as a single
1160 atomic entry containing the entire answer, including the named RRset
1161 and any associated DNSSEC RRs. The resolver SHOULD discard the
1162 entire atomic entry when any of the RRs contained in it expire. In
1163 most cases the appropriate cache index for the atomic entry will be
1164 the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
1165 form described in Section 3.1.3.2 the appropriate cache index will be
1166 the double <QNAME,QCLASS>.
1168 The reason for these recommendations is that, between the initial
1169 query and the expiration of the data from the cache, the
1170 authoritative data might have been changed (for example, via dynamic
1178 Arends, et al. Standards Track [Page 21]
1180 RFC 4035 DNSSEC Protocol Modifications March 2005
1183 There are two situations for which this is relevant:
1185 1. By using the RRSIG record, it is possible to deduce that an
1186 answer was synthesized from a wildcard. A security-aware
1187 recursive name server could store this wildcard data and use it
1188 to generate positive responses to queries other than the name for
1189 which the original answer was first received.
1191 2. NSEC RRs received to prove the non-existence of a name could be
1192 reused by a security-aware resolver to prove the non-existence of
1193 any name in the name range it spans.
1195 In theory, a resolver could use wildcards or NSEC RRs to generate
1196 positive and negative responses (respectively) until the TTL or
1197 signatures on the records in question expire. However, it seems
1198 prudent for resolvers to avoid blocking new authoritative data or
1199 synthesizing new data on their own. Resolvers that follow this
1200 recommendation will have a more consistent view of the namespace.
1202 4.6. Handling of the CD and AD Bits
1204 A security-aware resolver MAY set a query's CD bit in order to
1205 indicate that the resolver takes responsibility for performing
1206 whatever authentication its local policy requires on the RRsets in
1207 the response. See Section 3.2 for the effect this bit has on the
1208 behavior of security-aware recursive name servers.
1210 A security-aware resolver MUST clear the AD bit when composing query
1211 messages to protect against buggy name servers that blindly copy
1212 header bits that they do not understand from the query message to the
1215 A resolver MUST disregard the meaning of the CD and AD bits in a
1216 response unless the response was obtained by using a secure channel
1217 or the resolver was specifically configured to regard the message
1218 header bits without using a secure channel.
1220 4.7. Caching BAD Data
1222 While many validation errors will be transient, some are likely to be
1223 more persistent, such as those caused by administrative error
1224 (failure to re-sign a zone, clock skew, and so forth). Since
1225 requerying will not help in these cases, validating resolvers might
1226 generate a significant amount of unnecessary DNS traffic as a result
1227 of repeated queries for RRsets with persistent validation failures.
1229 To prevent such unnecessary DNS traffic, security-aware resolvers MAY
1230 cache data with invalid signatures, with some restrictions.
1234 Arends, et al. Standards Track [Page 22]
1236 RFC 4035 DNSSEC Protocol Modifications March 2005
1239 Conceptually, caching such data is similar to negative caching
1240 ([RFC2308]), except that instead of caching a valid negative
1241 response, the resolver is caching the fact that a particular answer
1242 failed to validate. This document refers to a cache of data with
1243 invalid signatures as a "BAD cache".
1245 Resolvers that implement a BAD cache MUST take steps to prevent the
1246 cache from being useful as a denial-of-service attack amplifier,
1247 particularly the following:
1249 o Since RRsets that fail to validate do not have trustworthy TTLs,
1250 the implementation MUST assign a TTL. This TTL SHOULD be small,
1251 in order to mitigate the effect of caching the results of an
1254 o In order to prevent caching of a transient validation failure
1255 (which might be the result of an attack), resolvers SHOULD track
1256 queries that result in validation failures and SHOULD only answer
1257 from the BAD cache after the number of times that responses to
1258 queries for that particular <QNAME, QTYPE, QCLASS> have failed to
1259 validate exceeds a threshold value.
1261 Resolvers MUST NOT return RRsets from the BAD cache unless the
1262 resolver is not required to validate the signatures of the RRsets in
1263 question under the rules given in Section 4.2 of this document. See
1264 Section 3.2.2 for discussion of how the responses returned by a
1265 security-aware recursive name server interact with a BAD cache.
1267 4.8. Synthesized CNAMEs
1269 A validating security-aware resolver MUST treat the signature of a
1270 valid signed DNAME RR as also covering unsigned CNAME RRs that could
1271 have been synthesized from the DNAME RR, as described in [RFC2672],
1272 at least to the extent of not rejecting a response message solely
1273 because it contains such CNAME RRs. The resolver MAY retain such
1274 CNAME RRs in its cache or in the answers it hands back, but is not
1279 A security-aware stub resolver MUST support the DNSSEC RR types, at
1280 least to the extent of not mishandling responses just because they
1290 Arends, et al. Standards Track [Page 23]
1292 RFC 4035 DNSSEC Protocol Modifications March 2005
1295 4.9.1. Handling of the DO Bit
1297 A non-validating security-aware stub resolver MAY include the DNSSEC
1298 RRs returned by a security-aware recursive name server as part of the
1299 data that the stub resolver hands back to the application that
1300 invoked it, but is not required to do so. A non-validating stub
1301 resolver that seeks to do this will need to set the DO bit in order
1302 to receive DNSSEC RRs from the recursive name server.
1304 A validating security-aware stub resolver MUST set the DO bit,
1305 because otherwise it will not receive the DNSSEC RRs it needs to
1306 perform signature validation.
1308 4.9.2. Handling of the CD Bit
1310 A non-validating security-aware stub resolver SHOULD NOT set the CD
1311 bit when sending queries unless it is requested by the application
1312 layer, as by definition, a non-validating stub resolver depends on
1313 the security-aware recursive name server to perform validation on its
1316 A validating security-aware stub resolver SHOULD set the CD bit,
1317 because otherwise the security-aware recursive name server will
1318 answer the query using the name server's local policy, which may
1319 prevent the stub resolver from receiving data that would be
1320 acceptable to the stub resolver's local policy.
1322 4.9.3. Handling of the AD Bit
1324 A non-validating security-aware stub resolver MAY chose to examine
1325 the setting of the AD bit in response messages that it receives in
1326 order to determine whether the security-aware recursive name server
1327 that sent the response claims to have cryptographically verified the
1328 data in the Answer and Authority sections of the response message.
1329 Note, however, that the responses received by a security-aware stub
1330 resolver are heavily dependent on the local policy of the
1331 security-aware recursive name server. Therefore, there may be little
1332 practical value in checking the status of the AD bit, except perhaps
1333 as a debugging aid. In any case, a security-aware stub resolver MUST
1334 NOT place any reliance on signature validation allegedly performed on
1335 its behalf, except when the security-aware stub resolver obtained the
1336 data in question from a trusted security-aware recursive name server
1337 via a secure channel.
1339 A validating security-aware stub resolver SHOULD NOT examine the
1340 setting of the AD bit in response messages, as, by definition, the
1341 stub resolver performs its own signature validation regardless of the
1342 setting of the AD bit.
1346 Arends, et al. Standards Track [Page 24]
1348 RFC 4035 DNSSEC Protocol Modifications March 2005
1351 5. Authenticating DNS Responses
1353 To use DNSSEC RRs for authentication, a security-aware resolver
1354 requires configured knowledge of at least one authenticated DNSKEY or
1355 DS RR. The process for obtaining and authenticating this initial
1356 trust anchor is achieved via some external mechanism. For example, a
1357 resolver could use some off-line authenticated exchange to obtain a
1358 zone's DNSKEY RR or to obtain a DS RR that identifies and
1359 authenticates a zone's DNSKEY RR. The remainder of this section
1360 assumes that the resolver has somehow obtained an initial set of
1363 An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
1364 RRset. To authenticate an apex DNSKEY RRset by using an initial key,
1367 1. verify that the initial DNSKEY RR appears in the apex DNSKEY
1368 RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
1371 2. verify that there is some RRSIG RR that covers the apex DNSKEY
1372 RRset, and that the combination of the RRSIG RR and the initial
1373 DNSKEY RR authenticates the DNSKEY RRset. The process for using
1374 an RRSIG RR to authenticate an RRset is described in Section 5.3.
1376 Once the resolver has authenticated the apex DNSKEY RRset by using an
1377 initial DNSKEY RR, delegations from that zone can be authenticated by
1378 using DS RRs. This allows a resolver to start from an initial key
1379 and use DS RRsets to proceed recursively down the DNS tree, obtaining
1380 other apex DNSKEY RRsets. If the resolver were configured with a
1381 root DNSKEY RR, and if every delegation had a DS RR associated with
1382 it, then the resolver could obtain and validate any apex DNSKEY
1383 RRset. The process of using DS RRs to authenticate referrals is
1384 described in Section 5.2.
1386 Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
1387 DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
1388 RRsets in the zone once the resolver has authenticated a zone's apex
1389 DNSKEY RRset. Section 5.4 shows how the resolver can use
1390 authenticated NSEC RRsets from the zone to prove that an RRset is not
1391 present in the zone.
1393 When a resolver indicates support for DNSSEC (by setting the DO bit),
1394 a security-aware name server should attempt to provide the necessary
1395 DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
1396 However, a security-aware resolver may still receive a response that
1397 lacks the appropriate DNSSEC RRs, whether due to configuration issues
1398 such as an upstream security-oblivious recursive name server that
1402 Arends, et al. Standards Track [Page 25]
1404 RFC 4035 DNSSEC Protocol Modifications March 2005
1407 accidentally interferes with DNSSEC RRs or due to a deliberate attack
1408 in which an adversary forges a response, strips DNSSEC RRs from a
1409 response, or modifies a query so that DNSSEC RRs appear not to be
1410 requested. The absence of DNSSEC data in a response MUST NOT by
1411 itself be taken as an indication that no authentication information
1414 A resolver SHOULD expect authentication information from signed
1415 zones. A resolver SHOULD believe that a zone is signed if the
1416 resolver has been configured with public key information for the
1417 zone, or if the zone's parent is signed and the delegation from the
1418 parent contains a DS RRset.
1420 5.1. Special Considerations for Islands of Security
1422 Islands of security (see [RFC4033]) are signed zones for which it is
1423 not possible to construct an authentication chain to the zone from
1424 its parent. Validating signatures within an island of security
1425 requires that the validator have some other means of obtaining an
1426 initial authenticated zone key for the island. If a validator cannot
1427 obtain such a key, it SHOULD switch to operating as if the zones in
1428 the island of security are unsigned.
1430 All the normal processes for validating responses apply to islands of
1431 security. The only difference between normal validation and
1432 validation within an island of security is in how the validator
1433 obtains a trust anchor for the authentication chain.
1435 5.2. Authenticating Referrals
1437 Once the apex DNSKEY RRset for a signed parent zone has been
1438 authenticated, DS RRsets can be used to authenticate the delegation
1439 to a signed child zone. A DS RR identifies a DNSKEY RR in the child
1440 zone's apex DNSKEY RRset and contains a cryptographic digest of the
1441 child zone's DNSKEY RR. Use of a strong cryptographic digest
1442 algorithm ensures that it is computationally infeasible for an
1443 adversary to generate a DNSKEY RR that matches the digest. Thus,
1444 authenticating the digest allows a resolver to authenticate the
1445 matching DNSKEY RR. The resolver can then use this child DNSKEY RR
1446 to authenticate the entire child apex DNSKEY RRset.
1448 Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
1449 can be authenticated if all of the following hold:
1451 o The DS RR has been authenticated using some DNSKEY RR in the
1452 parent's apex DNSKEY RRset (see Section 5.3).
1458 Arends, et al. Standards Track [Page 26]
1460 RFC 4035 DNSSEC Protocol Modifications March 2005
1463 o The Algorithm and Key Tag in the DS RR match the Algorithm field
1464 and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
1465 RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
1466 using the digest algorithm specified in the DS RR's Digest Type
1467 field, the resulting digest value matches the Digest field of the
1470 o The matching DNSKEY RR in the child zone has the Zone Flag bit
1471 set, the corresponding private key has signed the child zone's
1472 apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
1473 child zone's apex DNSKEY RRset.
1475 If the referral from the parent zone did not contain a DS RRset, the
1476 response should have included a signed NSEC RRset proving that no DS
1477 RRset exists for the delegated name (see Section 3.1.4). A
1478 security-aware resolver MUST query the name servers for the parent
1479 zone for the DS RRset if the referral includes neither a DS RRset nor
1480 a NSEC RRset proving that the DS RRset does not exist (see Section
1483 If the validator authenticates an NSEC RRset that proves that no DS
1484 RRset is present for this zone, then there is no authentication path
1485 leading from the parent to the child. If the resolver has an initial
1486 DNSKEY or DS RR that belongs to the child zone or to any delegation
1487 below the child zone, this initial DNSKEY or DS RR MAY be used to
1488 re-establish an authentication path. If no such initial DNSKEY or DS
1489 RR exists, the validator cannot authenticate RRsets in or below the
1492 If the validator does not support any of the algorithms listed in an
1493 authenticated DS RRset, then the resolver has no supported
1494 authentication path leading from the parent to the child. The
1495 resolver should treat this case as it would the case of an
1496 authenticated NSEC RRset proving that no DS RRset exists, as
1499 Note that, for a signed delegation, there are two NSEC RRs associated
1500 with the delegated name. One NSEC RR resides in the parent zone and
1501 can be used to prove whether a DS RRset exists for the delegated
1502 name. The second NSEC RR resides in the child zone and identifies
1503 which RRsets are present at the apex of the child zone. The parent
1504 NSEC RR and child NSEC RR can always be distinguished because the SOA
1505 bit will be set in the child NSEC RR and clear in the parent NSEC RR.
1506 A security-aware resolver MUST use the parent NSEC RR when attempting
1507 to prove that a DS RRset does not exist.
1514 Arends, et al. Standards Track [Page 27]
1516 RFC 4035 DNSSEC Protocol Modifications March 2005
1519 If the resolver does not support any of the algorithms listed in an
1520 authenticated DS RRset, then the resolver will not be able to verify
1521 the authentication path to the child zone. In this case, the
1522 resolver SHOULD treat the child zone as if it were unsigned.
1524 5.3. Authenticating an RRset with an RRSIG RR
1526 A validator can use an RRSIG RR and its corresponding DNSKEY RR to
1527 attempt to authenticate RRsets. The validator first checks the RRSIG
1528 RR to verify that it covers the RRset, has a valid time interval, and
1529 identifies a valid DNSKEY RR. The validator then constructs the
1530 canonical form of the signed data by appending the RRSIG RDATA
1531 (excluding the Signature Field) with the canonical form of the
1532 covered RRset. Finally, the validator uses the public key and
1533 signature to authenticate the signed data. Sections 5.3.1, 5.3.2,
1534 and 5.3.3 describe each step in detail.
1536 5.3.1. Checking the RRSIG RR Validity
1538 A security-aware resolver can use an RRSIG RR to authenticate an
1539 RRset if all of the following conditions hold:
1541 o The RRSIG RR and the RRset MUST have the same owner name and the
1544 o The RRSIG RR's Signer's Name field MUST be the name of the zone
1545 that contains the RRset.
1547 o The RRSIG RR's Type Covered field MUST equal the RRset's type.
1549 o The number of labels in the RRset owner name MUST be greater than
1550 or equal to the value in the RRSIG RR's Labels field.
1552 o The validator's notion of the current time MUST be less than or
1553 equal to the time listed in the RRSIG RR's Expiration field.
1555 o The validator's notion of the current time MUST be greater than or
1556 equal to the time listed in the RRSIG RR's Inception field.
1558 o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
1559 match the owner name, algorithm, and key tag for some DNSKEY RR in
1560 the zone's apex DNSKEY RRset.
1562 o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
1563 RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
1570 Arends, et al. Standards Track [Page 28]
1572 RFC 4035 DNSSEC Protocol Modifications March 2005
1575 It is possible for more than one DNSKEY RR to match the conditions
1576 above. In this case, the validator cannot predetermine which DNSKEY
1577 RR to use to authenticate the signature, and it MUST try each
1578 matching DNSKEY RR until either the signature is validated or the
1579 validator has run out of matching public keys to try.
1581 Note that this authentication process is only meaningful if the
1582 validator authenticates the DNSKEY RR before using it to validate
1583 signatures. The matching DNSKEY RR is considered to be authentic if:
1585 o the apex DNSKEY RRset containing the DNSKEY RR is considered
1588 o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
1589 and the DNSKEY RR either matches an authenticated DS RR from the
1590 parent zone or matches a trust anchor.
1592 5.3.2. Reconstructing the Signed Data
1594 Once the RRSIG RR has met the validity requirements described in
1595 Section 5.3.1, the validator has to reconstruct the original signed
1596 data. The original signed data includes RRSIG RDATA (excluding the
1597 Signature field) and the canonical form of the RRset. Aside from
1598 being ordered, the canonical form of the RRset might also differ from
1599 the received RRset due to DNS name compression, decremented TTLs, or
1600 wildcard expansion. The validator should use the following to
1601 reconstruct the original signed data:
1603 signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
1605 "|" denotes concatenation
1607 RRSIG_RDATA is the wire format of the RRSIG RDATA fields
1608 with the Signature field excluded and the Signer's Name
1611 RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
1613 name is calculated according to the function below
1615 class is the RRset's class
1617 type is the RRset type and all RRs in the class
1619 OrigTTL is the value from the RRSIG Original TTL field
1621 All names in the RDATA field are in canonical form
1626 Arends, et al. Standards Track [Page 29]
1628 RFC 4035 DNSSEC Protocol Modifications March 2005
1631 The set of all RR(i) is sorted into canonical order.
1633 To calculate the name:
1634 let rrsig_labels = the value of the RRSIG Labels field
1636 let fqdn = RRset's fully qualified domain name in
1639 let fqdn_labels = Label count of the fqdn above.
1641 if rrsig_labels = fqdn_labels,
1644 if rrsig_labels < fqdn_labels,
1645 name = "*." | the rightmost rrsig_label labels of the
1648 if rrsig_labels > fqdn_labels
1649 the RRSIG RR did not pass the necessary validation
1650 checks and MUST NOT be used to authenticate this
1653 The canonical forms for names and RRsets are defined in [RFC4034].
1655 NSEC RRsets at a delegation boundary require special processing.
1656 There are two distinct NSEC RRsets associated with a signed delegated
1657 name. One NSEC RRset resides in the parent zone, and specifies which
1658 RRsets are present at the parent zone. The second NSEC RRset resides
1659 at the child zone and identifies which RRsets are present at the apex
1660 in the child zone. The parent NSEC RRset and child NSEC RRset can
1661 always be distinguished as only a child NSEC RR will indicate that an
1662 SOA RRset exists at the name. When reconstructing the original NSEC
1663 RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
1664 be combined with NSEC RRs from the child zone. When reconstructing
1665 the original NSEC RRset for the apex of the child zone, the NSEC RRs
1666 MUST NOT be combined with NSEC RRs from the parent zone.
1668 Note that each of the two NSEC RRsets at a delegation point has a
1669 corresponding RRSIG RR with an owner name matching the delegated
1670 name, and each of these RRSIG RRs is authoritative data associated
1671 with the same zone that contains the corresponding NSEC RRset. If
1672 necessary, a resolver can tell these RRSIG RRs apart by checking the
1673 Signer's Name field.
1682 Arends, et al. Standards Track [Page 30]
1684 RFC 4035 DNSSEC Protocol Modifications March 2005
1687 5.3.3. Checking the Signature
1689 Once the resolver has validated the RRSIG RR as described in Section
1690 5.3.1 and reconstructed the original signed data as described in
1691 Section 5.3.2, the validator can attempt to use the cryptographic
1692 signature to authenticate the signed data, and thus (finally!)
1693 authenticate the RRset.
1695 The Algorithm field in the RRSIG RR identifies the cryptographic
1696 algorithm used to generate the signature. The signature itself is
1697 contained in the Signature field of the RRSIG RDATA, and the public
1698 key used to verify the signature is contained in the Public Key field
1699 of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034]
1700 provides a list of algorithm types and provides pointers to the
1701 documents that define each algorithm's use.
1703 Note that it is possible for more than one DNSKEY RR to match the
1704 conditions in Section 5.3.1. In this case, the validator can only
1705 determine which DNSKEY RR is correct by trying each matching public
1706 key until the validator either succeeds in validating the signature
1707 or runs out of keys to try.
1709 If the Labels field of the RRSIG RR is not equal to the number of
1710 labels in the RRset's fully qualified owner name, then the RRset is
1711 either invalid or the result of wildcard expansion. The resolver
1712 MUST verify that wildcard expansion was applied properly before
1713 considering the RRset to be authentic. Section 5.3.4 describes how
1714 to determine whether a wildcard was applied properly.
1716 If other RRSIG RRs also cover this RRset, the local resolver security
1717 policy determines whether the resolver also has to test these RRSIG
1718 RRs and how to resolve conflicts if these RRSIG RRs lead to differing
1721 If the resolver accepts the RRset as authentic, the validator MUST
1722 set the TTL of the RRSIG RR and each RR in the authenticated RRset to
1723 a value no greater than the minimum of:
1725 o the RRset's TTL as received in the response;
1727 o the RRSIG RR's TTL as received in the response;
1729 o the value in the RRSIG RR's Original TTL field; and
1731 o the difference of the RRSIG RR's Signature Expiration time and the
1738 Arends, et al. Standards Track [Page 31]
1740 RFC 4035 DNSSEC Protocol Modifications March 2005
1743 5.3.4. Authenticating a Wildcard Expanded RRset Positive Response
1745 If the number of labels in an RRset's owner name is greater than the
1746 Labels field of the covering RRSIG RR, then the RRset and its
1747 covering RRSIG RR were created as a result of wildcard expansion.
1748 Once the validator has verified the signature, as described in
1749 Section 5.3, it must take additional steps to verify the non-
1750 existence of an exact match or closer wildcard match for the query.
1751 Section 5.4 discusses these steps.
1753 Note that the response received by the resolver should include all
1754 NSEC RRs needed to authenticate the response (see Section 3.1.3).
1756 5.4. Authenticated Denial of Existence
1758 A resolver can use authenticated NSEC RRs to prove that an RRset is
1759 not present in a signed zone. Security-aware name servers should
1760 automatically include any necessary NSEC RRs for signed zones in
1761 their responses to security-aware resolvers.
1763 Denial of existence is determined by the following rules:
1765 o If the requested RR name matches the owner name of an
1766 authenticated NSEC RR, then the NSEC RR's type bit map field lists
1767 all RR types present at that owner name, and a resolver can prove
1768 that the requested RR type does not exist by checking for the RR
1769 type in the bit map. If the number of labels in an authenticated
1770 NSEC RR's owner name equals the Labels field of the covering RRSIG
1771 RR, then the existence of the NSEC RR proves that wildcard
1772 expansion could not have been used to match the request.
1774 o If the requested RR name would appear after an authenticated NSEC
1775 RR's owner name and before the name listed in that NSEC RR's Next
1776 Domain Name field according to the canonical DNS name order
1777 defined in [RFC4034], then no RRsets with the requested name exist
1778 in the zone. However, it is possible that a wildcard could be
1779 used to match the requested RR owner name and type, so proving
1780 that the requested RRset does not exist also requires proving that
1781 no possible wildcard RRset exists that could have been used to
1782 generate a positive response.
1784 In addition, security-aware resolvers MUST authenticate the NSEC
1785 RRsets that comprise the non-existence proof as described in Section
1788 To prove the non-existence of an RRset, the resolver must be able to
1789 verify both that the queried RRset does not exist and that no
1790 relevant wildcard RRset exists. Proving this may require more than
1794 Arends, et al. Standards Track [Page 32]
1796 RFC 4035 DNSSEC Protocol Modifications March 2005
1799 one NSEC RRset from the zone. If the complete set of necessary NSEC
1800 RRsets is not present in a response (perhaps due to message
1801 truncation), then a security-aware resolver MUST resend the query in
1802 order to attempt to obtain the full collection of NSEC RRs necessary
1803 to verify the non-existence of the requested RRset. As with all DNS
1804 operations, however, the resolver MUST bound the work it puts into
1805 answering any particular query.
1807 Since a validated NSEC RR proves the existence of both itself and its
1808 corresponding RRSIG RR, a validator MUST ignore the settings of the
1809 NSEC and RRSIG bits in an NSEC RR.
1811 5.5. Resolver Behavior When Signatures Do Not Validate
1813 If for whatever reason none of the RRSIGs can be validated, the
1814 response SHOULD be considered BAD. If the validation was being done
1815 to service a recursive query, the name server MUST return RCODE 2 to
1816 the originating client. However, it MUST return the full response if
1817 and only if the original query had the CD bit set. Also see Section
1818 4.7 on caching responses that do not validate.
1820 5.6. Authentication Example
1822 Appendix C shows an example of the authentication process.
1824 6. IANA Considerations
1826 [RFC4034] contains a review of the IANA considerations introduced by
1827 DNSSEC. The following are additional IANA considerations discussed
1830 [RFC2535] reserved the CD and AD bits in the message header. The
1831 meaning of the AD bit was redefined in [RFC3655], and the meaning of
1832 both the CD and AD bit are restated in this document. No new bits in
1833 the DNS message header are defined in this document.
1835 [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
1836 and defined its use. The use is restated but not altered in this
1839 7. Security Considerations
1841 This document describes how the DNS security extensions use public
1842 key cryptography to sign and authenticate DNS resource record sets.
1843 Please see [RFC4033] for terminology and general security
1844 considerations related to DNSSEC; see [RFC4034] for considerations
1845 specific to the DNSSEC resource record types.
1850 Arends, et al. Standards Track [Page 33]
1852 RFC 4035 DNSSEC Protocol Modifications March 2005
1855 An active attacker who can set the CD bit in a DNS query message or
1856 the AD bit in a DNS response message can use these bits to defeat the
1857 protection that DNSSEC attempts to provide to security-oblivious
1858 recursive-mode resolvers. For this reason, use of these control bits
1859 by a security-aware recursive-mode resolver requires a secure
1860 channel. See Sections 3.2.2 and 4.9 for further discussion.
1862 The protocol described in this document attempts to extend the
1863 benefits of DNSSEC to security-oblivious stub resolvers. However, as
1864 recovery from validation failures is likely to be specific to
1865 particular applications, the facilities that DNSSEC provides for stub
1866 resolvers may prove inadequate. Operators of security-aware
1867 recursive name servers will have to pay close attention to the
1868 behavior of the applications that use their services when choosing a
1869 local validation policy; failure to do so could easily result in the
1870 recursive name server accidentally denying service to the clients it
1871 is intended to support.
1875 This document was created from the input and ideas of the members of
1876 the DNS Extensions Working Group and working group mailing list. The
1877 editors would like to express their thanks for the comments and
1878 suggestions received during the revision of these security extension
1879 specifications. Although explicitly listing everyone who has
1880 contributed during the decade in which DNSSEC has been under
1881 development would be impossible, [RFC4033] includes a list of some of
1882 the participants who were kind enough to comment on these documents.
1886 9.1. Normative References
1888 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1889 STD 13, RFC 1034, November 1987.
1891 [RFC1035] Mockapetris, P., "Domain names - implementation and
1892 specification", STD 13, RFC 1035, November 1987.
1894 [RFC1122] Braden, R., "Requirements for Internet Hosts -
1895 Communication Layers", STD 3, RFC 1122, October 1989.
1897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1898 Requirement Levels", BCP 14, RFC 2119, March 1997.
1900 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1901 Specification", RFC 2181, July 1997.
1906 Arends, et al. Standards Track [Page 34]
1908 RFC 4035 DNSSEC Protocol Modifications March 2005
1911 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1912 (IPv6) Specification", RFC 2460, December 1998.
1914 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
1917 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
1920 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
1921 3225, December 2001.
1923 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
1924 message size requirements", RFC 3226, December 2001.
1926 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1927 Rose, "DNS Security Introduction and Requirements", RFC
1930 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1931 Rose, "Resource Records for DNS Security Extensions", RFC
1934 9.2. Informative References
1936 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1937 NCACHE)", RFC 2308, March 1998.
1939 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
1940 Extensions", RFC 2535, March 1999.
1942 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
1943 Update", RFC 3007, November 2000.
1945 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
1946 Authenticated Data (AD) bit", RFC 3655, November 2003.
1962 Arends, et al. Standards Track [Page 35]
1964 RFC 4035 DNSSEC Protocol Modifications March 2005
1967 Appendix A. Signed Zone Example
1969 The following example shows a (small) complete signed zone.
1971 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1978 3600 RRSIG SOA 5 1 3600 20040509183619 (
1979 20040409183619 38519 example.
1980 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
1981 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
1982 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
1983 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
1984 jV7j86HyQgM5e7+miRAz8V01b0I= )
1985 3600 NS ns1.example.
1986 3600 NS ns2.example.
1987 3600 RRSIG NS 5 1 3600 20040509183619 (
1988 20040409183619 38519 example.
1989 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
1990 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
1991 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
1992 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
1993 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
1994 3600 MX 1 xx.example.
1995 3600 RRSIG MX 5 1 3600 20040509183619 (
1996 20040409183619 38519 example.
1997 HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
1998 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
1999 VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
2000 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
2001 W6OISukd1EQt7a0kygkg+PEDxdI= )
2002 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
2003 3600 RRSIG NSEC 5 1 3600 20040509183619 (
2004 20040409183619 38519 example.
2005 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
2006 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
2007 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
2008 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
2009 jfFJ5arXf4nPxp/kEowGgBRzY/U= )
2010 3600 DNSKEY 256 3 5 (
2011 AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
2012 rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
2013 k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
2014 vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
2018 Arends, et al. Standards Track [Page 36]
2020 RFC 4035 DNSSEC Protocol Modifications March 2005
2023 ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
2025 3600 DNSKEY 257 3 5 (
2026 AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
2027 LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
2028 syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
2029 RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
2030 Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
2032 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
2033 20040409183619 9465 example.
2034 ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
2035 xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
2036 XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
2037 hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
2038 NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
2039 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
2040 20040409183619 38519 example.
2041 eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
2042 DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
2043 bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
2044 eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
2045 7z5OXogYVaFzHKillDt3HRxHIZM= )
2046 a.example. 3600 IN NS ns1.a.example.
2047 3600 IN NS ns2.a.example.
2049 B6DCD485719ADCA18E5F3D48A2331627FDD3
2051 3600 RRSIG DS 5 2 3600 20040509183619 (
2052 20040409183619 38519 example.
2053 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
2054 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
2055 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
2056 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
2057 Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
2058 3600 NSEC ai.example. NS DS RRSIG NSEC
2059 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2060 20040409183619 38519 example.
2061 cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
2062 U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
2063 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
2064 BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
2065 sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
2066 ns1.a.example. 3600 IN A 192.0.2.5
2067 ns2.a.example. 3600 IN A 192.0.2.6
2068 ai.example. 3600 IN A 192.0.2.9
2069 3600 RRSIG A 5 2 3600 20040509183619 (
2070 20040409183619 38519 example.
2074 Arends, et al. Standards Track [Page 37]
2076 RFC 4035 DNSSEC Protocol Modifications March 2005
2079 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
2080 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
2081 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
2082 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
2083 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
2084 3600 HINFO "KLH-10" "ITS"
2085 3600 RRSIG HINFO 5 2 3600 20040509183619 (
2086 20040409183619 38519 example.
2087 Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
2088 e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
2089 ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
2090 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
2091 FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
2092 3600 AAAA 2001:db8::f00:baa9
2093 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2094 20040409183619 38519 example.
2095 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
2096 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
2097 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
2098 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
2099 sZM6QjBBLmukH30+w1z3h8PUP2o= )
2100 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
2101 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2102 20040409183619 38519 example.
2103 QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
2104 CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
2105 P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
2106 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
2107 AhS+JOVfDI/79QtyTI0SaDWcg8U= )
2108 b.example. 3600 IN NS ns1.b.example.
2109 3600 IN NS ns2.b.example.
2110 3600 NSEC ns1.example. NS RRSIG NSEC
2111 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2112 20040409183619 38519 example.
2113 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
2114 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
2115 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
2116 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
2117 vhRXgWT7OuFXldoCG6TfVFMs9xE= )
2118 ns1.b.example. 3600 IN A 192.0.2.7
2119 ns2.b.example. 3600 IN A 192.0.2.8
2120 ns1.example. 3600 IN A 192.0.2.1
2121 3600 RRSIG A 5 2 3600 20040509183619 (
2122 20040409183619 38519 example.
2123 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
2124 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
2125 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
2126 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
2130 Arends, et al. Standards Track [Page 38]
2132 RFC 4035 DNSSEC Protocol Modifications March 2005
2135 v/iVXSYC0b7mPSU+EOlknFpVECs= )
2136 3600 NSEC ns2.example. A RRSIG NSEC
2137 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2138 20040409183619 38519 example.
2139 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
2140 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
2141 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
2142 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
2143 IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
2144 ns2.example. 3600 IN A 192.0.2.2
2145 3600 RRSIG A 5 2 3600 20040509183619 (
2146 20040409183619 38519 example.
2147 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
2148 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
2149 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
2150 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
2151 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
2152 3600 NSEC *.w.example. A RRSIG NSEC
2153 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2154 20040409183619 38519 example.
2155 N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
2156 VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
2157 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
2158 l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
2159 Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
2160 *.w.example. 3600 IN MX 1 ai.example.
2161 3600 RRSIG MX 5 2 3600 20040509183619 (
2162 20040409183619 38519 example.
2163 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
2164 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
2165 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
2166 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
2167 4kX18MMR34i8lC36SR5xBni8vHI= )
2168 3600 NSEC x.w.example. MX RRSIG NSEC
2169 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2170 20040409183619 38519 example.
2171 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
2172 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
2173 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
2174 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
2175 s1InQ2UoIv6tJEaaKkP701j8OLA= )
2176 x.w.example. 3600 IN MX 1 xx.example.
2177 3600 RRSIG MX 5 3 3600 20040509183619 (
2178 20040409183619 38519 example.
2179 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
2180 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
2181 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
2182 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
2186 Arends, et al. Standards Track [Page 39]
2188 RFC 4035 DNSSEC Protocol Modifications March 2005
2191 jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
2192 3600 NSEC x.y.w.example. MX RRSIG NSEC
2193 3600 RRSIG NSEC 5 3 3600 20040509183619 (
2194 20040409183619 38519 example.
2195 aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
2196 vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
2197 mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
2198 NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
2199 IjgiM8PXkBQtxPq37wDKALkyn7Q= )
2200 x.y.w.example. 3600 IN MX 1 xx.example.
2201 3600 RRSIG MX 5 4 3600 20040509183619 (
2202 20040409183619 38519 example.
2203 k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
2204 t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
2205 q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
2206 GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
2207 +gLcMZBnHJ326nb/TOOmrqNmQQE= )
2208 3600 NSEC xx.example. MX RRSIG NSEC
2209 3600 RRSIG NSEC 5 4 3600 20040509183619 (
2210 20040409183619 38519 example.
2211 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
2212 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
2213 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
2214 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
2215 QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
2216 xx.example. 3600 IN A 192.0.2.10
2217 3600 RRSIG A 5 2 3600 20040509183619 (
2218 20040409183619 38519 example.
2219 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
2220 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
2221 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
2222 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
2223 kbIDV6GPPSZVusnZU6OMgdgzHV4= )
2224 3600 HINFO "KLH-10" "TOPS-20"
2225 3600 RRSIG HINFO 5 2 3600 20040509183619 (
2226 20040409183619 38519 example.
2227 GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
2228 t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
2229 BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
2230 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
2231 RgNvuwbioFSEuv2pNlkq0goYxNY= )
2232 3600 AAAA 2001:db8::f00:baaa
2233 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2234 20040409183619 38519 example.
2235 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
2236 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
2237 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
2238 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
2242 Arends, et al. Standards Track [Page 40]
2244 RFC 4035 DNSSEC Protocol Modifications March 2005
2247 xS9cL2QgW7FChw16mzlkH6/vsfs= )
2248 3600 NSEC example. A HINFO AAAA RRSIG NSEC
2249 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2250 20040409183619 38519 example.
2251 ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
2252 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
2253 mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
2254 asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
2255 GghLahumFIpg4MO3LS/prgzVVWo= )
2257 The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
2258 Flags indicate that each of these DNSKEY RRs is a zone key. One of
2259 these DNSKEY RRs also has the SEP flag set and has been used to sign
2260 the apex DNSKEY RRset; this is the key that should be hashed to
2261 generate a DS record to be inserted into the parent zone. The other
2262 DNSKEY is used to sign all the other RRsets in the zone.
2264 The zone includes a wildcard entry, "*.w.example". Note that the
2265 name "*.w.example" is used in constructing NSEC chains, and that the
2266 RRSIG covering the "*.w.example" MX RRset has a label count of 2.
2268 The zone also includes two delegations. The delegation to
2269 "b.example" includes an NS RRset, glue address records, and an NSEC
2270 RR; note that only the NSEC RRset is signed. The delegation to
2271 "a.example" provides a DS RR; note that only the NSEC and DS RRsets
2274 Appendix B. Example Responses
2276 The examples in this section show response messages using the signed
2277 zone example in Appendix A.
2281 A successful query to an authoritative server.
2283 ;; Header: QR AA DO RCODE=0
2289 x.w.example. 3600 IN MX 1 xx.example.
2290 x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
2291 20040409183619 38519 example.
2292 Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
2293 XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
2294 H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
2298 Arends, et al. Standards Track [Page 41]
2300 RFC 4035 DNSSEC Protocol Modifications March 2005
2303 kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
2304 jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
2307 example. 3600 NS ns1.example.
2308 example. 3600 NS ns2.example.
2309 example. 3600 RRSIG NS 5 1 3600 20040509183619 (
2310 20040409183619 38519 example.
2311 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
2312 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
2313 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
2314 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
2315 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
2318 xx.example. 3600 IN A 192.0.2.10
2319 xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2320 20040409183619 38519 example.
2321 kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
2322 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
2323 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
2324 VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
2325 kbIDV6GPPSZVusnZU6OMgdgzHV4= )
2326 xx.example. 3600 AAAA 2001:db8::f00:baaa
2327 xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2328 20040409183619 38519 example.
2329 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
2330 aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
2331 ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
2332 U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
2333 xS9cL2QgW7FChw16mzlkH6/vsfs= )
2334 ns1.example. 3600 IN A 192.0.2.1
2335 ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2336 20040409183619 38519 example.
2337 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
2338 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
2339 im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
2340 +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
2341 v/iVXSYC0b7mPSU+EOlknFpVECs= )
2342 ns2.example. 3600 IN A 192.0.2.2
2343 ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2344 20040409183619 38519 example.
2345 V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
2346 Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
2347 yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
2348 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
2349 rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
2354 Arends, et al. Standards Track [Page 42]
2356 RFC 4035 DNSSEC Protocol Modifications March 2005
2361 An authoritative name error. The NSEC RRs prove that the name does
2362 not exist and that no covering wildcard exists.
2364 ;; Header: QR AA DO RCODE=3
2373 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2380 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2381 20040409183619 38519 example.
2382 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2383 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2384 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2385 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2386 jV7j86HyQgM5e7+miRAz8V01b0I= )
2387 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
2388 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2389 20040409183619 38519 example.
2390 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
2391 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
2392 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
2393 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
2394 vhRXgWT7OuFXldoCG6TfVFMs9xE= )
2395 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
2396 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
2397 20040409183619 38519 example.
2398 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
2399 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
2400 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
2401 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
2402 jfFJ5arXf4nPxp/kEowGgBRzY/U= )
2410 Arends, et al. Standards Track [Page 43]
2412 RFC 4035 DNSSEC Protocol Modifications March 2005
2417 A "no data" response. The NSEC RR proves that the name exists and
2418 that the requested RR type does not.
2420 ;; Header: QR AA DO RCODE=0
2429 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2436 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2437 20040409183619 38519 example.
2438 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2439 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2440 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2441 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2442 jV7j86HyQgM5e7+miRAz8V01b0I= )
2443 ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
2444 ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2445 20040409183619 38519 example.
2446 I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
2447 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
2448 jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
2449 ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
2450 IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
2455 B.4. Referral to Signed Zone
2457 Referral to a signed zone. The DS RR contains the data which the
2458 resolver will need to validate the corresponding DNSKEY RR in the
2461 ;; Header: QR DO RCODE=0
2466 Arends, et al. Standards Track [Page 44]
2468 RFC 4035 DNSSEC Protocol Modifications March 2005
2478 a.example. 3600 IN NS ns1.a.example.
2479 a.example. 3600 IN NS ns2.a.example.
2480 a.example. 3600 DS 57855 5 1 (
2481 B6DCD485719ADCA18E5F3D48A2331627FDD3
2483 a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
2484 20040409183619 38519 example.
2485 oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
2486 oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
2487 kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
2488 EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
2489 Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
2492 ns1.a.example. 3600 IN A 192.0.2.5
2493 ns2.a.example. 3600 IN A 192.0.2.6
2495 B.5. Referral to Unsigned Zone
2497 Referral to an unsigned zone. The NSEC RR proves that no DS RR for
2498 this delegation exists in the parent zone.
2500 ;; Header: QR DO RCODE=0
2509 b.example. 3600 IN NS ns1.b.example.
2510 b.example. 3600 IN NS ns2.b.example.
2511 b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
2512 b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2513 20040409183619 38519 example.
2514 GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
2515 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
2516 xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
2517 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
2518 vhRXgWT7OuFXldoCG6TfVFMs9xE= )
2522 Arends, et al. Standards Track [Page 45]
2524 RFC 4035 DNSSEC Protocol Modifications March 2005
2528 ns1.b.example. 3600 IN A 192.0.2.7
2529 ns2.b.example. 3600 IN A 192.0.2.8
2531 B.6. Wildcard Expansion
2533 A successful query that was answered via wildcard expansion. The
2534 label count in the answer's RRSIG RR indicates that a wildcard RRset
2535 was expanded to produce this response, and the NSEC RR proves that no
2536 closer match exists in the zone.
2538 ;; Header: QR AA DO RCODE=0
2541 a.z.w.example. IN MX
2544 a.z.w.example. 3600 IN MX 1 ai.example.
2545 a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
2546 20040409183619 38519 example.
2547 OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
2548 f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
2549 tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
2550 TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
2551 4kX18MMR34i8lC36SR5xBni8vHI= )
2554 example. 3600 NS ns1.example.
2555 example. 3600 NS ns2.example.
2556 example. 3600 RRSIG NS 5 1 3600 20040509183619 (
2557 20040409183619 38519 example.
2558 gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
2559 EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
2560 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
2561 RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
2562 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
2563 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
2564 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
2565 20040409183619 38519 example.
2566 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
2567 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
2568 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
2569 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
2570 QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
2573 ai.example. 3600 IN A 192.0.2.9
2574 ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
2578 Arends, et al. Standards Track [Page 46]
2580 RFC 4035 DNSSEC Protocol Modifications March 2005
2583 20040409183619 38519 example.
2584 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
2585 ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
2586 hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
2587 ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
2588 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
2589 ai.example. 3600 AAAA 2001:db8::f00:baa9
2590 ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
2591 20040409183619 38519 example.
2592 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
2593 kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
2594 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
2595 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
2596 sZM6QjBBLmukH30+w1z3h8PUP2o= )
2598 B.7. Wildcard No Data Error
2600 A "no data" response for a name covered by a wildcard. The NSEC RRs
2601 prove that the matching wildcard name does not have any RRs of the
2602 requested type and that no closer match exists in the zone.
2604 ;; Header: QR AA DO RCODE=0
2607 a.z.w.example. IN AAAA
2613 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2620 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2621 20040409183619 38519 example.
2622 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2623 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2624 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2625 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2626 jV7j86HyQgM5e7+miRAz8V01b0I= )
2627 x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
2628 x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
2629 20040409183619 38519 example.
2630 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
2634 Arends, et al. Standards Track [Page 47]
2636 RFC 4035 DNSSEC Protocol Modifications March 2005
2639 ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
2640 xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
2641 a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
2642 QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
2643 *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
2644 *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
2645 20040409183619 38519 example.
2646 r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
2647 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
2648 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
2649 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
2650 s1InQ2UoIv6tJEaaKkP701j8OLA= )
2655 B.8. DS Child Zone No Data Error
2657 A "no data" response for a QTYPE=DS query that was mistakenly sent to
2658 a name server for the child zone.
2660 ;; Header: QR AA DO RCODE=0
2669 example. 3600 IN SOA ns1.example. bugs.x.w.example. (
2676 example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
2677 20040409183619 38519 example.
2678 ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
2679 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
2680 vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
2681 DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
2682 jV7j86HyQgM5e7+miRAz8V01b0I= )
2683 example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
2684 example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
2685 20040409183619 38519 example.
2686 O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
2690 Arends, et al. Standards Track [Page 48]
2692 RFC 4035 DNSSEC Protocol Modifications March 2005
2695 FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
2696 Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
2697 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
2698 jfFJ5arXf4nPxp/kEowGgBRzY/U= )
2703 Appendix C. Authentication Examples
2705 The examples in this section show how the response messages in
2706 Appendix B are authenticated.
2708 C.1. Authenticating an Answer
2710 The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
2711 The corresponding RRSIG indicates that the MX RRset was signed by an
2712 "example" DNSKEY with algorithm 5 and key tag 38519. The resolver
2713 needs the corresponding DNSKEY RR in order to authenticate this
2714 answer. The discussion below describes how a resolver might obtain
2717 The RRSIG indicates the original TTL of the MX RRset was 3600, and,
2718 for the purpose of authentication, the current TTL is replaced by
2719 3600. The RRSIG labels field value of 3 indicates that the answer
2720 was not the result of wildcard expansion. The "x.w.example.com" MX
2721 RRset is placed in canonical form, and, assuming the current time
2722 falls between the signature inception and expiration dates, the
2723 signature is authenticated.
2725 C.1.1. Authenticating the Example DNSKEY RR
2727 This example shows the logical authentication process that starts
2728 from the a configured root DNSKEY (or DS RR) and moves down the tree
2729 to authenticate the desired "example" DNSKEY RR. Note that the
2730 logical order is presented for clarity. An implementation may choose
2731 to construct the authentication as referrals are received or to
2732 construct the authentication chain only after all RRsets have been
2733 obtained, or in any other combination it sees fit. The example here
2734 demonstrates only the logical process and does not dictate any
2735 implementation rules.
2737 We assume the resolver starts with a configured DNSKEY RR for the
2738 root zone (or a configured DS RR for the root zone). The resolver
2739 checks whether this configured DNSKEY RR is present in the root
2740 DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
2741 DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
2742 RRset, and whether the signature lifetime is valid. If all these
2746 Arends, et al. Standards Track [Page 49]
2748 RFC 4035 DNSSEC Protocol Modifications March 2005
2751 conditions are met, all keys in the DNSKEY RRset are considered
2752 authenticated. The resolver then uses one (or more) of the root
2753 DNSKEY RRs to authenticate the "example" DS RRset. Note that the
2754 resolver may have to query the root zone to obtain the root DNSKEY
2755 RRset or "example" DS RRset.
2757 Once the DS RRset has been authenticated using the root DNSKEY, the
2758 resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
2759 RR that matches one of the authenticated "example" DS RRs. If such a
2760 matching "example" DNSKEY is found, the resolver checks whether this
2761 DNSKEY RR has signed the "example" DNSKEY RRset and the signature
2762 lifetime is valid. If these conditions are met, all keys in the
2763 "example" DNSKEY RRset are considered authenticated.
2765 Finally, the resolver checks that some DNSKEY RR in the "example"
2766 DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
2767 DNSKEY is used to authenticate the RRSIG included in the response.
2768 If multiple "example" DNSKEY RRs match this algorithm and key tag,
2769 then each DNSKEY RR is tried, and the answer is authenticated if any
2770 of the matching DNSKEY RRs validate the signature as described above.
2774 The query in Appendix B.2 returned NSEC RRs that prove that the
2775 requested data does not exist and no wildcard applies. The negative
2776 reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
2777 authenticated in a manner identical to that of the MX RRset discussed
2782 The query in Appendix B.3 returned an NSEC RR that proves that the
2783 requested name exists, but the requested RR type does not exist. The
2784 negative reply is authenticated by verifying the NSEC RR. The NSEC
2785 RR is authenticated in a manner identical to that of the MX RRset
2788 C.4. Referral to Signed Zone
2790 The query in Appendix B.4 returned a referral to the signed
2791 "a.example." zone. The DS RR is authenticated in a manner identical
2792 to that of the MX RRset discussed above. This DS RR is used to
2793 authenticate the "a.example" DNSKEY RRset.
2795 Once the "a.example" DS RRset has been authenticated using the
2796 "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
2797 for some "a.example" DNSKEY RR that matches the DS RR. If such a
2798 matching "a.example" DNSKEY is found, the resolver checks whether
2802 Arends, et al. Standards Track [Page 50]
2804 RFC 4035 DNSSEC Protocol Modifications March 2005
2807 this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
2808 the signature lifetime is valid. If all these conditions are met,
2809 all keys in the "a.example" DNSKEY RRset are considered
2812 C.5. Referral to Unsigned Zone
2814 The query in Appendix B.5 returned a referral to an unsigned
2815 "b.example." zone. The NSEC proves that no authentication leads from
2816 "example" to "b.example", and the NSEC RR is authenticated in a
2817 manner identical to that of the MX RRset discussed above.
2819 C.6. Wildcard Expansion
2821 The query in Appendix B.6 returned an answer that was produced as a
2822 result of wildcard expansion. The answer section contains a wildcard
2823 RRset expanded as it would be in a traditional DNS response, and the
2824 corresponding RRSIG indicates that the expanded wildcard MX RRset was
2825 signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
2826 The RRSIG indicates that the original TTL of the MX RRset was 3600,
2827 and, for the purpose of authentication, the current TTL is replaced
2828 by 3600. The RRSIG labels field value of 2 indicates that the answer
2829 is the result of wildcard expansion, as the "a.z.w.example" name
2830 contains 4 labels. The name "a.z.w.w.example" is replaced by
2831 "*.w.example", the MX RRset is placed in canonical form, and,
2832 assuming that the current time falls between the signature inception
2833 and expiration dates, the signature is authenticated.
2835 The NSEC proves that no closer match (exact or closer wildcard) could
2836 have been used to answer this query, and the NSEC RR must also be
2837 authenticated before the answer is considered valid.
2839 C.7. Wildcard No Data Error
2841 The query in Appendix B.7 returned NSEC RRs that prove that the
2842 requested data does not exist and no wildcard applies. The negative
2843 reply is authenticated by verifying both NSEC RRs.
2845 C.8. DS Child Zone No Data Error
2847 The query in Appendix B.8 returned NSEC RRs that shows the requested
2848 was answered by a child server ("example" server). The NSEC RR
2849 indicates the presence of an SOA RR, showing that the answer is from
2850 the child . Queries for the "example" DS RRset should be sent to the
2851 parent servers ("root" servers).
2858 Arends, et al. Standards Track [Page 51]
2860 RFC 4035 DNSSEC Protocol Modifications March 2005
2866 Telematica Instituut
2871 EMail: roy.arends@telin.nl
2875 Internet Systems Consortium
2877 Redwood City, CA 94063
2885 21345 Ridgetop Circle
2886 Dulles, VA 20166-6503
2889 EMail: mlarson@verisign.com
2893 Colorado State University
2894 Department of Computer Science
2895 Fort Collins, CO 80523-1873
2897 EMail: massey@cs.colostate.edu
2901 National Institute for Standards and Technology
2903 Gaithersburg, MD 20899-8920
2906 EMail: scott.rose@nist.gov
2914 Arends, et al. Standards Track [Page 52]
2916 RFC 4035 DNSSEC Protocol Modifications March 2005
2919 Full Copyright Statement
2921 Copyright (C) The Internet Society (2005).
2923 This document is subject to the rights, licenses and restrictions
2924 contained in BCP 78, and except as set forth therein, the authors
2925 retain all their rights.
2927 This document and the information contained herein are provided on an
2928 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2929 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2930 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2931 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2932 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2933 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2935 Intellectual Property
2937 The IETF takes no position regarding the validity or scope of any
2938 Intellectual Property Rights or other rights that might be claimed to
2939 pertain to the implementation or use of the technology described in
2940 this document or the extent to which any license under such rights
2941 might or might not be available; nor does it represent that it has
2942 made any independent effort to identify any such rights. Information
2943 on the procedures with respect to rights in RFC documents can be
2944 found in BCP 78 and BCP 79.
2946 Copies of IPR disclosures made to the IETF Secretariat and any
2947 assurances of licenses to be made available, or the result of an
2948 attempt made to obtain a general license or permission for the use of
2949 such proprietary rights by implementers or users of this
2950 specification can be obtained from the IETF on-line IPR repository at
2951 http://www.ietf.org/ipr.
2953 The IETF invites any interested party to bring to its attention any
2954 copyrights, patents or patent applications, or other proprietary
2955 rights that may cover technology that may be required to implement
2956 this standard. Please address the information to the IETF at ietf-
2961 Funding for the RFC Editor function is currently provided by the
2970 Arends, et al. Standards Track [Page 53]
projects / FreeBSD / releng / 7.2.git / blob