idnits 2.17.1 draft-ietf-dnsext-dnssec-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' introduction to DNSSEC and definition of common terms can be found' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' security considerations.' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5. IANA Considerations' ) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC2535, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 499 has weird spacing: '...ere was no ex...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2002) is 7846 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '8' on line 1107 looks like a reference -- Missing reference section? '9' on line 1110 looks like a reference -- Missing reference section? '1' on line 1086 looks like a reference -- Missing reference section? '2' on line 1089 looks like a reference -- Missing reference section? '4' on line 1095 looks like a reference -- Missing reference section? '6' on line 1101 looks like a reference -- Missing reference section? '3' on line 1092 looks like a reference -- Missing reference section? '5' on line 1098 looks like a reference -- Missing reference section? '7' on line 1104 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft 4 Expires: April 25, 2003 M. Larson 5 VeriSign 6 D. Massey 7 USC/ISI 8 S. Rose 9 NIST 10 October 25, 2002 12 Protocol Modifications for the DNS Security Extensions 13 draft-ietf-dnsext-dnssec-protocol-00 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 25, 2003. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 This document is part of a family of documents that describe the 46 DNS Security Extensions (DNSSEC). The DNS Security Extensions are 47 a collection of new resource records and protocol modifications 48 that provide source authentication for the DNS. This document 49 describes the DNSSEC protocol modifications. The concept of zone 50 signing is introduced and the zone format is modified to include 51 KEY, SIG, NXT, and DS resource records. If a resolver indicates 52 support for DNSSEC, the response process is modified to include 53 the appropriate KEY, SIG, NXT, and DS resource records. These 54 resource records are used by the resolver to authenticate the 55 response. 57 This document obsoletes RFC 2535 and incorporates changes from all 58 updates to RFC 2535. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 64 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 67 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 5 68 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 69 2. Zone Signing and Zone Format . . . . . . . . . . . . . . . . 6 70 2.1 Inclusion of KEY RRs in a Zone . . . . . . . . . . . . . . . 7 71 2.2 Inclusion of NXT RRs in a Zone . . . . . . . . . . . . . . . 7 72 2.3 Inclusion of SIG RRs in a Zone . . . . . . . . . . . . . . . 7 73 2.4 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 74 2.5 Inclusion of DS RRs in a Zone . . . . . . . . . . . . . . . 8 75 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 76 3. Constructing DNS Responses . . . . . . . . . . . . . . . . . 10 77 3.1 Indicating Resolver Support for DNSSEC . . . . . . . . . . . 10 78 3.2 Inclusion of SIG RRs in a Response . . . . . . . . . . . . . 11 79 3.3 Inclusion of KEY RRs In a Response . . . . . . . . . . . . . 12 80 3.4 Inclusion of NXT RRs In a Response . . . . . . . . . . . . . 12 81 3.4.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12 82 3.4.2 Case 2: Query Name Does Not Exist and No Wildcard Matches . 13 83 3.4.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13 84 3.5 Inclusion of DS RRs In a Response . . . . . . . . . . . . . 13 85 3.6 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13 86 3.7 Special Considerations for Recursive/Caching Servers . . . . 15 87 3.8 Setting the AD and CD Bits in a Response . . . . . . . . . . 15 88 3.9 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16 89 4. Authenticating DNS Responses . . . . . . . . . . . . . . . . 17 90 4.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 18 91 4.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 19 92 4.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 19 93 4.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 20 94 4.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 22 95 4.2.4 Authenticating Wildcard Expanded RRset . . . . . . . . . . . 23 96 4.3 Authenticated Denial of Existence . . . . . . . . . . . . . 23 97 4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 4.4.1 Example of Re-Constructing the Original Name . . . . . . . . 24 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 100 6. Security Considerations . . . . . . . . . . . . . . . . . . 27 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 102 References . . . . . . . . . . . . . . . . . . . . . . . . . 29 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 104 A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 31 105 Full Copyright Statement . . . . . . . . . . . . . . . . . . 32 107 1. Introduction 109 The DNS Security Extensions (DNSSEC) modify several aspects of the 110 DNS protocol. The concept of zone signing is introduced and the 111 zone format is modified to include KEY, SIG, NXT, and DS resource 112 records as described in Section 2. If the resolver has indicated 113 support for DNSSEC, the process of constructing a DNS response is 114 also modified to include the appropriate KEY, SIG, NXT, and DS RR 115 types. Section 3 defines how a resolver indicates support for 116 DNSSEC, describes how the DNSSEC RR types are included in a 117 response, and also describes the specgal processing rules required 118 to handle queries for the DS RR type. Finally, Section 4 defines 119 how a resolver uses the DNSSEC RRs to authenticate a response. 121 1.1 Background and Related Documents 123 This document is part of a family of documents that define the DNS 124 security extensions. The DNS security extensions (DNSSEC) are a 125 collection of resource records and DNS protocol modifications that 126 add source authentication the Domain Name System (DNS). An 127 introduction to DNSSEC and definition of common terms can be found 128 in [8]. A definition of the DNSSEC resource records can be found 129 in [9]. This document defines the DNSSEC protocol modificatinos. 131 The reader to assumed to be familiar with the basic DNS concepts 132 described in RFC1034 [1] and RFC1035 [2] and should also be 133 familiar with common DNSSEC terminology as defined in [8]. 135 1.2 Reserved Words 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 138 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 RFC 2119. [4]. 142 1.3 Editors Notes 144 1.3.1 Open Technical Issues 146 The use of the NXT record requires input from the working group. 147 Although the opt-in issue is not resolved, progress on this 148 document was still needed. This text describes the NXT record as 149 it was defined in RFC 2535 and substantial portions of this 150 document would need to be updated to incorporate opt-in. The 151 updates will be made if opt-in is adopted. 153 The use of the AD bit is described in section 3.8 and requires 154 input from the working group. Since the AD bit usage is not 155 resolved, this text attempts to capture current ideas and drafts, 156 but further input from the working group is required. 158 1.3.2 Technical Changes or Corrections 160 Please report technical corrections to dnssec- 161 editors@east.isi.edu. To assist the editors, please indicate the 162 text in error and point out the RFC that defines the correct 163 behavior. For a technical change where there is no RFC that 164 defines the correct behavior (or RFCs provide conflicting 165 answers), please post the issue to namedroppers. 167 An example correction to dnssec-editors might be: Page X says 168 "DNSSEC RRs SHOULD be automatically returned in responses." This 169 was true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says 170 the DNSSEC RR types MUST NOT be included in responses unless the 171 resolver indicated support for DNSSEC. 173 1.3.3 Typos and Minor Corrections 175 Please report any typos corrections to dnssec- 176 editors@east.isi.edu. To assist the editors, please provide 177 enough context for us to quickly find the incorrect text. 179 An example message to dnssec-editors might be: page X says "the 180 DNSSEC standard has been in development for over 1 years". It 181 should read "over 10 years". 183 2. Zone Signing and Zone Format 185 DNSSEC defines a new process called zone signing and adds the KEY, 186 SIG, NXT, and DS resource records to the zone format. The zone 187 signing process is the first step in enabling resource record 188 authentication for this zone. After a signed zone has been 189 created and loaded, the KEY, SIG, NXT, and DS resource records can 190 be included in responses (as decribed in Section 3) and can be 191 used by resolvers to authenticate responses (as describe in 192 Section 4). KEY, SIG, NXT, and DS RRs MUST NOT appear in unsigned 193 zones. 195 To sign a zone, the zone administrator generates one or more 196 public/private key pairs. The zone's public key(s) are made 197 available by storing them in KEY resource records. Other DNS 198 public keys, such as public keys used by TKEY and SIG(0), can also 199 be stored in KEY RRs. Once the KEY records have been added to the 200 zone, the zone is sorted into a canonical form and NXT resource 201 records are added to enable authenticated denial of existence. 202 The zone administrator then signs every authoritative RRset in the 203 zone using the private key(s) and the signatures are stored in SIG 204 resource records. The resulting signed zone contains all data in 205 the original (unsigned) zone and also includes the new KEY, NXT, 206 and SIG RRs. 208 Section 2.1, Section 2.2, and Section 2.3 present the rules for 209 the including the KEY, NXT, and SIG resource records in a zone 210 (respectively). 212 The zone signing process also requires a change in the definition 213 of the CNAME resource record and Section 2.4 changes the CNAME RR 214 to allow SIG and NXT RRs to appear along with the CNAME RR. 216 To enable authentication chains between DNS zones, a signed zone 217 includes DS Resource Records for its signed delegations. Section 218 2.5 presents the rules for including DS resource records. 220 Note that if a resource record in a signed zone is added, 221 modified, or deleted, the signatures associaates with this RRset 222 MUST be updated and the NXT RR associated with the RRset's owner 223 name MUST also be updated. In addition, the zone MUST be 224 periodically resigned in order to maintain current SIG expiration 225 dates and the zone keys SHOULD change periodically. DNSSEC best 226 practices documents are encouraged to provide recommendations for 227 signature and key lifetimes. 229 2.1 Inclusion of KEY RRs in a Zone 231 A zone administrator generates a set of public/private key pairs 232 and uses the private key(s) to sign authoritative RRsets in the 233 zone. For each private zone key used to create SIG RRs, there 234 SHOULD be a corresponding public KEY RR stored at the zone apex 235 and the corresponding KEY RR MUST have the Zone Key Flag (KEY 236 RDATA Flag bit 7) set to 1. KEY RR's with Zone Flag set MUST only 237 appear at the zone apex. 239 A signed zone MUST have at least one zone KEY RR in its apex KEY 240 set and the apex KEY set MUST be self-signed by at least one 241 private key whose corresponding public zone KEY RR is stored in 242 the apex KEY set. 244 Other DNS public keys, such as those used by TKEY and SIG, can be 245 stored in the zone using non-Zone KEY RR's (KEY RDATA Flag bit 7 246 set to 0). Non-zone KEY RR's MUST NOT appear at delegation names, 247 but MAY appear at any other authoritative name in the zone. A 248 non-zone KEY RR SHOULD NOT appear at the apex name since this 249 could lead to large apex KEY sets and requires added processing 250 time at resolvers. 252 2.2 Inclusion of NXT RRs in a Zone 254 Each authoritative name in the zone MUST have an NXT resource 255 record. The NXT record indicates what are RR types are present at 256 that name and indicates the next authortitive name in the zone. 257 The collection of NXT or "next" resource records (RR) provide a 258 chain of all authoritative names and RRsets in the zone and are 259 used for authenticated denial of existence. The process for 260 constructing the NXT RR for a given name is described in [9]. 262 2.3 Inclusion of SIG RRs in a Zone 264 For each authoritative RRset in the zone, there MUST be at least 265 one SIG record that meets all of the following requirements: 267 The SIG owner name is equal to the RRset owner name. 269 The SIG class is equal to the RRset class. 271 The SIG Type Covered field is equal to the RRset type. 273 The SIG Original TTL field is greater than or equal to the TTL 274 of the RRset. 276 The SIG Labels field is equal to the number of labels in RRset 277 owner name. 279 The SIG Signer's Name is equal to the name of the zone 280 containing the RRset. 282 The SIG Algorithm, Signer's Name, and Key Tag fields identify a 283 zone KEY record at the zone apex. 285 The process for constructing the SIG RR for a given RRset is 286 described in [9]. An RRset MAY have multiple SIG RR associated 287 with it. 289 The SIG RR itself MUST NOT be signed since signing a SIG RRset 290 adds no value and creates a unterminated dependency loop in the 291 signing process. 293 The NS RRset that appears at the zone apex name MUST be signed, 294 but NS RRsets that appear at delegation owner names (child zones) 295 MUST NOT be signed and any glue address RRsets assoicated with 296 child delegations MUST NOT be signed. 298 2.4 Changes to the CNAME Resource Record. 300 If a CNAME RR is present at a name, RRs other than the SIG and NXT 301 MUST NOT be present at that name. 303 The above is modification to the original CNAME definition given 304 in [1]. The original definition of CNAME did not allow any other 305 resource records to co-exist with a CNAME record, but the zone 306 signing process associates NXT and SIG resource records with every 307 authorititative name. To resolve this conflict, the definition of 308 the CNAME resource record is modified to allow for the co- 309 existence of NXT and SIG RRs. 311 2.5 Inclusion of DS RRs in a Zone 313 The DS resource record is used to establish authentication chains 314 between DNS zones. A signed delegation (child zone) SHOULD 315 provide its parent zone with a DS RR for the delegation. All DS 316 RRsets stored in a zone MUST be signedx and DS RRsets MUST NOT 317 appear at non-delegation points or at a zone's apex. 319 The DS RR provided by the child SHOULD point to a KEY RR that is 320 present in the child's apex KEY set and the child's apex KEY RRset 321 SHOULD be signed by the corresponding private key. If the KEY RR 322 is present in the child's apex KEY set, the KEY RR MUST have the 323 Zone Key Flag set. 325 Note that the process of providing a DS RR can be accomplished by 326 either directly sending the DS RR to the parent or by sending a 327 KEY RR to the parent and requesting that the parent construct a DS 328 RR for the given KEY RR. The parent/child communication needs to 329 be authenticated in order to prevent an adversary from inserting a 330 false DS RR. DNSSEC operational and best practices documents are 331 encouraged to provide guidelines for providing a DS RR. 333 2.6 Example of a Secure Zone 335 secure zone 337 The apex KEY set includes two KEY RRs and the KEY RDATA Flags 338 indicate that each of these KEY RRs is a zone key. The first zone 339 KEY is used to sign the apex KEY set and a DS record for this key 340 is provided to the parent zone. The second zone KEY is used to 341 sign all the other RRsets in the zone. A non-zone KEY RR is also 342 stored at host1.example.com and this KEY and might be used by 343 SIG(0) to authenticate transactions from this host. 345 The zone includes a wildcard entry *.a.example.com. Note the 346 *.a.example.com name is used in constructing NXT chains and the 347 SIG covering the *.a.example.com MX RRset has a label count of 3. 349 The zone also includes two delegations. The delegation to 350 unsecure.example.com includes an NS RRset, glue address records, 351 and an NXT RR, but note that only the NXT RRset is signed. The 352 secure.example.com delegation has provided a DS RR and note that 353 only NXT and DS RRsets are signed. 355 3. Constructing DNS Responses 357 Unless a resolver has indicated support for DNSSEC, no changes are 358 made to the standard (non-secure) DNS response and a server simply 359 behaves as if no DNSSEC RR types were present. This helps avoid 360 backwards compatability issues and also avoids increasing the size 361 of (non-secure) DNS responses. Servers MUST NOT include any 362 DNSSEC RR types (KEY NXT SIG DS) unless the resolver has indicated 363 support for DNSSEC using one of the mechanisms described in 364 Section 3.1. 366 If a resolver has indicated support for DNSSEC: 368 SIG RRs that can be used to authenticate a response are 369 automatically included in the response according to the rules 370 in Section 3.2. 372 NXT RRs that can be used to provide authenticated denial of 373 existence are automatically included in the response according 374 to the rules in Section 3.4. 376 DS RRs (or an NXT RR if DS RRs are present) are automatically 377 included in referals according to the rules in Section 3.5. 379 Since the DS RR is the only RR type that appears only on the 380 upper side of a delegation, any query for the DS RR type 381 requires special processing as described in Section 3.6. 383 Section 3.7 discusses how these changes impact caching servers and 384 recursive servers. 386 3.1 Indicating Resolver Support for DNSSEC 388 A resolver has indicated it supports DNSSEC if any of the 389 following hold: 391 The query explictly requests a KEY, NXT, SIG, or DS RR type. 393 The query implicitly requests a KEY, NXT, SIG, or DS by 394 requesting a meta-type that matches the KEY, SIG, NXT, or DS 395 RRs. In particular, ANY, IXFR, and AFXR queries implictly 396 match the DNSSEC RR types and DNSSEC RRs MUST be returned in 397 response to a query for ANY, IFXR, or AXFR. 399 The resolver has explicity requested DNSSEC by setting the 400 DNSSEC OK bit in the ENDS0 header. 402 The "DNSSEC OK" (D0) bit is used for explicit notification of 403 DNSSEC support. The DO bit is defined in [9] and setting the DO 404 bit to one in a query indicates that the resolver is able to 405 accept DNSSEC security RRs. The DO bit cleared (set to zero) 406 indicates the resolver is unprepared to handle DNSSEC security RRs 407 and those RRs MUST NOT be returned in the response (unless DNSSEC 408 security RRs are explicitly requested in the query or implicitly 409 requested by the use a meta-RR type such as ANY, IXFR, or AFXR). 410 The DO bit of the query MUST be copied in the response. 412 In the event a server returns a NOTIMP, FORMERR or SERVFAIL 413 response to a query that has the DO bit set, the resolver SHOULD 414 NOT expect DNSSEC security RRs and SHOULD retry the query without 415 EDNS0 in accordance with Section 5.3 of RFC2671 [6]. 417 The absence of DNSSEC data in response to a query with the DO bit 418 set MUST NOT be taken to mean no security information is available 419 for that zone since the response may have be forged or may be a 420 non-forged response to an altered (DO bit cleared) query. 422 3.2 Inclusion of SIG RRs in a Response 424 If the resolver has indicated support for DNSSEC, servers SHOULD 425 attempt to send SIG RRs that can be used to authenticate the RR 426 sets in the response. The inclusion of SIG RRs in a response is 427 subject to the following rules: 429 When an signed RRset is placed in the answer section, its SIG 430 RRs are also placed in the answer section. The SIG RRs have a 431 higher priority for inclusion than any other RRsets that may 432 need to be included. If space does not permit the inclusion of 433 these SIG RRs, the response MUST be considered truncated. 435 When an signed RRset is placed in the authority section, its 436 SIG RRs are also placed in the authority section. The SIG RRs 437 have a higher priority for inclusion than any other RRsets that 438 may need to be included. If space does not permit the 439 inclusion of these SIG RRs, the response MUST be considered 440 truncated. 442 When an signed RRset is placed in the additional section, its 443 SIG RRs are also placed in the additional section. If space 444 does not permit the inclusion of these SIG RRs, the response 445 MUST NOT be considered truncated. 447 3.3 Inclusion of KEY RRs In a Response 449 If the resolver has indicated support for DNSSEC and the query 450 requests the SOA or NS RRs, then a server SHOULD return the KEY 451 RRset with the same name in the additional section. If not all 452 additional information will fit in the response, type A and AAAA 453 glue RRs have higher priority than KEY RRs. The SIG RR(s) 454 associated with the KEY RR set SHOULD also be included in the 455 additional section (see including SIG RRs in Section 3.2). 457 3.4 Inclusion of NXT RRs In a Response 459 If the resolver has indicated support for DNSSEC, the server MUST 460 include NXT RRs in each of the following cases: 462 Case 1: the query name exists, but the requested RR type does 463 not exist. 465 Case 2: the query name does not exist and no wildcard can be 466 expanded to answer the query. 468 Case 3: the query name does not exist, but a wildcard can be 469 expanded to answer the query. 471 NXT RRs are also included in a referal response if no DS RR is 472 present. In this case, the NXT RR is used to prove no DS RR 473 exists for the delegation and referals are discussed in detail in 474 Section 3.5. 476 Note that in every case the NXT RRs are included to provide 477 authenticated denial of existence. 479 3.4.1 Case 1: Query Name Exists, but RR Type Not Present 481 If the query name exists but the requested RR type is not present 482 at the name, then the NXT RR associated with the query name MUST 483 be included in the authority section. Any SIG(s) associated with 484 the NXT RRset are also included in the authority section (see 485 including SIG RRs in Section 3.2) If space does not permit the 486 inclusion of the NXT RR (or its associate SIG RRs), the response 487 MUST be considered truncated. 489 Note that since the query name exists, an single NXT RR suffices 490 to prove the requested type does not exist. Since the name exists 491 in the zone, an NXT RR for that name also exists and lists RR 492 types present at the name. Since the query name exists, no 493 wildcard expansion applies to this query. 495 3.4.2 Case 2: Query Name Does Not Exist and No Wildcard Matches 497 If the query name does not exist and no wildcard expansion matches 498 the query, the authority section of the response MUST include an 499 NXT RR that proves there was no exact match for the name and MUST 500 also include NXT RRs that prove no wildcard would have matched the 501 query. Any SIG(s) associated with the NXT RRsets are also 502 included in the authority section (see including SIG RRs in 503 Section 3.2) If space does not permit the inclusion of these NXT 504 RRs, the response MUST be considered truncated. 506 Appendix A provides an algorithm for computing the appropriate NXT 507 RRs that prove no wildcard matches the query name. 509 3.4.3 Case 3: Query Name Does Not Exist, but Wildcard Matches 511 If the query name does not exist and a wildcard expansion matches 512 the query, then the wildcard card expanded answer (and any SIG RRs 513 associated with the wildcard RR) are returned in the answer 514 section. The authority section of the response MUST include NXT 515 RRs that prove there were no exact matches for the name and MUST 516 also include NXT RRs to prove no closer wildcard entry would have 517 matched this query. 519 Appendix A provides an algorithm for computing the appropriate NXT 520 RRs that prove no closer wildcard matches the query name. 522 3.5 Inclusion of DS RRs In a Response 524 If the resolver has indicated support for DNSSEC, a server 525 returning a referral for the delegation MUST include both the NS 526 RRset and DS RRset if the DS RRset exists. The NS RRset MUST be 527 placed before the DS RRset (and its assoicated SIG RRs). 529 If the resolver has indicated support for DNSSEC, a server 530 returning a referral for the delegation MUST include both parent 531 NS RRset and the parent NXT RR if the DS RRset does not exist. 532 The NS RRset MUST be placed before the NXT RRset (and its 533 assoicated SIG RRs). 535 This increases the size of referral messages and may cause some or 536 all glue RRs to be omitted. If space does not permit the 537 inclusion of the DS RRset (NXT RRset) and its assoicated SIG RRs, 538 the response MUST be considered truncated. 540 3.6 Responding to Queries for DS RRs 542 The DS record is the first resource record that appears only on 543 the upper side of a delegation. In other words, the DS record for 544 zone "example.com" is only stored in the "com" zone (the parent/ 545 upper side of the delegation). This introduces novel server 546 behavior since the child server is authoritative for the zone, but 547 the zone does not contain the DS RR. A server's response to a DS 548 query depends on whether the server is authoritative for the 549 parent and/or child zones as described below. 551 If a server is authoritative for the parent zone at a delegation 552 point and receives a query for the DS record at the delegation 553 name, then the server MUST return the DS RRset from the parent 554 zone. This is true regardless of whether or not the server is 555 also authoritative for the child zone. 557 If the server is authoritative for the child zone at a delegation 558 point and is not authoritative for the parent zone, there is no 559 natural response. The child zone is not authoritative for the DS 560 record at the zone's apex and the DS RR is only stored at the 561 parent. 563 If the server allows recursion and the RD bit is set in the 564 query, the server MAY perform recursion to find the DS record 565 at the delegation point and MAY return the DS record from its 566 cache. In this case, the AA bit MUST NOT be set in the 567 response. 569 If the server does not perform recursion to find the DS RR, 570 the server MUST reply with: 572 RCODE: NOERROR 573 AA bit: set 574 Answer Section: Empty 575 Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] 577 In other words, an authortative child server answers as if it is 578 authoritative for the zone and the DS record does not exist. Note 579 DS-aware recursive servers will query the parent zone at 580 delegation points and thus will not be affected by this behavior. 582 For example, suppose "example.com" is a delegation point and a 583 query for the "example.com" DS RRset is received by a server. 585 If the server is authoritative for "com", the server MUST 586 reply with the "example.com" DS RRset from the "com" zone. 588 If the server is authoritative for "example.com" and is not 589 authortative for "com", the server MAY perform recursion to 590 find the "example.com" DS record (provided the RD bit was set 591 in the query). If the server does not use recursion to obtain 592 the DS RR, the server MUST reply as though the DS RR did not 593 exist: 595 RCODE: NOERROR 596 AA bit: set 597 Answer Section: Empty 598 Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] 600 3.7 Special Considerations for Recursive/Caching Servers 602 A DNSSEC aware recursive server MUST set the DO bit on recursive 603 requests, regardless of the status of the DO bit on the initiating 604 resolver request. If the initiating resolver request does not 605 have the DO bit set, the recursive DNSSEC-aware server MUST remove 606 any DNSSEC security RRs before returning the data to the client, 607 however cached data MUST NOT be modified. 609 A caching server SHOULD NOT attempt to answer a query by piecing 610 together the responses it has received previous from other queries 611 that requested different names or RR types. A cache typically 612 does not have access to the complete zone and thus it can be 613 difficult for a caching server to determine the proper SIG, NXT, 614 KEY, and DS RRs for a given a query. A caching server SHOULD 615 cache each response single atomic entry indexed by the question 616 (including the response and the all the assoicated DNSSEC RR 617 types). The cache SHOULD discard the entire entry when any RR in 618 the response expires. 620 3.8 Setting the AD and CD Bits in a Response 622 DNSSEC allocates two new bits in the DNS message header section: 623 The CD (checking disabled) bit and the AD (authentic data) bit. 624 These bits are defined in [9] and their use is described below. 626 The CD bit is set by the resolver and MUST be copied in the 627 response. If the CD bit is set to one, it indicates the resolver 628 is willing to perform authentication and the server need not 629 perform authentication on the RRsets in the response. 631 Regardless of the CD bit, the server MAY choose to perform 632 authentication (or choose not to perform authentication) according 633 to the local server policy. The CD bit MAY be used in 634 constructing the local server policy. If local server policy does 635 perform authentication, any RRsets rejected by the local 636 authentication policy MUST NOT be returned in a response 637 (regardless of the CD bit). 639 The AD bit is set by the server and indicates the data in the 640 response has been authenticated by the server, according to the 641 local server policy. The AD bit MUST NOT be set on a response 642 unless all of the RRsets in the answer and authority sections have 643 met the servers local authentication policy. A resolver MUST NOT 644 use the AD bit unless unless it communicates with the server over 645 a secure transport mechanism and is explicitly configured to trust 646 the server's policy. DNSSEC best practices documents are 647 encouraged to provide server policy recommendations. 649 3.9 Example DNSSEC Responses 651 example of A and SIG 653 example of apex KEY 655 example of signed delegation (DS) and unsigned delegation (NXT) 657 example of auth denial (includes NXT for wildcards) 659 4. Authenticating DNS Responses 661 In order to use DNSSEC RRs for authentication, a resolver requires 662 some intial authenticated KEY RR. The process for obtaining and 663 authenticating this initial KEY RR is achieved via some external 664 mechanism. For example, a resolver could use some off-line 665 authenticated exchange to obtain a zone's KEY RR or obtain a DS RR 666 that identifies and authenticates a zone's KEY RR. In the 667 remainder of this section assumes the resolver has used some 668 unspecified off-line mechanism and obtained an initial set of 669 authenticated KEY RRs. 671 An initial KEY RR can be used to authenticate a zone's apex KEY 672 RRset. To authenticate an apex KEY RRset using an initial key, 673 the resolver MUST 675 1. Verify the initial KEY RR appears in the apex KEY RRset and 676 verify the KEY RR has the Zone Key Flag (KEY RDATA bit 7) set 677 to 1. 679 2. Verify there is some SIG RR that covers the apex KEY RRset 680 and the combination of the SIG RR and the initial KEY RR 681 authenticate the KEY RRset. The process for using a SIG RR to 682 authenticate an RRset is described in Section 4.2. 684 Once the apex KEY RRset has been authenticated using an initial 685 KEY RR, delegations from that zone can be authenticated using DS 686 RRs. This allows a resolver to start from an initial externally 687 authenticated key, and use DS RRsets to recursively proceed down 688 the DNS tree to obtain other apex KEY RRsets. If the resolver was 689 initially configured with a root KEY RR and if every delegation 690 had a DS RR assoicated with it, the resolver could obtain any apex 691 KEY RRset. The process of using DS RRs to authentic a referal is 692 described in Section 4.1. 694 Once a zones apex KEY RRset has been authenticated, Section 4.2 695 shows how the resolver can use KEY RRs in the apex KEY RRset and 696 SIG RRs from the zone to authenticate any other RRsets in the 697 zone. Section 4.3 shows how the resolver can use authenticated 698 NXT RRsets from the zone to prove an RRset is not present in the 699 zone. 701 If the resolver has indicated support for DNSSEC, DNSSEC aware 702 servers SHOULD attempt to provide the necessary KEY, SIG, NXT, and 703 DS RRets in a response (see Section 3). However, a response that 704 lacks the approriate DNSSEC RRs may result from configuration 705 issues such as a non-DNSSEC aware cache that removes or fails 706 request DNSSEC RRs or may result from an intentional attack where 707 an adversary forges a response, strips DNSSEC RRs from a response 708 forges, or modifies the query so DNSSEC RRs appear not to be 709 requested. The absence of DNSSEC data in response MUST NOT be 710 taken to mean that no authentication information is available. 712 A resolver SHOULD expect authentication information from signed 713 zones. A SHOULD believe a zone is signed if the resolver has been 714 configured with public key information for the zone or if the 715 zone's parent is signed and the delegation at the parent contains 716 a DS RRset. DNSSEC best practices documents are encouraged to 717 provide guidance on how a resolver responds if DNSSEC RRs are 718 expected, but can not be obtained. DNSSEC best practices 719 documents are also are encouraged to provide guidance on how a 720 resolver responds if the expected DNSSEC RRs are obtained but 721 appear invalid (e.g. all SIG RRs are expired). 723 4.1 Authenticating Referrals 725 Once the apex KEY RRset for a (parent) zone has been 726 authenticated, DS RRsets can be used to authenticate a referal to 727 a delegation (child zone). A DS RR identifies a KEY RR in the 728 child's apex KEY RRset. The DS RR contains a digest of the 729 child's KEY RR and a strong cryptographic digest algorithm ensures 730 that an adversary can not easily generate a KEY RR that matches 731 the digest. Thus authenticating the digest allows a resolver to 732 safely declare the matching child KEY RR to is also authentic. 733 This child KEY RR is then used to authenticate the entire child 734 apex KEY RRset. 736 Given a DS RR for a delegation (child zone), the delegation's 737 (child zone's) apex KEY RRset is considered to be authentic if all 738 of the following hold: 740 The DS RR has been authenticated using some KEY RR in the 741 parent's apex KEY RRset (see Section 4.2). 743 The Algorithm, Key Tag, and Digest fields in the DS RR match 744 the algorithm, key tag, and digest of a KEY RR present in the 745 child's apex KEY RRset. 747 The matching KEY RR in the child zone has the Zone Flag bit set 748 to one, the corresponding private key has signed the child apex 749 KEY RRset, and the resulting SIG RR authenticates the child's 750 apex KEY RRset. 752 If the referal from the parent zone did not contain a DS RRset, 753 the response SHOULD have included an NXT RRset that proves no DS 754 RRset exists for the delegation name (see Section 3.5). A 755 resolver SHOULD send the parent a query for the DS RRset if 756 neither a DS RRset or NXT RRset is included in the referal. 758 If the resolver authenticates an NXT RRset that proves no DS RRset 759 is present for this zone, then there is no authentication path 760 leading from the parent to the child. If the resolver has an 761 initial KEY RR that belongs to the child zone (or any delegation 762 below the child zone), this initial KEY RR MAY be used to re- 763 establish an authentication path. If no such initial KEY RR 764 exists, the resolver can not authenticate RRsets at or below the 765 child zone. 767 Note for a signed delegation there are two NXT RRs associated with 768 the delegation name. One NXT RR resides at the parent can be used 769 to prove whether a DS RRset exists for the delegation name. A 770 second NXT RR resides at the child zone and identifies which 771 RRsets are present at the apex in the child zone. The parent NXT 772 RR and child NXT RR can always be distinguished since the only the 773 child NXT RR will specify an SOA RR set exists at the name. A 774 resolver MUST only use the parent NXT RR when proving a DS RRset 775 does not exist. 777 4.2 Authenticating an RRSet Using a SIG RR 779 A SIG RR (and its corresponding KEY RR) is used by a resolver to 780 authentic an RRset. The SIG RR is first checked to verify that it 781 covers the RRset, has a valid time interval, and identifies a 782 valid KEY RR. The signed data is then constructed by appending 783 SIG RDATA (excluding the Signature Field) with the covered RRset 784 (in canonical form). Finally, the public key and signature and 785 used to authenticate the signed data. Section 4.2.1, Section 786 4.2.2, and Section 4.2.3 describe each step in detail. 788 4.2.1 Checking the SIG RR Validity 790 An SIG RR can be used to authenicate an RRset if all of the 791 following conditions hold: 793 The SIG RR and the RRset MUST have the same owner name and same 794 class. 796 The SIG RR's Signer's Name field MUST be the name of the zone 797 that contains the RRset. 799 The SIG RR's Type Covered field MUST equal the RRset's type. 801 The number of labels in the RRset owner name MUST be greater 802 than or equal to the value in the SIG RR's Labels field. 804 The resolver's current time MUST be less than or equal to the 805 time listed in the SIG RR's Expiration field. 807 The resolver's current time MUST be greater than or equal to 808 the time listed in the SIG RR's Inception field. 810 The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST 811 match the owner name, algorithm, and key tag for some KEY RR in 812 the zone's apex KEY RRset. 814 The matching KEY RR MUST be present in the zone's apex KEY 815 RRset and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) 816 set to 1. 818 It is possible that more than one KEY RR matches the conditions 819 above. In this case, the resolver can not determine which KEY RR 820 is used to authenticate the signature and the resolver MUST try 821 each matching KEY RR until the resolver has either validated the 822 signature or all matching KEY RRs have failed. 824 Note that the authentication process is only meaningful if the 825 resolver first authenticates a KEY RR before using it to validate 826 a signature. The matching KEY RR is considered to be authentic if 828 The apex KEY RRset containing the KEY RR is considered 829 authentic 831 The RRset covered by the SIG RR is the apex KEY RRset itself 832 and the KEY RR matches an authenticated DS RR from the parent 833 zone or matches some initial KEY RR/DS RR that is known to be 834 authentic. 836 4.2.2 Reconstructing the Signed Data 838 Once the SIG RR has met the validity requirements described in 839 Section 4.2.1, the original signed data needs to be reconstructed. 840 The original signed data includes SIG RDATA (excluding the 841 Signature field) and the RRset in cannonical order and might 842 differ from the RRset received in the DNS response due to name 843 compression, TTL decrementing by a cache, or the RRset may be the 844 result of wildcard expansion. The following algorithm is used to 845 reconstuct the original signed data: 847 signed_data = SIG_RDATA | RR(1) | RR(2)... where 849 "|" denotes append 850 SIG_RDATA is the wire format of the SIG RDATA fields with 851 the Signature field excluded. 852 the Signer's Name in cannonical form. 854 RR(i) = name | class | type | OrigTTL | RDATA length | RDATA 856 name is calculated according to the function below 858 class is the RRset's class 860 type is the RRset type and all RRs in the class 862 OrigTTL is the value from the SIG Original TTL field 864 All names in the RDATA field are in canonical form 866 The set of all RR(i) is sorted into cannonical order. 868 To calculate the name: 869 let sig_labels = the value of the SIG Labels field 871 let fqdn = RRset's fully qualified domain name in 872 canonical form 874 let fqdn_labels = RRset's fully qualified domain name in 875 canonical form 877 if sig_labels = fqdn_labels, 878 name = fqdn 880 if sig_labels < fqdn_labels, 881 name = "*." | the leftmost sig_label labels of the fqdn 883 if sig_labels > fqdn 884 the SIG RR did not pass the necessary validation 885 checks and MUST NOT be used to authenticate this RRset. 887 An example of original name calculation is given in Section 4.4.1. 888 The canonical form for names and RRsets is defined in [9]. 890 NXT RRsets present at a delegaion name require special processing. 891 There are two distinct NXT RRsets associated with a signed 892 delegation name. One NXT RRset resides at the parent and 893 specifies which RRset are present at the parent. A second NXT 894 RRset resides at the child zone and identifies which RRsets are 895 present at the apex in the child zone. The parent NXT RRset and 896 child NXT RRset can always be distinguished since only the child 897 NXT RRs will specify an SOA RR set exists at the name. When 898 constructing the original NXT RRset, the NXT RRs MUST NOT be 899 combined with NXT RRs from the child (and vice versa). 901 4.2.3 Checking the Signature 903 Once the SIG RR has met the validity requirements described in 904 Section 4.2.1 and the original signed data has been reconstructed 905 as described in Section 4.2.2, the cryptographic signature is used 906 to authenticate the signed data (and thus authenticate the RRset). 908 The Algorithm field in the SIG RR identifies the cryptographic 909 algorithm used to validate the signature. The signature itself is 910 contained in the Signature field of the SIG RDATA and public key 911 used to authenticate this signature is contained in the Public Key 912 field of the matching KEY RR(s) (found in Section 4.2.1). [9] 913 provides a list of algorithm types and provides pointers to the 914 documents that define each algorithm's use. 916 Note it is possible that more than one KEY RR matches the 917 conditions in Section 4.2.1. In this case, the resolver can not 918 determine which KEY RR is used to authenticate the signature and 919 the resolver MUST try each matching KEY RR until the resolver has 920 either validated the signature or all matching KEY RRs have 921 failed. 923 If the SIG RR Labels field is not equal to the number of labels in 924 the RRsets fully qualified domain name, then the RRset is a result 925 of wildcard expansion. The resolver MUST verify the wildcard was 926 applied properly before the RRset is considered authentic. The 927 RRset and SIG RR MUST be discarded if the resolver proves the 928 wildcard was applied improperly. Section 4.2.4 describes how to 929 determine whether a wildcard was applied properly. 931 If other SIG RRs also cover this SIG RR, the local resolver 932 security policy determines whether these SIG RRs need to be tested 933 and determines how to resolve conflicts if these SIG RRs lead to 934 differing results. 936 If the RRset is accepted as authentic, the SIG RR TTL and the TTL 937 of each RR in the authenticated RRset MUST be set to the minimum 938 of 940 the RR TTL received in the response 942 the value in the SIG RRs Original TTL field 944 4.2.4 Authenticating Wildcard Expanded RRset 946 If a SIG RR's fully qualified domain name does not equal the 947 Labels field in the SIG RDATA, then SIG RR (and its covered RRset) 948 were created as a result of wildcard expansion. Once the 949 signature has been verified as described in Section 4.2, 950 additional steps are required to verify 1) no intermediate name 951 cancels the use of the wildcard and 2) no more specific wildcard 952 name could have been used to create this RRset. 954 Intermediate label names can be formed from the fully qualified 955 domain name by removing the rightmost labels and are used to prove 956 the wildcard was used properly. For example, 957 "www.a.b.c.example.com." has intermediate names of 958 "a.b.c.example.com", "b.c.example.com", "c.example.com", 959 "example.com", and "com". For each intermediate label name whose 960 label count is greater the SIG RR Labels field, the resolver MUST 961 obtain and authenticate NXT RRs that prove: 963 the intermediate label name does not exist (otherwise this 964 label would cancel the wildcard) 966 the name "*.intermediate_label_name" does not exist (otherwise 967 this wildcard would take precedence) 969 Note the response SHOULD include all NXT RRs needed to the 970 authenticate the response (see Section Section 3.4). 972 4.3 Authenticated Denial of Existence 974 A resolver can use authenticated NXT RRs to prove that an RRset is 975 not present in a signed zone. NXT RRsets SHOULD be automatically 976 included in the response, provided the zone is signed and the 977 resolver has indicated support for DNSSEC. NXT RRsets are 978 authenticated according to standard RRset authentication rules 979 described in Section 4.2 and are applied as follows: 981 If the requested RR name matches the owner name of an 982 authenticated NXT RR, then all RR types present at that owner 983 name MUST be listed in the NXT RR's Type Bit Map field. A 984 resolver can prove the requested RR type does not exist by 985 presenting checking for the RR type in NXT RR's Type Bit Map 986 field. Also, since owner name exists in the zone, no wildcard 987 expansion could be used to match the requested RR owner name and 988 type. 990 If the requested RR name logically appears after an authenticated 991 NXT RR owner name and logically appears before the name listed in 992 that NXT RR's Next Domain Name field, then the requested RR name 993 is not present in the zone. However, it is possible a wildcard 994 could be used to match the requested RR owner name and type 996 Intermediate label names are used to prove no wildcard matches the 997 requested name. Intermediate label names are formed from the 998 requested RR's fully qualified domain name by removing the 999 rightmost labels from the name. For example, 1000 "www.a.b.c.example.com." has intermediate names of 1001 "a.b.c.example.com", "b.c.example.com", "c.example.com", 1002 "example.com", and "com". To prove no wildcard matches, the 1003 resolver MUST start with the longest intermediate label name prove 1004 that: 1006 No wildcard exists at this intermediate label name. In other 1007 words, there is an authenticated NXT RR such the NXT RR's owner 1008 name logically appears before "*.intermediate_label_name" and 1009 the NXT RR's Next Domain field appears logically after 1010 "*.intermediate_lable_name". 1012 The resolver MUST continue testing intermediate label names until 1013 (in order of decreasing label count) until the intermediate label 1014 name matches an authenticated NXT RR's owner name. Note that this 1015 is guaranteed to occur since at some point the intermediate label 1016 will equal the zone name and NXT RR exists at the zone name. 1018 4.4 Example 1020 4.4.1 Example of Re-Constructing the Original Name 1022 Suppose the RRset owner name received in a response is 1023 "www.a.b.c.example.com.". This fully qualified domain name has 6 1024 labels: "www", "a", "b", "c", "example", and "com". The name 1025 used in reconstructing the original signed data depends on the 1026 value of the SIG Labels. 1028 If the SIG Labels field is 6, then the SIG Labels field equals the 1029 number of labels in the RRsets fully qualified domain name. 1030 Wildcard expansion was not used to construct this RRset and the 1031 name "www.a.b.c.example.com." is used to construct the original 1032 signed data. 1034 If the SIG Labels field is 3, then the SIG Labels field is 1035 strictly less than number of labels in the RRset's fully qualified 1036 domain name. Wildcard expansion was used to construct this RRset 1037 and the original wildcard owner name is constructed by appending 1038 "*." to the last 3 labels in the owner name. The name 1039 "*.c.example.com." is is used to construct the original signed 1040 data. 1042 authentication process for www.example.com starting from a initial 1043 root key 1045 authentication process for non-existent www.a.b.c.example.com 1046 starting from a initial root key 1048 5. IANA Considerations 1050 This document introduces no IANA considerations. 1052 [9] contains a complete review of the IANA considerations 1053 introduced by the DNSSEC. 1055 6. Security Considerations 1057 This document describes how the DNS security extensions use public 1058 key cryptography to sign and authenticate DNS resource record 1059 sets. 1061 At this time, at least two substantial elements of the DNSSEC 1062 specification have yet to be decided by the working group. The 1063 open opt-in issue would change elements such as what RRsets must 1064 be signed, would impact how wildcards are used, and would replace 1065 authenticated denial of existence with authenticated denial of 1066 security. The ad-bit is also undecided. The ad bit (as 1067 currently defined) is used to indicate the security status of 1068 RRsets in the response. These items clearly raise security 1069 considerations and will addressed here as these issues are 1070 resolved in the working group. 1072 DNSSEC introduces a number of denial of service issues. These 1073 issues will also be addressed in the revised version of the 1074 security considerations. 1076 7. Acknowledgements 1078 This document was created from the input and ideas of several 1079 members of the DNS Extensions Working Group and working group 1080 mailing list. The co-authors of this draft would like to express 1081 their thanks for the comments and suggestions received during the 1082 revision of these security extension specifications. 1084 References 1086 [1] Mockapetris, P., "Domain names - concepts and facilities", 1087 STD 13, RFC 1034, November 1987. 1089 [2] Mockapetris, P., "Domain names - implementation and 1090 specification", STD 13, RFC 1035, November 1987. 1092 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1093 August 1996. 1095 [4] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, March 1997. 1098 [5] Elz, R. and R. Bush, "Clarifications to the DNS 1099 Specification", RFC 2181, July 1997. 1101 [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 1102 August 1999. 1104 [7] Eastlake, D., "DNS Request and Transaction Signatures ( 1105 SIG(0)s)", RFC 2931, September 2000. 1107 [8] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC 1108 Intro", October 2002. 1110 [9] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource 1111 Records for the DNS Security Extensions", October 2002. 1113 Authors' Addresses 1115 Roy Arends 1116 Bankastraat 41-E 1117 1094 EB Amsterdam 1118 NL 1120 EMail: roy@logmess.com 1122 Matt Larson 1123 VeriSign, Inc. 1124 21345 Ridgetop Circle 1125 Dulles, VA 20166-6503 1126 USA 1128 EMail: mlarson@verisign.com 1129 Dan Massey 1130 USC Information Sciences Institute 1131 3811 N. Fairfax Drive 1132 Arlington, VA 22203 1133 USA 1135 EMail: masseyd@isi.edu 1137 Scott Rose 1138 National Institute for Standards and Technology 1139 100 Bureau Drive 1140 Gaithersburg, MD 20899-8920 1141 USA 1143 EMail: scott.rose@nist.gov 1144 Appendix A. Algorithm For Handling Wildcard Expansion 1146 For zone (Z) and a name (N) that may occur in Z, the following 1147 algorithm finds all wildcard RRsets that match N or returns an NXT 1148 RR set that proves no wildcard expansion matches N. The algorithm 1149 was written for clarity not efficiency: (EDITORS NOTE: the 1150 algorithm was really written on a redeye flight during dull movie 1151 so it is unlikely to really achieve clarity :) 1153 0. INPUT: a name (N) and a zone (Z). 1154 INIT: NXT_SET = NULL 1156 1. Construct S = sequence of all names in Z, sorted 1157 into canonical order. 1159 2. If N exists in S 1160 There is an exact match for N. 1161 Return all RRsets associated with N 1162 Else 1163 Add the name that would immediately 1164 preceed N in S to NXT_SET. 1165 EndIf 1167 3. Replace the leftmost label of N with * 1169 4. If N exists in S 1170 There is a wildcard match for N. 1171 Return all RRsets associated with N 1172 Else 1173 Add the NXT for name that would immediately 1174 preceed N in S to NXT_SET. 1175 EndIf 1177 5. Remove the leading * from N. 1179 6. If N exists in S 1180 There is an name that terminates the wildcard search. 1181 Add the NXT for N to NXT_SET and return NXT_SET. 1182 Else 1183 Goto Step 3 1184 EndIf 1186 Note: the algorithm is guaranteed to terminate since 1187 eventually there will be a match or N will be 1188 reduced to zone name itself and the zone name 1189 must exist in S. 1191 Full Copyright Statement 1193 Copyright (C) The Internet Society (2002). All Rights Reserved. 1195 This document and translations of it may be copied and furnished 1196 to others, and derivative works that comment on or otherwise 1197 explain it or assist in its implementation may be prepared, 1198 copied, published and distributed, in whole or in part, without 1199 restriction of any kind, provided that the above copyright notice 1200 and this paragraph are included on all such copies and derivative 1201 works. However, this document itself may not be modified in any 1202 way, such as by removing the copyright notice or references to the 1203 Internet Society or other Internet organizations, except as needed 1204 for the purpose of developing Internet standards in which case the 1205 procedures for copyrights defined in the Internet Standards 1206 process must be followed, or as required to translate it into 1207 languages other than English. 1209 The limited permissions granted above are perpetual and will not 1210 be revoked by the Internet Society or its successors or assigns. 1212 This document and the information contained herein is provided on 1213 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1214 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1215 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1216 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1219 Acknowledgement 1221 Funding for the RFC Editor function is currently provided by the 1222 Internet Society.