idnits 2.17.1 draft-ietf-dnssec-secext2-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-secext2-05.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secext2-05.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secext2-05.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-secext2-05.txt,', but the file name used is 'draft-ietf-dnssec-secext2-05' == 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 373: '... There MUST be a zone KEY RR, signed...' RFC 2119 keyword, line 376: '...one to be unsecured MUST appear in and...' RFC 2119 keyword, line 400: '...ty aware servers MUST (1) allow KEY, S...' RFC 2119 keyword, line 469: '... implementations MUST be designed to h...' RFC 2119 keyword, line 518: '... KEY RR MUST occur at the apex node ...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 176 has weird spacing: '...ts from poten...' == Line 824 has weird spacing: '... key tag ...' == Line 1967 has weird spacing: '... a flag bit f...' == Line 2059 has weird spacing: '...ong int ac;...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: SOA serial numbers for secure zones MUST not only be advanced when their data is updated but also when new SIG RRs are inserted (ie, the zone or any part of it is re-signed). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 1998) is 9507 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFCs 2136' is mentioned on line 276, but not defined -- Looks like a reference, but probably isn't: '2137' on line 985 -- Looks like a reference, but probably isn't: '2030' on line 1561 == Unused Reference: 'RFC 1032' is defined on line 1816, but no explicit reference was found in the text == Unused Reference: 'RFC 1034' is defined on line 1821, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 1824, but no explicit reference was found in the text == Unused Reference: 'RFC 1750' is defined on line 1832, but no explicit reference was found in the text == Unused Reference: 'RFC 2030' is defined on line 1844, but no explicit reference was found in the text == Unused Reference: 'RSA FAQ' is defined on line 1880, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1032 ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1530 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2030 (Obsoleted by RFC 4330) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (Obsoleted by RFC 3007) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA FAQ' Summary: 21 errors (**), 1 flaw (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Security Working Group Donald E. Eastlake 3rd 2 INTERNET-DRAFT CyberCash 3 OBSOLETES RFC 2065 4 UPDATES RFC 1034, 1035 5 Expires: October 1998 April 1998 7 Domain Name System Security Extensions 8 ------ ---- ------ -------- ---------- 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-secext2-05.txt, is intended 13 to become a Proposed Standard RFC obsoleting Proposed Standard RFC 14 2065. Distribution of this document is unlimited. Comments should be 15 sent to the DNS Security Working Group mailing list or to the author. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 Extensions to the Domain Name System (DNS) are described that provide 38 data integrity and authentication to security aware resolvers and 39 applications through the use of cryptographic digital signatures. 40 These digital signatures are included in secured zones as resource 41 records. Security can also be provided through non-security aware 42 DNS servers in some cases. 44 The extensions provide for the storage of authenticated public keys 45 in the DNS. This storage of keys can support general public key 46 distribution services as well as DNS security. The stored keys 47 enable security aware resolvers to learn the authenticating key of 48 zones in addition to those for which they are initially configured. 49 Keys associated with DNS names can be retrieved to support other 50 protocols. Provision is made for a variety of key types and 51 algorithms. 53 In addition, the security extensions provide for the optional 54 authentication of DNS protocol transactions and requests. 56 This document incorporates feedback on RFC 2065 from early 57 implementers and potential users. 59 Acknowledgments 61 The significant contributions and suggestions of the following 62 persons (in alphabetic order) to DNS security are gratefully 63 acknowledged: 65 James M. Galvin 66 John Gilmore 67 Olafur Gudmundsson 68 Charlie Kaufman 69 Edward Lewis 70 Radia J. Perlman 71 Jeffrey I. Schiller 72 Steven (Xunhua) Wang 73 Brian Wellington 75 Table of Contents 77 Status of This Document....................................1 79 Abstract...................................................2 80 Acknowledgments............................................2 82 Table of Contents..........................................3 84 1. Overview of Contents....................................5 85 2. Overview of the DNS Extensions..........................6 86 2.1 Services Not Provided..................................6 87 2.2 Key Distribution.......................................6 88 2.3 Data Origin Authentication and Integrity...............7 89 2.3.1 The SIG Resource Record..............................8 90 2.3.2 Authenticating Name and Type Non-existence...........8 91 2.3.3 Special Considerations With Time-to-Live.............8 92 2.3.4 Special Considerations at Delegation Points..........9 93 2.3.5 Special Considerations with CNAME....................9 94 2.3.6 Signers Other Than The Zone.........................10 95 2.4 DNS Transaction and Request Authentication............10 97 3. The KEY Resource Record................................12 98 3.1 KEY RDATA format......................................12 99 3.1.1 Object Types, DNS Names, and Keys...................13 100 3.1.2 The KEY RR Flag Field...............................13 101 3.1.3 The Protocol Octet..................................14 102 3.2 The KEY Algorithm Number Specification................15 103 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...16 104 3.4 Determination of Zone Secure/Unsecured Status.........17 105 3.5 KEY RRs in the Construction of Responses..............18 107 4. The SIG Resource Record................................20 108 4.1 SIG RDATA Format......................................20 109 4.1.1 ....................................................20 110 4.1.2 Algorithm Number Field..............................21 111 4.1.3 Labels Field........................................21 112 4.1.4 Original TTL Field..................................21 113 4.1.5 Signature Expiration and Inception Fields...........22 114 4.1.6 Key Tag Field.......................................22 115 4.1.7 Signer's Name Field.................................22 116 4.1.8 Signature Field.....................................23 117 4.1.8.1 Calculating Transaction and Request SIGs..........23 118 4.2 SIG RRs in the Construction of Responses..............24 119 4.3 Processing Responses and SIG RRs......................25 120 4.4 Signature Lifetime, Expiration, TTLs, and Validity....26 122 5. Non-existent Names and Types...........................27 123 5.1 The NXT Resource Record...............................27 124 5.2 NXT RDATA Format......................................28 125 5.3 Additional Complexity Due to Wildcards................28 126 5.4 Example...............................................29 127 5.5 Special Considerations at Delegation Points...........30 128 5.6 Zone Transfers........................................30 129 5.6.1 Full Zone Transfers.................................30 130 5.6.2 Incremental Zone Transfers..........................31 132 6. How to Resolve Securely and the AD and CD Bits.........32 133 6.1 The AD and CD Header Bits.............................32 134 6.2 Staticly Configured Keys..............................33 135 6.3 Chaining Through The DNS..............................34 136 6.3.1 Chaining Through KEYs...............................34 137 6.3.2 Conflicting Data....................................36 138 6.4 Secure Time...........................................36 140 7. ASCII Representation of Security RRs...................37 141 7.1 Presentation of KEY RRs...............................37 142 7.2 Presentation of SIG RRs...............................38 143 7.3 Presentation of NXT RRs...............................39 145 8. Canonical Form and Order of Resource Records...........40 146 8.1 Canonical RR Form.....................................40 147 8.2 Canonical DNS Name Order..............................40 148 8.3 Canonical RR Ordering Within An RRset.................41 149 8.4 Canonical Ordering of RR Types........................41 151 9. Conformance............................................42 152 9.1 Server Conformance....................................42 153 9.2 Resolver Conformance..................................42 155 10. Security Considerations...............................43 157 References................................................44 159 Author's Address..........................................46 160 Expiration and File Name..................................46 162 Appendix A: Base 64 Encoding..............................47 164 Appendix B: Changes from RFC 2065.........................49 166 Appendix C: Key Tag Calculation...........................51 168 1. Overview of Contents 170 This document standardizes extensions of the Domain Name System (DNS) 171 protocol to support DNS security and public key distribution. It 172 assumes that the reader is familiar with the Domain Name System, 173 particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An 174 earlier version of these extensions appears in RFC 2065. This 175 replacement for that RFC incorporates early implementation experience 176 and requests from potential users. 178 Section 2 provides an overview of the extensions and the key 179 distribution, data origin authentication, and transaction and request 180 security they provide. 182 Section 3 discusses the KEY resource record, its structure, and use 183 in DNS responses. These resource records represent the public keys 184 of entities named in the DNS and are used for key distribution. 186 Section 4 discusses the SIG digital signature resource record, its 187 structure, and use in DNS responses. These resource records are used 188 to authenticate other resource records in the DNS and optionally to 189 authenticate DNS transactions and requests. 191 Section 5 discusses the NXT resource record (RR) and its use in DNS 192 responses including full and incremental zone transfers. The NXT RR 193 permits authenticated denial of the existence of a name or of an RR 194 type for an existing name. 196 Section 6 discusses how a resolver can be configured with a starting 197 key or keys and proceed to securely resolve DNS requests. 198 Interactions between resolvers and servers are discussed for various 199 combinations of security aware and security non-aware. Two 200 additional DNS header bits are defined for signaling between 201 resolvers and servers. 203 Section 7 describes the ASCII representation of the security resource 204 records for use in master files and elsewhere. 206 Section 8 defines the canonical form and order of RRs for DNS 207 security purposes. 209 Section 9 defines levels of conformance for resolvers and servers. 211 Section 10 provides a few paragraphs on overall security 212 considerations. 214 Appendix A gives details of base 64 encoding which is used in the 215 file representation of some RRs defined in this document. 217 Appendix B summarizes changes between this draft and RFC 2065. 219 Appendix C specified how to calculate the simple checksum used as a 220 key tag in the SIG RR. 222 2. Overview of the DNS Extensions 224 The Domain Name System (DNS) protocol security extensions provide 225 three distinct services: key distribution as described in Section 2.2 226 below, data origin authentication as described in Section 2.3 below, 227 and transaction and request authentication, described in Section 2.4 228 below. 230 Special considerations related to "time to live", CNAMEs, and 231 delegation points are also discussed in Section 2.3. 233 2.1 Services Not Provided 235 It is part of the design philosophy of the DNS that the data in it is 236 public and that the DNS gives the same answers to all inquirers. 237 Following this philosophy, no attempt has been made to include any 238 sort of access control lists or other means to differentiate 239 inquirers. 241 No effort has been made to provide for any confidentiality for 242 queries or responses. (This service may be available via IPSEC [RFC 243 1825], TLS [draft-ietf-tls-*], or other security protocols.) 245 Protection is not provided against denial of service. 247 2.2 Key Distribution 249 A resource record format is defined to associate keys with DNS names. 250 This permits the DNS to be used as a public key distribution 251 mechanism in support of DNS security itself and other protocols. 253 The syntax of a KEY resource record (RR) is described in Section 3. 254 It includes an algorithm identifier, the actual public key 255 parameter(s), and a variety of flags including those indicating the 256 type of entity the key is associated with and/or asserting that there 257 is no key associated with that entity. 259 Under conditions described in Section 3.5, security aware DNS servers 260 will automatically attempt to return KEY resources as additional 261 information, along with those resource records actually requested, to 262 minimize the number of queries needed. 264 2.3 Data Origin Authentication and Integrity 266 Authentication is provided by associating with resource record sets 267 (RRsets [RFC 2181]) in the DNS cryptographically generated digital 268 signatures. Commonly, there will be a single private key that 269 authenticates an entire zone but there might be multiple keys for 270 different algorithms, signers, etc. If a security aware resolver 271 reliably learns a public key of the zone, it can authenticate, for 272 signed data read from that zone, that it was properly authorized and 273 is current. The most secure implementation is for the zone private 274 key(s) to be kept off-line and used to re-sign all of the records in 275 the zone periodically. However, there are cases, for example dynamic 276 update [RFCs 2136, 2137], where DNS private keys need to be on-line. 277 [draft-ietf-dnssec-secops-*.txt] 279 This data origin authentication key(s) are associated with the zone 280 and not with the servers that store copies of the data. That means 281 compromise of a secondary server or, if the key(s) are kept off line, 282 even the primary server for a zone, will not necessarily affect the 283 degree of assurance that a resolver has that it can determine whether 284 data is genuine. 286 A resolver could learn a public key of a zone either by reading it 287 from the DNS or by having it or a key which authenticates it staticly 288 configured. To reliably learn a public key by reading it from the 289 DNS, the key itself must be signed with a key the resolver trusts. 290 The resolver must be configured with at least a public key which 291 authenticates one zone as a starting point. From there, it can 292 securely read public keys of other zones, if the intervening zones in 293 the DNS tree are secure and their signed keys accessible. 295 Adding data origin authentication and integrity requires no change to 296 the "on-the-wire" DNS protocol beyond the addition of the signature 297 resource type and the key resource type needed for key distribution. 298 (Data non-existence authentication also requires the NXT RR as 299 described in 2.3.2.) This service can be supported by existing 300 resolver and caching server implementations so long as they can 301 support the additional resource types (see Section 9). The one 302 exception is that CNAME referrals in a secure zone can not be 303 authenticated if they are from non-security aware servers (see 304 Section 2.3.5). 306 If signatures are separately retrieved and verified when retrieving 307 the information they authenticate, there will be more trips to the 308 server and performance will suffer. Security aware servers mitigate 309 that degradation by attempting to send the signature(s) needed (see 310 Section 4.2). 312 2.3.1 The SIG Resource Record 314 The syntax of a SIG resource record (signature) is described in 315 Section 4. It cryptographically binds the RRset being signed to the 316 signer and a validity interval. 318 Every name in a secured zone will have associated with it at least 319 one SIG resource record for each resource type under that name except 320 for glue address RRs and delegation point NS RRs. A security aware 321 server will attempt to return, with RRs retrieved, the corresponding 322 SIGs. If a server is not security aware, the resolver must retrieve 323 all the SIG records for a name and select the one or ones that sign 324 the resource record set(s) that resolver is interested in. 326 2.3.2 Authenticating Name and Type Non-existence 328 The above security mechanism only provides a way to sign existing 329 RRsets in a zone. "Data origin" authentication is not obviously 330 provided for the non-existence of a domain name in a zone or the 331 non-existence of a type for an existing name. This gap is filled by 332 the NXT RR which authenticatably asserts a range of non-existent 333 names in a zone and the non-existence of types for the existing name 334 just before that range. 336 Section 5 below covers the NXT RR. 338 2.3.3 Special Considerations With Time-to-Live 340 A digital signature will fail to verify if any change has occurred to 341 the data between the time it was originally signed and the time the 342 signature is verified. This conflicts with our desire to have the 343 time-to-live (TTL) field of resource records tick down while they are 344 cached. 346 This could be avoided by leaving the time-to-live out of the digital 347 signature, but that would allow unscrupulous servers to set 348 arbitrarily long TTL values undetected. Instead, we include the 349 "original" TTL in the signature and communicate that data along with 350 the current TTL. Unscrupulous servers under this scheme can 351 manipulate the TTL but a security aware resolver will bound the TTL 352 value it uses at the original signed value. Separately, signatures 353 include a signature inception time and a signature expiration time. A 354 resolver that knows the absolute time can determine securely whether 355 a signature is in effect. It is not possible to rely solely on the 356 signature expiration as a substitute for the TTL, however, since the 357 TTL is primarily a database consistency mechanism and non-security 358 aware servers that depend on TTL must still be supported. 360 2.3.4 Special Considerations at Delegation Points 362 DNS security would like to view each zone as a unit of data 363 completely under the control of the zone owner with each entry 364 (RRset) signed by a special private key held by the zone manager. 365 But the DNS protocol views the leaf nodes in a zone, which are also 366 the apex nodes of a subzone (i.e., delegation points), as "really" 367 belonging to the subzone. These nodes occur in two master files and 368 might have RRs signed by both the upper and lower zone's keys. A 369 retrieval could get a mixture of these RRs and SIGs, especially since 370 one server could be serving both the zone above and below a 371 delegation point. [RFC 2181] 373 There MUST be a zone KEY RR, signed by its superzone, for every 374 subzone if the superzone is secure. In the case of an unsecured 375 subzone which can not or will not be modified to add any security 376 RRs, a KEY declaring the subzone to be unsecured MUST appear in and 377 be signed by the superzone, if the superzone is secure. For all but 378 one other RR type the data from the subzone is more authoritative so 379 only the KEY RR in the superzone should be signed. The NS and any 380 glue address RRs should only be signed in the subzone. The SOA and 381 any other RRs that have the zone name as owner should appear only in 382 the subzone and thus are signed only there. The NXT RR type is the 383 exceptional case that will always appear differently and 384 authoritatively in both the superzone and subzone, if both are 385 secure, as described in Section 5. 387 2.3.5 Special Considerations with CNAME 389 There is a problem when security related RRs with the same owner name 390 as a CNAME RR are retrieved from a non-security-aware server. In 391 particular, an initial retrieval for the CNAME or any other type may 392 not retrieve any associated SIG, KEY, or NXT RR. For retrieved types 393 other than CNAME, it will retrieve that type at the target name of 394 the CNAME (or chain of CNAMEs) and will also return the CNAME. In 395 particular, a specific retrieval for type SIG will not get the SIG, 396 if any, at the original CNAME domain name but rather a SIG at the 397 target name. 399 Security aware servers must be used to securely CNAME in DNS. 400 Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along 401 with CNAME RRs, (2) suppress CNAME processing on retrieval of these 402 types as well as on retrieval of the type CNAME, and (3) 403 automatically return SIG RRs authenticating the CNAME or CNAMEs 404 encountered in resolving a query. This is a change from the previous 405 DNS standard [RFCs 1034/1035] which prohibited any other RR type at a 406 node where a CNAME RR was present. 408 2.3.6 Signers Other Than The Zone 410 There are cases where a SIG resource record is signed by other than 411 one of the private key(s) used to authenticate a zone. 413 One is for support of dynamic update [RFC 2136] (or future requests 414 which require secure authentication) where an entity is permitted to 415 authenticate/update its records [RFC 2137]. The public key of the 416 entity must be present in the DNS and be signed by a zone level key 417 but the other RR(s) may be signed with the entity's key. 419 A second case is support of transaction and request authentication as 420 described in Section 2.4. 422 In additions, signatures can be included on resource records within 423 the DNS for use by applications other than DNS. DNS related 424 signatures authenticate that data originated with the zone owner or 425 that a request or transaction originated with the relevant host. 426 Other signatures can provide other types of assurances. 428 2.4 DNS Transaction and Request Authentication 430 The data origin authentication service described above protects 431 retrieved resource records and the non-existence of resource records 432 but provides no protection for DNS requests or for message headers. 434 If header bits are falsely set by a bad server, there is little that 435 can be done. However, it is possible to add transaction 436 authentication. Such authentication means that a resolver can be 437 sure it is at least getting messages from the server it thinks it 438 queried and that the response is from the query it sent (i.e., that 439 these messages have not been diddled in transit). This is 440 accomplished by optionally adding a special SIG resource record at 441 the end of the reply which digitally signs the concatenation of the 442 server's response and the resolver's query. 444 Requests can also be authenticated by including a special SIG RR at 445 the end of the request. Authenticating requests serves no function 446 in older DNS servers and requests with a non-empty additional 447 information section produce error returns or may even be ignored by 448 many of them. However, this syntax for signing requests is defined in 449 connection with authenticating secure dynamic update requests [RFC 450 2137] or future requests requiring authentication. 452 The private keys used in transaction security belong to the host 453 composing the reply, not to the zone involved. Request 454 authentication may also involve the private key of the host composing 455 the request or other private keys depending on the request authority 456 it is sought to establish. The corresponding public key(s) are 457 normally stored in and retrieved from the DNS for verification. 459 Because requests and replies are highly variable, message 460 authentication SIGs can not be pre-calculated. Thus it will be 461 necessary to keep the private key on-line, for example in software or 462 in a directly connected piece of hardware. 464 3. The KEY Resource Record 466 The KEY resource record (RR) is used to store a public key that is 467 associated with a Domain Name System (DNS) name. This can be the 468 public key of a zone, a user, or a host or other end entity. Security 469 aware DNS implementations MUST be designed to handle at least two 470 simultaneously valid keys of the same type associated with the same 471 name. 473 The type number for the KEY RR is 25. 475 A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs 476 must be signed by a zone level key. 478 3.1 KEY RDATA format 480 The RDATA for a KEY RR consists of flags, a protocol octet, the 481 algorithm number octet, and the public key itself. The format is as 482 follows: 484 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | flags | protocol | algorithm | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | / 490 / public key / 491 / / 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 494 The KEY RR is not intended for storage of certificates and a separate 495 certificate RR has been developed for that purpose, defined in 496 [draft-ietf-dnssec-certs-*.txt]. 498 The meaning of the KEY RR owner name, flags, and protocol octet are 499 described in Sections 3.1.1 through 3.1.5 below. The flags and 500 algorithm must be examined before any data following the algorithm 501 octet as they control the existence and format of any following data. 502 The algorithm and public key fields are described in Section 3.2. 503 The format of the public key is algorithm dependent. 505 KEY RRs do not specify their validity period but their authenticating 506 SIG RR(s) do as described in Section 4 below. 508 3.1.1 Object Types, DNS Names, and Keys 510 The public key in a KEY RR is for the object named in the owner name. 512 A DNS name may refer to up to three different categories of things. 513 For example, foo.host.example could be (1) a zone, (2) a host or 514 other end entity , or (3) the mapping into a DNS name of the user or 515 account foo@host.example. Thus, there are flag bits, as described 516 below, in the KEY RR to indicate with which of these roles the owner 517 name and public key are associated. Note that an appropriate zone 518 KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs 519 occur only at delegation points. 521 3.1.2 The KEY RR Flag Field 523 In the "flags" field: 525 1 1 1 1 1 1 526 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 527 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 528 | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG | 529 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 531 Bit 0 and 1 are the key "type" bits whose values have the following 532 meanings: 533 10: Bit 0 a one indicates that use of the key is prohibited 534 for authentication. 535 01: Bit 1 a one indicates that use of the key is prohibited 536 for confidentiality. 537 00: If the bits are zero, then use of the key for 538 authentication and/or confidentiality is permitted. Note that DNS 539 security makes use of keys for authentication only. 540 Confidentiality use flagging is provided for use of keys in other 541 protocols. Implementations not intended to support key 542 distribution for confidentiality MAY require that the 543 confidentiality use prohibited bit be on for keys they serve. 544 11: If both bits are one, the "no key" value, there is no key 545 information and the RR stops after the algorithm octet. By the 546 use of this "no key" value, a signed KEY RR can authenticatably 547 assert that, for example, a zone is not secured. See section 3.4 548 below. 550 Bits 2 is reserved and must be zero. 552 Bits 3 is reserved as a flag extension bit. If it is a one, a second 553 16 bit flag field is added after the algorithm octet and before 554 the key data. This bit MUST NOT be set unless one or more such 555 additional bits have been defined and are non-zero. 557 Bits 4-5 are reserved and must be zero. 559 Bits 6 and 7 form a field that encodes the name type. Field values 560 have the following meanings: 561 00: indicates that this is a key associated with a "user" or 562 "account" at an end entity, usually a host. The coding of the 563 owner name is that used for the responsible individual mailbox in 564 the SOA and RP RRs: The owner name is the user name as the name of 565 a node under the entity name. For example, "j_random_user" on 566 host.subdomain.example could have a public key associated through 567 a KEY RR with name j_random_user.host.subdomain.example. It could 568 be used in a security protocol where authentication of a user was 569 desired. This key might be useful in IP or other security for a 570 user level service such a telnet, ftp, rlogin, etc. 571 01: indicates that this is a zone key for the zone whose name 572 is the KEY RR owner name. This is the public key used for the 573 primary DNS security feature of data origin authentication. Zone 574 KEY RRs occur only at delegation points. 575 10: indicates that this is a key associated with the non-zone 576 "entity" whose name is the RR owner name. This will commonly be a 577 host but could, in some parts of the DNS tree, be some other type 578 of entity such as a telephone number [RFC 1530] or numeric IP 579 address. This is the public key used in connection with DNS 580 request and transaction authentication services if the owner name 581 designates a DNS resolver or server host. It could also be used 582 in an IP-security protocol where authentication at the host, 583 rather than user, level was desired, such as routing, NTP, etc. 584 11: reserved. 586 Bits 8-11 are reserved and must be zero. 588 Bits 12-15 are the "signatory" field. If non-zero, they indicate 589 that the key can validly sign things as specified in DNS dynamic 590 update [RFC 2137]. Note that zone keys (see bits 6 and 7 above) 591 always have authority to sign any RRs in the zone regardless of 592 the value of the signatory field. 594 3.1.3 The Protocol Octet 596 It is anticipated that keys stored in DNS will be used in conjunction 597 with a variety of Internet protocols. It is intended that the 598 protocol octet and possibly some of the currently unused (must be 599 zero) bits in the KEY RR flags as specified in the future will be 600 used to indicate a key's validity for different protocols. 602 The following values of the Protocol Octet are reserved as indicated: 604 VALUE Protocol 606 0 -reserved 607 1 TLS 608 2 email 609 3 dnssec 610 4 IPSEC 611 5-254 - available for assignment by IANA 612 255 All 614 In more detail: 615 1 is reserved to refer to the TLS standard. The presence of a 616 host KEY resource with this protocol value is an assertion that the 617 host speaks TLS. 618 2 is reserved for use in connection with email. 619 3 is used for DNS security. The protocol field should be set to 620 this value for zone keys and other keys used in DNS security. 621 Implementations that can determine that a key is a DNS security key 622 by the fact that flags label it a zone key or the signatory flag 623 field is non-zero are NOT REQUIRED to check the protocol field. 624 4 is reserved to refer to the Oakley/IPSEC [RFC 1825] protocol 625 and indicates that this key is valid for use in conjunction with that 626 security standard. This key could be used in connection with secured 627 communication on behalf of an end entity or user whose name is the 628 owner name of the KEY RR if the entity or user flag bits are set. 629 The presence of a KEY resource with this protocol value is an 630 assertion that the host speaks Oakley/IPSEC. 631 255 indicates that the key can be used in connection with any 632 protocol for which KEY RR protocol octet values have been defined. 633 The use of this value is discouraged and the use of different keys 634 for different protocols is encouraged. 636 3.2 The KEY Algorithm Number Specification 638 This octet is the key algorithm parallel to the same field for the 639 SIG resource as described in Section 4.1. The following values are 640 assigned: 642 VALUE Protocol 644 0 - reserved 645 1 RSA/MD5 [draft-ietf-dnssec-rsa-*.txt] - recommended 646 2 Diffie-Hellman [draft-ietf-dnssec-dhk-*.txt] - key only 647 3 DSA [draft-ietf-dnssec-dss-*.txt] - MANDATORY 648 4 reserved for elliptic curve 649 5-251 - available (see below) 650 252 reserved for indirect keys 651 253 - available (but was "null" [RFC 2065]) 652 254 private (see below) 653 255 - reserved 655 Algorithm specific formats and procedures are given in separate 656 documents. The mandatory to implement for interoperability algorithm 657 is number 3, DSA. It is recommended that the RSA/MD5 algorithm, 658 number 1, also be implemented. Algorithm 2 is used to indicate 659 Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve. 661 Numbers 5 through 251 and 253 are available for assignment should 662 sufficient reason arise. However, the designation of a new algorithm 663 could have a major impact on interoperability and requires an IETF 664 standards action. 666 Number 252 is reserved for the definition of an indirect key format 667 where they actual key material is elsewhere. 669 Number 254 is reserved for private use and will never be assigned a 670 specific algorithm. For number 254, the public key area for the KEY 671 RR and the signature will actually begin with a length byte followed 672 by an Object Identifier (ISO OID) of that length. The OID indicates 673 the private algorithm in use and the remainder of the area is 674 whatever is required by that algorithm. 676 Values 0 and 255 are reserved but the value 0 is used in the 677 algorithm field when that field is not used. An example is in a KEY 678 RR with the top two flag bits on, the "no-key" value, where no key is 679 present. 681 3.3 Interaction of Flags, Algorithm, and Protocol Bytes 683 Various combinations of the no-key type flags, algorithm byte, 684 protocol byte, and any future assigned protocol indicating flags are 685 possible. The meaning of these combinations is indicated below: 687 NK = no key type (flags bits 0 and 1 on) 688 AL = algorithm byte 689 PR = protocols indicated by protocol byte or future assigned flags 690 x represents any valid non-zero value(s). 692 AL PR NK Meaning 693 0 0 0 Illegal, claims key but has bad algorithm field. 694 0 0 1 Specifies total lack of security for owner zone. 695 0 x 0 Illegal, claims key but has bad algorithm field. 696 0 x 1 Specified protocols unsecured, others may be secure. 697 x 0 0 Gives key but no protocols to use it. 698 x 0 1 Denies key for specific algorithm. 699 x x 0 Specifies key for protocols. 700 x x 1 Algorithm not understood for protocol. 702 3.4 Determination of Zone Secure/Unsecured Status 704 A zone KEY RR with the "no-key" type field value (both key type flag 705 bits 0 and 1 on) indicates that the zone named is unsecured while a 706 zone KEY RR with a key present indicates that the zone named is 707 secure. The secured versus unsecured status of a zone may vary with 708 different cryptographic algorithms. Even for the same algorithm, 709 conflicting zone KEY RRs may be present. 711 Zone KEY RRs, like all RRs, are only trusted if they are 712 authenticated by a SIG RR whose signer field is a signer for which 713 the resolver has a public key they trust and where resolver policy 714 permits that signer to sign for the KEY owner name. Untrusted zone 715 KEY RRs MUST be ignored in determining the security status of the 716 zone. However, there can be multiple sets of trusted zone KEY RRs 717 for a zone with different algorithms, signers, etc. 719 For any particular algorithm, zones can be (1) secure, indicating 720 that any retrieved RR must be authenticated by a SIG RR or it will be 721 discarded as bogus, (2) unsecured, indicating that SIG RRs are not 722 expected or required for RRs retrieved from the zone, or (3) 723 experimentally secure, which indicates that SIG RRs might or might 724 not be present but must be checked if found. The status of a zone is 725 determined as follows: 727 1. If, for a zone and algorithm, every trusted zone KEY RR for the 728 zone says there is no key for that zone, it is unsecured for that 729 algorithm. 731 2. If, there is at least one trusted no-key zone KEY RR and one 732 trusted key specifying zone KEY RR, then that zone is only 733 experimentally secure for the algorithm. Both authenticated and 734 non-authenticated RRs for it should be accepted by the resolver. 736 3. If every trusted zone KEY RR that the zone and algorithm has is 737 key specifying, then it is secure for that algorithm and only 738 authenticated RRs from it will be accepted. 740 Examples: 742 (1) A resolver only trusts signatures by the superzone within the 743 DNS hierarchy so it will look only at the KEY RRs that are signed by 744 the superzone. If it finds only no-key KEY RRs, it will assume the 745 zone is not secure. If it finds only key specifying KEY RRs, it will 746 assume the zone is secure and reject any unsigned responses. If it 747 finds both, it will assume the zone is experimentally secure 749 (2) A resolver trusts the superzone of zone Z (to which it got 750 securely from its local zone) and a third party, cert-auth.xy. When 751 considering data from zone Z, it may be signed by the superzone of Z, 752 by cert-auth.xy, by both, or by neither. The following table 753 indicates whether zone Z will be considered secure, experimentally 754 secure, or unsecured, depending on the signed zone KEY RRs for Z; 756 c e r t - a u t h . x y 758 KEY RRs| None | NoKeys | Mixed | Keys | 759 S --+-----------+-----------+----------+----------+ 760 u None | illegal | unsecured | experim. | secure | 761 p --+-----------+-----------+----------+----------+ 762 e NoKeys | unsecured | unsecured | experim. | secure | 763 r --+-----------+-----------+----------+----------+ 764 Z Mixed | experim. | experim. | experim. | secure | 765 o --+-----------+-----------+----------+----------+ 766 n Keys | secure | secure | secure | secure | 767 e +-----------+-----------+----------+----------+ 769 3.5 KEY RRs in the Construction of Responses 771 An explicit request for KEY RRs does not cause any special additional 772 information processing except, of course, for the corresponding SIG 773 RR from a security aware server (see Section 4.2). 775 Security aware DNS servers include KEY RRs as additional information 776 in responses, where a KEY is available, in the following cases: 778 (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same 779 name (perhaps just a zone key) SHOULD be included as additional 780 information if space is available. There will always be at least one 781 such KEY RR in a secure zone in connection with each subzone 782 delegation point, even if it has the no-key type value to indicate 783 that the subzone is unsecured. If not all additional information 784 will fit, type A and AAAA glue RRs have higher priority than KEY 785 RR(s). 787 (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same 788 name (usually just a host RR and NOT the zone key which usually would 789 have a different name) SHOULD be included if space is available. On 790 inclusion of A or AAAA RRs as additional information, the KEY RRset 791 with the same name should also be included but with lower priority 792 than the A or AAAA RRs. 794 4. The SIG Resource Record 796 The SIG or "signature" resource record (RR) is the fundamental way 797 that data is authenticated in the secure Domain Name System (DNS). As 798 such it is the heart of the security provided. 800 The SIG RR unforgably authenticates an RRset [RFC 2181] of a 801 particular type, class, and name and binds it to a time interval and 802 the signer's domain name. This is done using cryptographic 803 techniques and the signer's private key. The signer is frequently 804 the owner of the zone from which the RR originated. 806 The type number for the SIG RR type is 24. 808 4.1 SIG RDATA Format 810 The RDATA portion of a SIG RR is as shown below. The integrity of 811 the RDATA information is protected by the signature field. 813 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 814 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | type covered | algorithm | labels | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | original TTL | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | signature expiration | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | signature inception | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | key tag | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + 826 | / 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 828 / / 829 / signature / 830 / / 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 4.1.1 835 The "type covered" is the type of the other RRs covered by this SIG. 837 4.1.2 Algorithm Number Field 839 This octet is as described in section 3.2. 841 4.1.3 Labels Field 843 The "labels" octet is an unsigned count of how many labels there are 844 in the original SIG RR owner name not counting the null label for 845 root and not counting any initial "*" for a wildcard. If a secured 846 retrieval is the result of wild card substitution, it is necessary 847 for the resolver to use the original form of the name in verifying 848 the digital signature. This field makes it easy to determine the 849 original form. 851 If, on retrieval, the RR appears to have a longer name than indicated 852 by "labels", the resolver can tell it is the result of wildcard 853 substitution. If the RR owner name appears to be shorter than the 854 labels count, the SIG RR must be considered corrupt and ignored. The 855 maximum number of labels allowed in the current DNS is 127 but the 856 entire octet is reserved and would be required should DNS names ever 857 be expanded to 255 labels. The following table gives some examples. 858 The value of "labels" is at the top, the retrieved owner name on the 859 left, and the table entry is the name to use in signature 860 verification except that "bad" means the RR is corrupt. 862 labels= | 0 | 1 | 2 | 3 | 4 | 863 --------+-----+------+--------+----------+----------+ 864 .| . | bad | bad | bad | bad | 865 d.| *. | d. | bad | bad | bad | 866 c.d.| *. | *.d. | c.d. | bad | bad | 867 b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | 868 a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | 870 4.1.4 Original TTL Field 872 The "original TTL" field is included in the RDATA portion to avoid 873 (1) authentication problems that caching servers would otherwise 874 cause by decrementing the real TTL field and (2) security problems 875 that unscrupulous servers could otherwise cause by manipulating the 876 real TTL field. This original TTL is protected by the signature 877 while the current TTL field is not. 879 NOTE: The "original TTL" must be restored into the covered RRs when 880 the signature is verified (see Section 8). This implies that all RRs 881 for a particular type, name, and class, that is, all the RRs in any 882 particular RRset, must have the same TTL to start with. 884 4.1.5 Signature Expiration and Inception Fields 886 The SIG is valid from the "signature inception" time until the 887 "signature expiration" time. Both are unsigned numbers of seconds 888 since the start of 1 January 1970, GMT, ignoring leap seconds. (See 889 also Section 4.4.) Ring arithmetic is used as for DNS SOA serial 890 numbers [RFC 1982] which means that these times can never be more 891 than about 136.09 years in the future. A SIG RR may have an 892 expiration time numerically less than the inception time if the 893 expiration time is near the 32 bit wrap around point and/or the 894 signature is long lived. 896 (To prevent misordering of network requests to update a zone 897 dynamically, monotonically increasing "signature inception" times may 898 be necessary. [RFC 2137]) 900 SOA serial numbers for secure zones MUST not only be advanced when 901 their data is updated but also when new SIG RRs are inserted (ie, the 902 zone or any part of it is re-signed). 904 4.1.6 Key Tag Field 906 The "key Tag" is a two octet quantity that is used to efficiently 907 select between multiple keys which may be applicable and thus check 908 that a public key about to be used for the computationally expensive 909 effort to check the signature is possibly valid. For algorithm 1 910 (MD5/RSA) as defined in [draft-ietf-dnssec-rsa-*.txt], it is the next 911 to the bottom two octets of the public key modulus needed to decode 912 the signature field. That is to say, the most significant 16 of the 913 least significant 24 bits of the modulus in network (big endian) 914 order. For all other algorithms, including private algorithms, it is 915 calculated as a simple checksum of the KEY RR as described in 916 Appendix C. 918 4.1.7 Signer's Name Field 920 The "signer's name" field is the domain name of the signer generating 921 the SIG RR. This is the owner name of the public KEY RR that can be 922 used to verify the signature. It is frequently the zone which 923 contained the RRset being authenticated. Which signers should be 924 authorized to sign what is a significant resolver policy question as 925 discussed in Section 6. The signer's name may be compressed with 926 standard DNS name compression when being transmitted over the 927 network. 929 4.1.8 Signature Field 931 The actual signature portion of the SIG RR binds the other RDATA 932 fields to the RRset of the "type covered" RRs with that owner name 933 and class. This covered RRset is thereby authenticated. To 934 accomplish this, a data sequence is constructed as follows: 936 data = RDATA | RR(s)... 938 where "|" is concatenation, 940 RDATA is the wire format of all the RDATA fields in the SIG RR itself 941 (including the canonical form of the signer's name) before but not 942 including the signature, and 944 RR(s) is the RRset of the RR(s) of the type covered with the same 945 owner name and class as the SIG RR in canonical form and order as 946 defined in Section 8. 948 How this data sequence is processed into the signature is algorithm 949 dependent. These algorithm dependent formats and procedures are 950 described in separate documents (Section 3.2). 952 SIGs SHOULD NOT be included in a zone for any "meta-type" such as 953 ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR). 955 4.1.8.1 Calculating Transaction and Request SIGs 957 A response message from a security aware server may optionally 958 contain a special SIG at the end of the additional information 959 section to authenticate the transaction. 961 This SIG has a "type covered" field of zero, which is not a valid RR 962 type. It is calculated by using a "data" (see Section 4.1.8) of the 963 entire preceding DNS reply message, including DNS header but not the 964 IP header and before the reply RR counts have been adjusted for the 965 inclusion of any transaction SIG, concatenated with the entire DNS 966 query message that produced this response, including the query's DNS 967 header and any request SIGs but not its IP header. That is 969 data = full response (less transaction SIG) | full query 971 Verification of the transaction SIG (which is signed by the server 972 host key, not the zone key) by the requesting resolver shows that the 973 query and response were not tampered with in transit, that the 974 response corresponds to the intended query, and that the response 975 comes from the queried server. 977 A DNS request may be optionally signed by including one or more SIGs 978 at the end of the query. Such SIGs are identified by having a "type 979 covered" field of zero. They sign the preceding DNS request message 980 including DNS header but not including the IP header or any request 981 SIGs at the end and before the request RR counts have been adjusted 982 for the inclusions of any request SIG(s). 984 WARNING: Request SIGs are unnecessary for any currently defined 985 request other than update [RFC 2136, 2137] and will cause many old 986 DNS servers to give an error return or ignore a query. However, such 987 SIGs may in the future been needed for other requests. 989 Except where needed to authenticate an update or similar privileged 990 request, servers are not required to check request SIGs. 992 4.2 SIG RRs in the Construction of Responses 994 Security aware DNS servers SHOULD, for every authenticated RRset the 995 query will return, attempt to send the available SIG RRs which 996 authenticate the requested RRset. The following rules apply to the 997 inclusion of SIG RRs in responses: 999 1. when an RRset is placed in a response, its SIG RR has a higher 1000 priority for inclusion than additional RRs that may need to be 1001 included. If space does not permit its inclusion, the response 1002 MUST be considered truncated except as provided in 2 below. 1004 2. When a SIG RR is present in the zone for an additional 1005 information section RR, the response MUST NOT be considered 1006 truncated merely because space does not permit the inclusion of 1007 the SIG RR with the additional information. 1009 3. SIGs to authenticate glue records and NS RRs for subzones at a 1010 delegation point are unnecessary and MUST NOT be sent. (Note 1011 that KEYs given for a subzone in that subzone's superzone are 1012 controlling so the superzone's signature on the KEY MUST be 1013 included (unless the KEY was additional information and the SIG 1014 did not fit).) 1016 4. If a SIG covers any RR that would be in the answer section of 1017 the response, its automatic inclusion MUST be in the answer 1018 section. If it covers an RR that would appear in the authority 1019 section, its automatic inclusion MUST be in the authority 1020 section. If it covers an RR that would appear in the additional 1021 information section it MUST appear in the additional information 1022 section. This is a change in the existing standard [RFCs 1034, 1023 1035] which contemplates only NS and SOA RRs in the authority 1024 section. 1026 5. Optionally, DNS transactions may be authenticated by a SIG RR at 1027 the end of the response in the additional information section 1028 (Section 4.1.8.1). Such SIG RRs are signed by the DNS server 1029 originating the response. Although the signer field MUST be a 1030 name of the originating server host, the owner name, class, TTL, 1031 and original TTL, are meaningless. The class and TTL fields 1032 SHOULD be zero. To conserve space, the owner name SHOULD be 1033 root (a single zero octet). If transaction authentication is 1034 desired, that SIG RR must be considered the highest priority for 1035 inclusion. 1037 4.3 Processing Responses and SIG RRs 1039 The following rules apply to the processing of SIG RRs included in a 1040 response: 1042 1. A security aware resolver that receives a response from a 1043 security aware server via a secure communication with the AD bit 1044 (see Section 6.1) set, MAY choose to accept the RRs as received 1045 without verifying the zone SIG RRs. 1047 2. In other cases, a security aware resolver SHOULD verify the SIG 1048 RRs for the RRs of interest. This may involve initiating 1049 additional queries for SIG or KEY RRs, especially in the case of 1050 getting a response from an server that does not implement 1051 security. (As explained in 2.3.5 above, it will not be possible 1052 to secure CNAMEs being served up by non-secure resolvers.) 1054 NOTE: Implementers might expect the above SHOULD to be a MUST. 1055 However, local policy or the calling application may not require 1056 the security services. 1058 3. If SIG RRs are received in response to a user query explicitly 1059 specifying the SIG type, no special processing is required. 1061 If the message does not pass integrity checks or the SIG does not 1062 check against the signed RRs, the SIG RR is invalid and should be 1063 ignored. If all of the SIG RR(s) purporting to authenticate an RRset 1064 are invalid, then the RRset is not authenticated. 1066 If the SIG RR is the last RR in a response in the additional 1067 information section and has a type covered of zero, it is a 1068 transaction signature of the response and the query that produced the 1069 response. It MAY be optionally checked and the message rejected if 1070 the checks fail. But even if the checks succeed, such a transaction 1071 authentication SIG does NOT directly authenticate any RRs in the 1072 message. Only a proper SIG RR signed by the zone or a key tracing 1073 its authority to the zone or to static resolver configuration can 1074 directly authenticate RRs, depending on resolver policy (see Section 1075 6). If a resolver does not implement transaction and/or request 1076 SIGs, it MUST ignore them without error. 1078 If all checks indicate that the SIG RR is valid then RRs verified by 1079 it should be considered authenticated. 1081 4.4 Signature Lifetime, Expiration, TTLs, and Validity 1083 Security aware servers MUST NOT consider SIG RRs to authenticate 1084 anything before their signature inception or after its expiration 1085 time (see also Section 6). Security aware servers MUST NOT consider 1086 any RR to be authenticated after all its signatures have expired. 1087 When a secure server caches authenticated data, if the TTL would 1088 expire at a time further in the future than the authentication 1089 expiration time, the server SHOULD trim the TTL in the cache entry 1090 not to extent beyond the authentication expiration time. Within 1091 these constraints, servers should continue to follow DNS TTL aging. 1092 Thus authoritative servers should continue to follow the zone refresh 1093 and expire parameters and a non-authoritative server should count 1094 down the TTL and discard RRs when the TTL is zero (even for a SIG 1095 that has not yet reached its authentication expiration time). In 1096 addition, when RRs are transmitted in a query response, the TTL 1097 should be trimmed so that current time plus the TTL does not extend 1098 beyond the authentication expiration time. Thus, in general, the TTL 1099 on a transmitted RR would be 1101 min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) 1103 When signatures are generated, signature expiration times should be 1104 set far enough in the future that it is quite certain that new 1105 signatures can be generated before the old ones expire. However, 1106 setting expiration too far into the future could mean a long time to 1107 flush any bad data or signatures that may have been generated. 1109 It is recommended that signature lifetime be a small multiple of the 1110 TTL (ie, 4 to 16 times the TTL) but not less than a reasonable 1111 maximum re-signing interval and not less than the zone expiry time. 1113 5. Non-existent Names and Types 1115 The SIG RR mechanism described in Section 4 above provides strong 1116 authentication of RRs that exist in a zone. But it is not clear 1117 above how to verifiably deny the existence of a name in a zone or a 1118 type for an existent name. 1120 The nonexistence of a name in a zone is indicated by the NXT ("next") 1121 RR for a name interval containing the nonexistent name. An NXT RR or 1122 RRs and its or their SIG(s) are returned in the authority section, 1123 along with the error, if the server is security aware. The same is 1124 true for a non-existent type under an existing name except that there 1125 is no error indication other than an empty answer section 1126 accompanying the NXT(s). This is a change in the existing standard 1127 [RFCs 1034/1035] which contemplates only NS and SOA RRs in the 1128 authority section. NXT RRs will also be returned if an explicit query 1129 is made for the NXT type. 1131 The existence of a complete set of NXT records in a zone means that 1132 any query for any name and any type to a security aware server 1133 serving the zone will result in an reply containing at least one 1134 signed RR unless it is a query for delegation point NS or glue A or 1135 AAAA RRs. 1137 5.1 The NXT Resource Record 1139 The NXT resource record is used to securely indicate that RRs with an 1140 owner name in a certain name interval do not exist in a zone and to 1141 indicate what RR types are present for an existing name. 1143 The owner name of the NXT RR is an existing name in the zone. It's 1144 RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone 1145 create a chain of all of the literal owner names in that zone, 1146 including unexpanded wildcard but omitting the owner name of glue 1147 address records unless they would otherwise be included. This implies 1148 a canonical ordering of all domain names in a zone as described in 1149 Section 8. The presence of the NXT RR means that no name between its 1150 owner name and the name in its RDATA area exists and that no other 1151 types exist under its owner name. 1153 There is a potential problem with the last NXT in a zone as it wants 1154 to have an owner name which is the last existing name in canonical 1155 order, which is easy, but it is not obvious what name to put in its 1156 RDATA to indicate the entire remainder of the name space. This is 1157 handled by treating the name space as circular and putting the zone 1158 name in the RDATA of the last NXT in a zone. 1160 The NXT RRs for a zone SHOULD be automatically calculated and added 1161 to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed 1162 the zone minimum TTL. 1164 The type number for the NXT RR is 30. 1166 NXT RRs are only signed by zone level keys. 1168 5.2 NXT RDATA Format 1170 The RDATA for an NXT RR consists simply of a domain name followed by 1171 a bit map, as shown below. 1173 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | next domain name / 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | type bit map / 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 The NXT RR type bit map format currently defined is one bit per RR 1182 type present for the owner name. A one bit indicates that at least 1183 one RR of that type is present for the owner name. A zero indicates 1184 that no such RR is present. All bits not specified because they are 1185 beyond the end of the bit map are assumed to be zero. Note that bit 1186 30, for NXT, will always be on so the minimum bit map length is 1187 actually four octets. Trailing zero octets are prohibited in this 1188 format. The first bit represents RR type zero (an illegal type which 1189 can not be present) and so will be zero in this format. This format 1190 is not used if there exists an RR with a type number greater than 1191 127. If the zero bit of the type bit map is a one, it indicates that 1192 a different format is being used which will always be the case if a 1193 type number greater than 127 is present. 1195 The domain name may be compressed with standard DNS name compression 1196 when being transmitted over the network. The size of the bit map can 1197 be inferred from the RDLENGTH and the length of the next domain name. 1199 5.3 Additional Complexity Due to Wildcards 1201 Proving that a non-existent name response is correct or that a 1202 wildcard expansion response is correct makes things a little more 1203 complex. 1205 In particular, when a non-existent name response is returned, an NXT 1206 must be returned showing that the exact name queried did not exist 1207 and, in general, one or more additional NXT's need to be returned to 1208 also prove that there wasn't a wildcard whose expansion should have 1209 been returned except that there is no need to return multiple copies 1210 of the same NXT. These NXTs, if any, are returned in the authority 1211 section of the response. 1213 Furthermore, if a wildcard expansion is returned in a response, in 1214 general one or more NXTs needs to also be returned in the authority 1215 section to prove that no more specific name (including possibly more 1216 specific wildcards in the zone) existed on which the response should 1217 have been based. 1219 5.4 Example 1221 Assume zone foo.nil has entries for 1223 big.foo.nil, 1224 medium.foo.nil. 1225 small.foo.nil. 1226 tiny.foo.nil. 1228 Then a query to a security aware server for huge.foo.nil would 1229 produce an error reply with an RCODE of NXDOMAIN and the authority 1230 section data including something like the following: 1232 foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil 1233 foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 1234 19970102030405 ;signature expiration 1235 19961211100908 ;time signed 1236 2143 ;key identifier 1237 foo.nil. ;signer 1238 AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm 1239 fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) 1240 ) 1241 big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil 1242 big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 1243 19970102030405 ;signature expiration 1244 19961211100908 ;time signed 1245 2143 ;key identifier 1246 foo.nil. ;signer 1247 MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 1248 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) 1249 ) 1251 Note that this response implies that big.foo.nil is an existing name 1252 in the zone and thus has other RR types associated with it than NXT. 1253 However, only the NXT (and its SIG) RR appear in the response to this 1254 query for huge.foo.nil, which is a non-existent name. 1256 5.5 Special Considerations at Delegation Points 1258 A name (other than root) which is the head of a zone also appears as 1259 the leaf in a superzone. If both are secure, there will always be 1260 two different NXT RRs with the same name. They can be easily 1261 distinguished by their signers, the next domain name fields, the 1262 presence of the SOA type bit, etc. Security aware servers should 1263 return the correct NXT automatically when required to authenticate 1264 the non-existence of a name and both NXTs, if available, on explicit 1265 query for type NXT. 1267 Non-security aware servers will never automatically return an NXT and 1268 some old implementations may only return the NXT from the subzone on 1269 explicit queries. 1271 5.6 Zone Transfers 1273 The subsections below describe how full and incremental zone 1274 transfers are secured. 1276 SIG RRs secure all authoritative RRs transferred for both full and 1277 incremental [RFC 1995] zone transfers. NXT RRs are an essential 1278 elements in secure zone transfers and assure that every authoritative 1279 name and type will be present; however, if there are multiple SIGs 1280 with the same name and type covered, a subset of the SIGs could be 1281 sent as long as at least one is present and, in the case of unsigned 1282 delegation point NS or glue A or AAAA RRs a subset of these RRs or 1283 simply a modified set could be sent as long as at least one of each 1284 type is included. 1286 When an incremental or full zone transfer request is received with 1287 the same or newer version number than that of the server's copy of 1288 the zone, it is replied to with just the SOA RR of the server's 1289 current version and the SIG RRset verifying that SOA RR. 1291 The complete NXT chaims specified in this document enable a resolver 1292 to obtain, by successive queries chaining through NXTs, all of the 1293 names in a zone even if zone transfers are prohibited. Different 1294 format NXTs may be specified in the future to avoid this. 1296 5.6.1 Full Zone Transfers 1298 To provide server authentication that a complete transfer has 1299 occurred, transaction authentication SHOULD be used on all full zone 1300 transfers. This provides strong server based protection for the 1301 entire zone in transit. 1303 5.6.2 Incremental Zone Transfers 1305 Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be 1306 verified in the same way as for a full zone transfer and the 1307 integrity of the NXT name chain and correctness of the NXT type bits 1308 for the zone after the incremental RR deletes and adds can check each 1309 disjoint area of the zone updated. But the completeness of an 1310 incremental transfer can not be confirmed because usually neither the 1311 deleted RR section nor the added RR section has a compete NXT chain. 1312 As a result, a server which securely supports IXFR must handle IXFR 1313 SIG RRs for each incremental transfer set that it maintains. 1315 The IXFR SIG is calculated over the incremental zone update 1316 collection of RRs in the order in which it is transmitted: old SOA, 1317 then deleted RRs, then new SOA and added RRs. Within each section, 1318 RRs must be ordered as specified in Section 8. If condensation of 1319 adjacent incremental update sets is done by the zone owner, the 1320 original IXFR SIG for each set included in the condensation must be 1321 discarded and a new on IXFR SIG calculated to cover the resulting 1322 condensed set. 1324 The IXFR SIG really belongs to the zone as a whole, not to the zone 1325 name. Although it SHOULD be correct for the zone name, the labels 1326 field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only 1327 sent as part of an incremental zone transfer. After validation of 1328 the IXFR SIG, the transferred RRs MAY be considered valid without 1329 verification of the internal SIGs if such trust in the server 1330 conforms to local policy. 1332 6. How to Resolve Securely and the AD and CD Bits 1334 Retrieving or resolving secure data from the Domain Name System (DNS) 1335 involves starting with one or more trusted public keys that have been 1336 staticly configured at the resolver. With starting trusted keys, a 1337 resolver willing to perform cryptography can progress securely 1338 through the secure DNS structure to the zone of interest as described 1339 in Section 6.3. Such trusted public keys would normally be configured 1340 in a manner similar to that described in Section 6.2. However, as a 1341 practical matter, a security aware resolver would still gain some 1342 confidence in the results it returns even if it was not configured 1343 with any keys but trusted what it got from a local well known server 1344 as if it were staticly configured. 1346 Data stored at a security aware server needs to be internally 1347 categorized as Authenticated, Pending, or Insecure. There is also a 1348 fourth transient state of Bad which indicates that all SIG checks 1349 have explicitly failed on the data. Such Bad data is not retained at 1350 a security aware server. Authenticated means that the data has a 1351 valid SIG under a KEY traceable via a chain of zero or more SIG and 1352 KEY RRs allowed by the resolvers policies to a KEY staticly 1353 configured at the resolver. Pending data has no authenticated SIGs 1354 and at least one additional SIG the resolver is still trying to 1355 authenticate. Insecure data is data which it is known can never be 1356 either Authenticated or found Bad in the zone where it was found 1357 because it is in or has been reached via a unsecured zone or because 1358 it is unsigned glue address or delegation point NS data. Behavior in 1359 terms of control of and flagging based on such data labels is 1360 described in Section 6.1. 1362 The proper validation of signatures requires a reasonably secure 1363 shared opinion of the absolute time between resolvers and servers as 1364 described in Section 6.4. 1366 6.1 The AD and CD Header Bits 1368 Two previously unused bits are allocated out of the DNS 1369 query/response format header. The AD (authentic data) bit indicates 1370 in a response that all the data included in the answer and authority 1371 portion of the response has been authenticated by the server 1372 according to the policies of that server. The CD (checking disabled) 1373 bit indicates in a query that Pending (non-authenticated) data is 1374 acceptable to the resolver sending the query. 1376 These bits are allocated from the previously must-be-zero Z field as 1377 follows: 1379 1 1 1 1 1 1 1380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1381 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1382 | ID | 1383 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1384 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 1385 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1386 | QDCOUNT | 1387 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1388 | ANCOUNT | 1389 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1390 | NSCOUNT | 1391 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1392 | ARCOUNT | 1393 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1395 These bits are zero in old servers and resolvers. Thus the responses 1396 of old servers are not flagged as authenticated to security aware 1397 resolvers and queries from non-security aware resolvers do not assert 1398 the checking disabled bit and thus will be answered by security aware 1399 servers only with Authenticated or Insecure data. Security aware 1400 resolvers MUST NOT trust the AD bit unless they trust the server they 1401 are talking to and either have a secure path to it or use DNS 1402 transaction security. 1404 Any security aware resolver willing to do cryptography SHOULD assert 1405 the CD bit on all queries to permit it to impose its own policies and 1406 to reduce DNS latency time by allowing security aware servers to 1407 answer with Pending data. 1409 Security aware servers MUST NOT return Bad data. For non-security 1410 aware resolvers or security aware resolvers requesting service by 1411 having the CD bit clear, security aware servers MUST return only 1412 Authenticated or Insecure data in the answer and authority sections 1413 with the AD bit set in the response. Security aware servers SHOULD 1414 return Pending data, with the AD bit clear in the response, to 1415 security aware resolvers requesting this service by asserting the CD 1416 bit in their request. The AD bit MUST NOT be set on a response 1417 unless all of the RRs in the answer and authority sections of the 1418 response are either Authenticated or Insecure. The AD bit does not 1419 cover the additional information section. 1421 6.2 Staticly Configured Keys 1423 The public key to authenticate a zone SHOULD be defined in local 1424 configuration files before that zone is loaded at the primary server 1425 so the zone can be authenticated. 1427 While it might seem logical for everyone to start with a public key 1428 associated with the root zone and staticly configure this in every 1429 resolver, this has problems. The logistics of updating every DNS 1430 resolver in the world should this key ever change would be severe. 1431 Furthermore, many organizations will explicitly wish their "interior" 1432 DNS implementations to completely trust only their own DNS servers. 1433 Interior resolvers of such organizations can then go through the 1434 organization's zone servers to access data outsize the organization's 1435 domain and need not be configured with keys above the organization's 1436 DNS apex. 1438 Host resolvers that are not part of a larger organization may be 1439 configured with a key for the domain of their local ISP whose 1440 recursive secure DNS caching server they use. 1442 6.3 Chaining Through The DNS 1444 Starting with one or more trusted keys for any zone, it should be 1445 possible to retrieve signed keys for that zone's subzones which have 1446 a key. A secure sub-zone is indicated by a KEY RR with non-null key 1447 information appearing with the NS RRs for the sub-zone. These make 1448 it possible to descend within the tree of zones. 1450 6.3.1 Chaining Through KEYs 1452 In general, some RRset that you wish to validate in the secure DNS 1453 will be signed by one or more SIG RRs. Each of these SIG RRs has a 1454 signer under whose name is stored the public KEY to use in 1455 authenticating the SIG. Each of those KEYs will, generally, also be 1456 signed with a SIG. And those SIGs will have signer names also 1457 referring to KEYs. And so on. As a result, authentication leads to 1458 chains of alternating SIG and KEY RRs with the first SIG signing the 1459 original data whose authenticity is to be shown and the final KEY 1460 being some trusted key staticly configured at the resolver performing 1461 the authentication. 1463 In testing such a chain, the validity periods of the SIGs encountered 1464 must be intersected to determine the validity period of the 1465 authentication of the data, a purely algorithmic process. In 1466 addition, the validation of each SIG over the data with reference to 1467 a KEY must meet the objective cryptographic test implied by the 1468 cryptographic algorithm used (although even here the resolver may 1469 have policies as to trusted algorithms and key lengths). Finally, 1470 the judgement that a SIG with a particular signer name can 1471 authenticate data (possibly a KEY RRset) with a particular owner 1472 name, is primarily a policy question. Ultimately, this is a policy 1473 local to the resolver and any clients that depend on that resolver's 1474 decisions. It is, however, recommended, that the policy below be 1475 adopted: 1477 Let A < B mean that A is a shorter domain name than B formed by 1478 dropping one or more whole labels from the left end of B, i.e., 1479 A is a direct or indirect superdomain of B. Let A = B mean that 1480 A and B are the same domain name (i.e., are identical after 1481 letter case canonicalization). Let A > B mean that A is a 1482 longer domain name than B formed by adding one or more whole 1483 labels on the left end of B, i.e., A is a direct or indirect 1484 subdomain of B 1486 Let Static be the owner names of the set of staticly configured 1487 trusted keys at a resolver. 1489 Then Signer is a valid signer name for a SIG authenticating an 1490 RRset (possibly a KEY RRset) with owner name Owner at a resolver 1491 if any of the following three rules apply: 1493 (1) Owner > or = Signer (except that if Signer is root, Owner 1494 must be root or a top level domain name). That is, Owner is the 1495 same as or a subdomain of Signer. 1497 (2) ( Owner < Signer ) and ( Signer > or = some Static ). That 1498 is, Owner is a superdomain of Signer and Signer is staticly 1499 configured or a subdomain of a staticly configured key. 1501 (3) Signer = some Static. That is, the signer is exactly some 1502 staticly configured key. 1504 Rule 1 is the rule for descending the DNS tree and includes a special 1505 prohibition on the root zone key due to the restriction that the root 1506 zone be only one label deep. This is the most fundamental rule. 1508 Rule 2 is the rule for ascending the DNS tree from one or more 1509 staticly configured keys. Rule 2 has no effect if only root zone 1510 keys are staticly configured. 1512 Rule 3 is a rule permitting direct cross certification. Rule 3 has 1513 no effect if only root zone keys are staticly configured. 1515 Great care should be taken that the consequences have been fully 1516 considered before making any local policy adjustments to these rules 1517 (other than dispensing with rules 2 and 3 if only root zone keys are 1518 staticly configured). 1520 6.3.2 Conflicting Data 1522 It is possible that there will be multiple SIG-KEY chains that appear 1523 to authenticate conflicting RRset answers to the same query. A 1524 resolver should choose only the most reliable answer to return and 1525 discard other data. This choice of most reliable is a matter of 1526 local policy which could take into account differing trust in 1527 algorithms, key sizes, staticly configured keys, zones traversed, 1528 etc. The technique given below is recommended for taking into 1529 account SIG-KEY chain length. 1531 A resolver should keep track of the number of successive secure zones 1532 traversed from a staticly configured key starting point to any secure 1533 zone it can reach. In general, the lower such a distance number is, 1534 the greater the confidence in the data. Staticly configured data 1535 should be given a distance number of zero. If a query encounters 1536 different Authenticated data for the same query with different 1537 distance values, that with a larger value should be ignored unless 1538 some other local policy covers the case. 1540 A security conscious resolver should completely refuse to step from a 1541 secure zone into a unsecured zone unless the unsecured zone is 1542 certified to be non-secure by the presence of an authenticated KEY RR 1543 for the unsecured zone with the no-key type value. Otherwise the 1544 resolver is getting bogus or spoofed data. 1546 If legitimate unsecured zones are encountered in traversing the DNS 1547 tree, then no zone can be trusted as secure that can be reached only 1548 via information from such non-secure zones. Since the unsecured zone 1549 data could have been spoofed, the "secure" zone reach via it could be 1550 counterfeit. The "distance" to data in such zones or zones reached 1551 via such zones could be set to 256 or more as this exceeds the 1552 largest possible distance through secure zones in the DNS. 1554 6.4 Secure Time 1556 Coordinated interpretation of the time fields in SIG RRs requires 1557 that reasonably consistent time be available to the hosts 1558 implementing the DNS security extensions. 1560 A variety of time synchronization protocols exist including the 1561 Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are 1562 used, they MUST be used securely so that time can not be spoofed. 1563 Otherwise, for example, a host could get its clock turned back and 1564 might then believe old SIG RRs, and the data they authenticate, which 1565 were valid but are no longer. 1567 7. ASCII Representation of Security RRs 1569 This section discusses the format for master file and other ASCII 1570 presentation of the three DNS security resource records. 1572 The algorithm field in KEY and SIG RRs can be represented as either 1573 an unsigned integer or symbolicly. The following initial symbols are 1574 defined as indicated: 1576 Value Symbol 1578 001 RSAMD5 1579 002 DH 1580 003 DSA 1581 004 ECC 1582 252 INDIRECT 1583 253 NULL (obsolete, see RFC 2065) 1584 254 PRIVATE 1586 7.1 Presentation of KEY RRs 1588 KEY RRs may appear as single logical lines in a zone data master file 1589 [RFC 1033]. 1591 The flag field is represented as an unsigned integer or a sequence of 1592 mnemonics as follows separated by instances of the verticle bar ("|") 1593 character: 1595 BIT Mnemonic Explanation 1596 0-1 key type 1597 NOCONF =1 confidentiality use prohibited 1598 NOAUTH =2 authentication use prohibited 1599 NOKEY =3 no key present 1600 2 FLAG2 - reserved 1601 3 EXTEND flags extension 1602 4 FLAG4 - reserved 1603 5 FLAG5 - reserved 1604 6-7 name type 1605 USER =0 (default, may be omitted) 1606 ZONE =1 1607 HOST =2 (host or other end entity) 1608 NTYP3 - reserved 1609 8 FLAG8 - reserved 1610 9 FLAG9 - reserved 1611 10 FLAG10 - reserved 1612 11 FLAG11 - reserved 1613 12-15 signatory field, values 0 to 15 1614 can be represented by SIG0, SIG1, ... SIG15 1616 No flag mnemonic need be present if the bit or field it repesents is 1617 zero. 1619 The protocol octet can be represented as either an unsigned integer 1620 or symbolicly. The following initial symbols are defined: 1622 000 NONE 1623 001 TLS 1624 002 EMAIL 1625 003 DNSSEC 1626 004 IPSEC 1627 255 ALL 1629 Note that if the type flags field has the NOKEY value, nothing 1630 appears after the algorithm octet. 1632 The remaining public key portion is represented in base 64 (see 1633 Appendix A) and may be divided up into any number of white space 1634 separated substrings, down to single base 64 digits, which are 1635 concatenated to obtain the full signature. These substrings can span 1636 lines using the standard parenthesis. 1638 Note that the public key may have internal sub-fields but these do 1639 not appear in the master file representation. For example, with 1640 algorithm 1 there is a public exponent size, then a public exponent, 1641 and then a modulus. With algorithm 254, there will be an OID size, 1642 an OID, and algorithm dependent information. But in both cases only a 1643 single logical base 64 string will appear in the master file. 1645 7.2 Presentation of SIG RRs 1647 A data SIG RR may be represented as a single logical line in a zone 1648 data file [RFC 1033] but there are some special considerations as 1649 described below. (It does not make sense to include a transaction or 1650 request authenticating SIG RR in a file as they are a transient 1651 authentication that covers data including an ephemeral transaction 1652 number and so must be calculated in real time.) 1654 There is no particular problem with the signer, covered type, and 1655 times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY 1656 is the year, the first MM is the month number (01-12), DD is the day 1657 of the month (01-31), HH is the hour in 24 hours notation (00-23), 1658 the second MM is the minute (00-59), and SS is the second (00-59). 1660 The original TTL field appears as an unsigned integer. 1662 If the original TTL, which applies to the type signed, is the same as 1663 the TTL of the SIG RR itself, it may be omitted. The date field 1664 which follows it is larger than the maximum possible TTL so there is 1665 no ambiguity. 1667 The "labels" field appears as an unsigned integer. 1669 The key tag appears as an unsigned number. 1671 However, the signature itself can be very long. It is the last data 1672 field and is represented in base 64 (see Appendix A) and may be 1673 divided up into any number of white space separated substrings, down 1674 to single base 64 digits, which are concatenated to obtain the full 1675 signature. These substrings can be split between lines using the 1676 standard parenthesis. 1678 7.3 Presentation of NXT RRs 1680 NXT RRs do not appear in original unsigned zone master files since 1681 they should be derived from the zone as it is being signed. If a 1682 signed file with NXTs added is printed or NXTs are printed by 1683 debugging code, they appear as the next domain name followed by the 1684 RR type present bits as an unsigned interger or sequence of RR 1685 mnemonics. 1687 8. Canonical Form and Order of Resource Records 1689 This section describes the canonical form of resource records (RRs), 1690 their default name order, and their order, for purposes of domain 1691 name system (DNS) security. A canonical name order is necessary to 1692 construct the NXT name chain. A canonical form and ordering within 1693 an RRset is necessary in consistently constructing and verifying SIG 1694 RRs. A canonical ordering of types within a name is required in 1695 connection with incremental transfer (Section 5.6.2). 1697 8.1 Canonical RR Form 1699 For purposes of DNS security, the canonical form for an RR is the 1700 wire format of the RR with domain names (1) fully expanded (no name 1701 compression via pointers), (2) all domain name letters set to lower 1702 case, (3) owner name wild cards in master file form (no substitution 1703 made for *), and (4) the original TTL substituted for the current 1704 TTL. 1706 8.2 Canonical DNS Name Order 1708 For purposes of DNS security, the canonical ordering of owner names 1709 is to sort individual labels as unsigned left justified octet strings 1710 where the absence of a octet sorts before a zero value octet and 1711 upper case letters are treated as lower case letters. Names are then 1712 sorted by sorting on the highest level label and then, within those 1713 names with the same highest level label by the next lower label, etc. 1714 down to leaf node labels. Within a zone, the zone name itself always 1715 exists and all other names are the zone name with some prefix of 1716 lower level labels. Thus the zone name itself always sorts first. 1718 Example: 1719 foo.example 1720 a.foo.example 1721 yljkjljk.a.foo.example 1722 Z.a.foo.example 1723 zABC.a.FOO.EXAMPLE 1724 z.foo.example 1725 *.z.foo.example 1726 \200.z.foo.example 1728 8.3 Canonical RR Ordering Within An RRset 1730 Within any particular owner name and type, RRs are sorted by RDATA as 1731 a left justified unsigned octet sequence where the absence of an 1732 octet sorts before the zero octet. 1734 8.4 Canonical Ordering of RR Types 1736 When RRs of the same name but different types must be ordered, they 1737 are ordered by type, considering the type to be an unsigned integer, 1738 except that SIG RRs are placed immediately after the type they cover. 1739 Thus, for example, an A record would be put before an MX record 1740 because A is type 1 and MX is type 15 but if both were signed, the 1741 order would be A < SIG(A) < MX < SIG(MX). 1743 9. Conformance 1745 Levels of server and resolver conformance are defined below. 1747 9.1 Server Conformance 1749 Two levels of server conformance for DNS security are defined as 1750 follows: 1752 BASIC: Basic server compliance is the ability to store and retrieve 1753 (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or 1754 caching server for a secure zone MUST have at least basic compliance 1755 and even then some things, such as secure CNAMEs, will not work 1756 without full compliance. 1758 FULL: Full server compliance adds the following to basic compliance: 1759 (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) 1760 ability, given a zone file and private key, to add appropriate SIG 1761 and NXT RRs, possibly via a separate application, (3) proper 1762 automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) 1763 suppression of CNAME following on retrieval of the security type RRs, 1764 (5) recognize the CD query header bit and set the AD query header 1765 bit, as appropriate, and (6) proper handling of the two NXT RRs at 1766 delegation points. Primary servers for secure zones MUST be fully 1767 compliant and for complete secure operation, all secondary, caching, 1768 and other servers handling the zone SHOULD be fully compliant as 1769 well. 1771 9.2 Resolver Conformance 1773 Two levels of resolver compliance (including the resolver portion of 1774 a server) are defined for DNS Security: 1776 BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs 1777 when they are explicitly requested. 1779 FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT 1780 RRs including verification of SIGs at least for the mandatory 1781 algorithm, (2) maintains appropriate information in its local caches 1782 and database to indicate which RRs have been authenticated and to 1783 what extent they have been authenticated, (3) performs additional 1784 queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when 1785 needed, (4) normally sets the CD query header bit on its queries. 1787 10. Security Considerations 1789 This document specifies extensions to the Domain Name System (DNS) 1790 protocol to provide data integrity and origin authentication, public 1791 key distribution, and optional transaction and request security. 1793 It should be noted that, at most, these extensions guarantee the 1794 validity of resource records, including KEY resource records, 1795 retrieved from the DNS. They do not magically solve other security 1796 problems. For example, using secure DNS you can have high confidence 1797 in the IP address you retrieve for a host name; however, this does 1798 not stop someone for substituting an unauthorized host at that 1799 address or capturing packets sent to that address and falsely 1800 responding with packets apparently from that address. Any reasonably 1801 complete security system will require the protection of many 1802 additional facets of the Internet beyond DNS. 1804 The implementation of NXT RRs as described herein enables a resolver 1805 to determine all the names in a zone even if zone transfers are 1806 prohibited (section 5.6). This is an active area of work and may 1807 change. 1809 A number of precautions in DNS implementation have evolved over the 1810 years to harden the insecure DNS against spoofing. These precautions 1811 should not generally be abandoned but should be considered to provide 1812 additional protection in case of key compromise in secure DNS. 1814 References 1816 [RFC 1032] - M. Stahl, "Domain Administrators Guide", November 1987. 1818 [RFC 1033] - M. Lottor, "Domain Administrators Operations Guide", 1819 November 1987. 1821 [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and 1822 Facilities", STD 13, November 1987. 1824 [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and 1825 Specifications", STD 13, November 1987. 1827 [RFC 1305] - D. Mills, "Network Time Protocol (v3)", March 1992. 1829 [RFC 1530] - C. Malamud, and M. Rose, "Principles of Operation for 1830 the TPC.INT Subdomain: General Principles and Policy", October 1993. 1832 [RFC 1750] - D. Eastlake, S. Crocker, and J. Schiller, "Randomness 1833 Requirements for Security", December 1994. 1835 [RFC 1825] - Ran Atkinson, "Security Architecture for the Internet 1836 Protocol", August 1995. 1838 [RFC 1982] - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", 1839 09/03/1996. 1841 [RFC 1995] - Masatka Ohta, "Incremental Zone Transfer in DNS", August 1842 1996. 1844 [RFC 2030] - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 1845 for IPv4, IPv6 and OSI", October 1996. 1847 [RFC 2045] - N. Freed & N. Borenstein, "Multipurpose Internet Mail 1848 Extensions (MIME) Part One: Format of Internet Message Bodies", 1849 November 1996. 1851 [RFC 2065] - Donald Eastlake, Charles Kaufman, "Domain Name System 1852 Security Extensions", 01/03/1997. 1854 [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 1855 Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. 1857 [RFC 2137] - Donald Eastlake, "Secure Domain Name System Dynamic 1858 Update", 04/21/1997. 1860 [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS 1861 Specification", July 1997. 1863 draft-ietf-dnssec-rsa-*.txt, D. Eastlake, "RSA/MD5 KEYs and SIGs in 1864 the Domain Name System (DNS)". 1866 draft-ietf-dnssec-dhk-*.txt, D. Eastlake, "Storage of Diffie-Hellman 1867 Keys in the Domain Name System (DNS)". 1869 draft-ietf-dnssec-dss-*.txt, D. Eastlake, "DSA KEYs and SIGs in the 1870 Domain Name System (DNS)". 1872 draft-ietf-dsnssec-certs-*.txt, D. Eastlake, O. Gudmundsson, "Storing 1873 Certificates in the Domain Name System". 1875 draft-ietf-dnssec-secops-*.txt, D. Eastlake, "DNS Operational 1876 Security Considerations". 1878 draft-ietf-tls-*.txt, 1880 [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. 1882 Author's Address 1884 Donald E. Eastlake 3rd 1885 CyberCash, Inc. 1886 318 Acton Street 1887 Carlisle, MA 01741 USA 1889 Telephone: +1 978-287-4877 1890 +1 703-620-4200 (main office, Reston, Virginia, USA) 1891 fax: +1 978-371-7148 1892 email: dee@cybercash.com 1894 Expiration and File Name 1896 This draft expires October 1998. 1898 Its file name is draft-ietf-dnssec-secext2-05.txt. 1900 Appendix A: Base 64 Encoding 1902 The following encoding technique is taken from [RFC 2045] by N. 1903 Borenstein and N. Freed. It is reproduced here in an edited form for 1904 convenience. 1906 A 65-character subset of US-ASCII is used, enabling 6 bits to be 1907 represented per printable character. (The extra 65th character, "=", 1908 is used to signify a special processing function.) 1910 The encoding process represents 24-bit groups of input bits as output 1911 strings of 4 encoded characters. Proceeding from left to right, a 1912 24-bit input group is formed by concatenating 3 8-bit input groups. 1913 These 24 bits are then treated as 4 concatenated 6-bit groups, each 1914 of which is translated into a single digit in the base 64 alphabet. 1916 Each 6-bit group is used as an index into an array of 64 printable 1917 characters. The character referenced by the index is placed in the 1918 output string. 1920 Table 1: The Base 64 Alphabet 1922 Value Encoding Value Encoding Value Encoding Value Encoding 1923 0 A 17 R 34 i 51 z 1924 1 B 18 S 35 j 52 0 1925 2 C 19 T 36 k 53 1 1926 3 D 20 U 37 l 54 2 1927 4 E 21 V 38 m 55 3 1928 5 F 22 W 39 n 56 4 1929 6 G 23 X 40 o 57 5 1930 7 H 24 Y 41 p 58 6 1931 8 I 25 Z 42 q 59 7 1932 9 J 26 a 43 r 60 8 1933 10 K 27 b 44 s 61 9 1934 11 L 28 c 45 t 62 + 1935 12 M 29 d 46 u 63 / 1936 13 N 30 e 47 v 1937 14 O 31 f 48 w (pad) = 1938 15 P 32 g 49 x 1939 16 Q 33 h 50 y 1941 Special processing is performed if fewer than 24 bits are available 1942 at the end of the data being encoded. A full encoding quantum is 1943 always completed at the end of a quantity. When fewer than 24 input 1944 bits are available in an input group, zero bits are added (on the 1945 right) to form an integral number of 6-bit groups. Padding at the 1946 end of the data is performed using the '=' character. Since all base 1947 64 input is an integral number of octets, only the following cases 1948 can arise: (1) the final quantum of encoding input is an integral 1949 multiple of 24 bits; here, the final unit of encoded output will be 1950 an integral multiple of 4 characters with no "=" padding, (2) the 1951 final quantum of encoding input is exactly 8 bits; here, the final 1952 unit of encoded output will be two characters followed by two "=" 1953 padding characters, or (3) the final quantum of encoding input is 1954 exactly 16 bits; here, the final unit of encoded output will be three 1955 characters followed by one "=" padding character. 1957 Appendix B: Changes from RFC 2065 1959 This section summarizes the most important changes that have been 1960 made since RFC 2065. 1962 1. Most of Section 7 of [RFC 2065] called "Operational 1963 Considerations", has been removed and may be made into a separate 1964 document [draft-ietf-dnssec-secops-*.txt]. 1966 2. The KEY RR has been changed by (2a) eliminating the "experimental" 1967 flag as unnecessary, (2b) reserving a flag bit for flags 1968 expansion, (2c) more compactly encoding a number of bit fields in 1969 such a way as to leave unchanged bits actually used by the limited 1970 code currently deployed, (2d) eliminating the IPSEC and email flag 1971 bits which are replaced by values of the protocol field and adding 1972 a protocol field value for DNS security itself, (2e) adding 1973 material to indicate that zone KEY RRs occur only at delegation 1974 points, and (2f) removing the description of the RSA/MD5 algorithm 1975 to a separate document [draft-ietf-dnssec-rsa-*.txt]. Section 3.4 1976 describing the meaning of various combinations of "no-key" and key 1977 present KEY RRs has been added and the secure / unsecure status of 1978 a zone has been clarified as being per algorithm. 1980 3. The SIG RR has been changed by (3a) renaming the "time signed" 1981 field to be the "signature inception" field, (3b) clarifying that 1982 signature expiration and inception use serial number ring 1983 arithmetic, (3c) changing the definition of the key footprint/tag 1984 for algorithms other than 1 and adding Appendix C to specify its 1985 calculation. In addition, the SIG covering type AXFR has been 1986 eliminated while one covering IXFR [RFC 1995] has been added (see 1987 section 5.6). 1989 4. Algorithm 3, the DSA algorithm, is now designated as the mandatory 1990 to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is 1991 now a recommended option. Algorithm 2 and 4 are designated as the 1992 Diffie-Hellman key and elliptic cryptography algorithms 1993 respectively, all to be defined in separate documents. Algorithm 1994 code point 252 is designated to indicate "indirect" keys, to be 1995 defined in a separate document, where the actual key is elsewhere. 1996 Both the KEY and SIG RR definitions have been simplified by 1997 eliminating the "null" algorithm 253 as defined in [RFC 2065]. 1998 That algorithm had been included because at the time it was 1999 thought it might be useful in DNS dynamic update [RFC 2136]. It 2000 was in fact not so used and it is dropped to simplify DNS 2001 security. 2003 5. The NXT RR has been changed so that (5a) the NXT RRs in a zone 2004 cover all names, including wildcards as literal names without 2005 expansion, except for glue address records whose names would not 2006 otherwise appear, (5b) all NXT bit map areas whose first octet has 2007 bit zero set have been reserved for future definition, (5c) the 2008 number of and circumstances under which an NXT must be returned in 2009 connection with wildcard names has been extended, and (5d) in 2010 connection with the bit map, references to the WKS RR have been 2011 removed and verticle bars ("|") have been added between the RR 2012 type mnemonics in the ASCII representation. 2014 6. Information on the canonical form and ordering of RRs has been 2015 moved into a separate Section 8. 2017 7. A subsection covering incremental and full zone transfer has been 2018 added in Section 5. 2020 8. Concerning DNS chaining: Further specification and policy 2021 recommendations on secure resolution have been added, primarily in 2022 Section 6.3.1. It is now clearly stated that authenticated data 2023 has a validity period of the intersection of the validity periods 2024 of the SIG RRs in its authentication chain. The requirement to 2025 staticly configure a superzone's key signed by a zone in all of 2026 the zone's authoritative servers has been removed. The 2027 recommendation was dropped to continue DNS security checks in a 2028 secure island of DNS data that is separated from other parts of 2029 the DNS tree by insecure zones and does not contain a zone for 2030 which a key has been staticly configured. 2032 9. It was clarified that the presence of the AD bit in a response 2033 does not apply to the additional information section or to glue 2034 address or delegation point NS RRs. 2036 10. It is now required that KEY RRs and NXT RRs be signed only with 2037 zone-level keys. 2039 Appendix C: Key Tag Calculation 2041 The key tag field in the SIG RR is just a means of more efficiently 2042 selecting the correct KEY RR to use when there is more than one KEY 2043 RR candidate. It is possible for more than one candidate key to have 2044 the same tag, in which case each must be tried in verifying a 2045 signature, for example, until one works or all fail. The following 2046 reference implementation is in ANSI C. It is coded for clarity, not 2047 efficiency. 2049 /* assumes int is at least 16 bits 2050 first byte of the key tag is the most significant byte of return value 2051 second byte of the key tag is the least significant byte of return value 2052 */ 2054 int keytag ( 2055 unsigned char key[], /* the RDATA part of the KEY RR */ 2056 unsigned int keysize, /* the RDLENGTH */ 2057 ) 2058 { 2059 long int ac; /* assumed to be 32 bits or larger */ 2061 for ( ac = 0, i = 0; i < keysize; ++i ) 2062 ac += (i&1) ? key[i] : key[i]<<8; 2063 ac += (ac>>16) & 0xFFFF; 2064 return ac & 0xFFFF; 2065 }