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]
added
removed
doc/rfc/rfc4035.txt
