idnits 2.17.1 draft-ietf-dnssec-secext2-07.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-07.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secext2-07.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secext2-07.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-07.txt,', but the file name used is 'draft-ietf-dnssec-secext2-07' == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 182 has weird spacing: '...ts from poten...' == Line 838 has weird spacing: '... key tag ...' == Line 2009 has weird spacing: '... a flag bit f...' == Line 2110 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. == 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 (December 1998) is 9263 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: 'RFC2119' is mentioned on line 234, but not defined == Missing Reference: 'RFCs 2136' is mentioned on line 289, but not defined -- Looks like a reference, but probably isn't: '2137' on line 1006 -- Looks like a reference, but probably isn't: '2030' on line 1580 == Unused Reference: 'RFC 1034' is defined on line 1861, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 1864, but no explicit reference was found in the text == Unused Reference: 'RFC 2030' is defined on line 1881, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 1891, but no explicit reference was found in the text == Unused Reference: 'RSA FAQ' is defined on line 1921, but no explicit reference was found in the text ** 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 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA FAQ' Summary: 18 errors (**), 1 flaw (~~), 15 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 IBM 3 OBSOLETES RFC 2065 4 UPDATES RFCs 1034, 1035, and 2181 5 Expires: June 1999 December 1998 7 Domain Name System Security Extensions 8 ------ ---- ------ -------- ---------- 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-secext2-07.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 [[changed from draft 5 to draft 6: add IANA Considerations section, 36 update dates and file name, update author info, update references 37 where new documents have superceded those previously referenced, add 38 reference to RFC 2119, clarify wording, minor change at 4.1.5 to 39 explain why modular time does not induce a security flaw, clarify 40 that the zone key for a secure subzone need not be included at the 41 leaf node in the superzone, specify that algorithm 254 OIDs are BER 42 encoded, add algorithm 253 for domain name encoded private 43 algorithm]] [[changed from draft 6 to draft 7: tweak IANA 44 Considerations section and add reference to RFC 2434, update author 45 info]] 47 Abstract 49 Extensions to the Domain Name System (DNS) are described that provide 50 data integrity and authentication to security aware resolvers and 51 applications through the use of cryptographic digital signatures. 52 These digital signatures are included in secured zones as resource 53 records. Security can also be provided through non-security aware 54 DNS servers in some cases. 56 The extensions provide for the storage of authenticated public keys 57 in the DNS. This storage of keys can support general public key 58 distribution services as well as DNS security. The stored keys 59 enable security aware resolvers to learn the authenticating key of 60 zones in addition to those for which they are initially configured. 61 Keys associated with DNS names can be retrieved to support other 62 protocols. Provision is made for a variety of key types and 63 algorithms. 65 In addition, the security extensions provide for the optional 66 authentication of DNS protocol transactions and requests. 68 This document incorporates feedback on RFC 2065 from early 69 implementers and potential users. 71 Acknowledgments 73 The significant contributions and suggestions of the following 74 persons (in alphabetic order) to DNS security are gratefully 75 acknowledged: 77 James M. Galvin 78 John Gilmore 79 Olafur Gudmundsson 80 Charlie Kaufman 81 Edward Lewis 82 Thomas Narten 83 Radia J. Perlman 84 Jeffrey I. Schiller 85 Steven (Xunhua) Wang 86 Brian Wellington 88 Table of Contents 90 Status of This Document....................................1 92 Abstract...................................................2 93 Acknowledgments............................................2 95 Table of Contents..........................................3 97 1. Overview of Contents....................................5 98 2. Overview of the DNS Extensions..........................6 99 2.1 Services Not Provided..................................6 100 2.2 Key Distribution.......................................6 101 2.3 Data Origin Authentication and Integrity...............7 102 2.3.1 The SIG Resource Record..............................8 103 2.3.2 Authenticating Name and Type Non-existence...........8 104 2.3.3 Special Considerations With Time-to-Live.............8 105 2.3.4 Special Considerations at Delegation Points..........9 106 2.3.5 Special Considerations with CNAME....................9 107 2.3.6 Signers Other Than The Zone.........................10 108 2.4 DNS Transaction and Request Authentication............10 109 3. The KEY Resource Record................................11 110 3.1 KEY RDATA format......................................12 111 3.1.1 Object Types, DNS Names, and Keys...................12 112 3.1.2 The KEY RR Flag Field...............................13 113 3.1.3 The Protocol Octet..................................14 114 3.2 The KEY Algorithm Number Specification................15 115 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...16 116 3.4 Determination of Zone Secure/Unsecured Status.........16 117 3.5 KEY RRs in the Construction of Responses..............18 118 4. The SIG Resource Record................................18 119 4.1 SIG RDATA Format......................................19 120 4.1.1 Type Covered Field..................................19 121 4.1.2 Algorithm Number Field..............................19 122 4.1.3 Labels Field........................................19 123 4.1.4 Original TTL Field..................................20 124 4.1.5 Signature Expiration and Inception Fields...........20 125 4.1.6 Key Tag Field.......................................21 126 4.1.7 Signer's Name Field.................................21 127 4.1.8 Signature Field.....................................22 128 4.1.8.1 Calculating Transaction and Request SIGs..........22 129 4.2 SIG RRs in the Construction of Responses..............23 130 4.3 Processing Responses and SIG RRs......................24 131 4.4 Signature Lifetime, Expiration, TTLs, and Validity....25 132 5. Non-existent Names and Types...........................25 133 5.1 The NXT Resource Record...............................26 134 5.2 NXT RDATA Format......................................27 135 5.3 Additional Complexity Due to Wildcards................27 136 5.4 Example...............................................28 137 5.5 Special Considerations at Delegation Points...........28 138 5.6 Zone Transfers........................................29 139 5.6.1 Full Zone Transfers.................................29 140 5.6.2 Incremental Zone Transfers..........................30 141 6. How to Resolve Securely and the AD and CD Bits.........30 142 6.1 The AD and CD Header Bits.............................31 143 6.2 Staticly Configured Keys..............................32 144 6.3 Chaining Through The DNS..............................33 145 6.3.1 Chaining Through KEYs...............................33 146 6.3.2 Conflicting Data....................................34 147 6.4 Secure Time...........................................35 148 7. ASCII Representation of Security RRs...................35 149 7.1 Presentation of KEY RRs...............................36 150 7.2 Presentation of SIG RRs...............................37 151 7.3 Presentation of NXT RRs...............................38 152 8. Canonical Form and Order of Resource Records...........38 153 8.1 Canonical RR Form.....................................38 154 8.2 Canonical DNS Name Order..............................38 155 8.3 Canonical RR Ordering Within An RRset.................39 156 8.4 Canonical Ordering of RR Types........................39 157 9. Conformance............................................39 158 9.1 Server Conformance....................................39 159 9.2 Resolver Conformance..................................40 160 10. Security Considerations...............................40 161 11. IANA Considerations...................................41 163 References................................................42 165 Author's Address..........................................44 166 Expiration and File Name..................................44 168 Appendix A: Base 64 Encoding..............................45 170 Appendix B: Changes from RFC 2065.........................47 172 Appendix C: Key Tag Calculation...........................49 174 1. Overview of Contents 176 This document standardizes extensions of the Domain Name System (DNS) 177 protocol to support DNS security and public key distribution. It 178 assumes that the reader is familiar with the Domain Name System, 179 particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An 180 earlier version of these extensions appears in RFC 2065. This 181 replacement for that RFC incorporates early implementation experience 182 and requests from potential users. 184 Section 2 provides an overview of the extensions and the key 185 distribution, data origin authentication, and transaction and request 186 security they provide. 188 Section 3 discusses the KEY resource record, its structure, and use 189 in DNS responses. These resource records represent the public keys 190 of entities named in the DNS and are used for key distribution. 192 Section 4 discusses the SIG digital signature resource record, its 193 structure, and use in DNS responses. These resource records are used 194 to authenticate other resource records in the DNS and optionally to 195 authenticate DNS transactions and requests. 197 Section 5 discusses the NXT resource record (RR) and its use in DNS 198 responses including full and incremental zone transfers. The NXT RR 199 permits authenticated denial of the existence of a name or of an RR 200 type for an existing name. 202 Section 6 discusses how a resolver can be configured with a starting 203 key or keys and proceed to securely resolve DNS requests. 204 Interactions between resolvers and servers are discussed for various 205 combinations of security aware and security non-aware. Two 206 additional DNS header bits are defined for signaling between 207 resolvers and servers. 209 Section 7 describes the ASCII representation of the security resource 210 records for use in master files and elsewhere. 212 Section 8 defines the canonical form and order of RRs for DNS 213 security purposes. 215 Section 9 defines levels of conformance for resolvers and servers. 217 Section 10 provides a few paragraphs on overall security 218 considerations. 220 Sectuion 11 specified IANA considerations for allocation of 221 additional values of paramters defined in this document. 223 Appendix A gives details of base 64 encoding which is used in the 224 file representation of some RRs defined in this document. 226 Appendix B summarizes changes between this draft and RFC 2065. 228 Appendix C specified how to calculate the simple checksum used as a 229 key tag in most SIG RRs. 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in [RFC2119]. 235 2. Overview of the DNS Extensions 237 The Domain Name System (DNS) protocol security extensions provide 238 three distinct services: key distribution as described in Section 2.2 239 below, data origin authentication as described in Section 2.3 below, 240 and transaction and request authentication, described in Section 2.4 241 below. 243 Special considerations related to "time to live", CNAMEs, and 244 delegation points are also discussed in Section 2.3. 246 2.1 Services Not Provided 248 It is part of the design philosophy of the DNS that the data in it is 249 public and that the DNS gives the same answers to all inquirers. 250 Following this philosophy, no attempt has been made to include any 251 sort of access control lists or other means to differentiate 252 inquirers. 254 No effort has been made to provide for any confidentiality for 255 queries or responses. (This service may be available via IPSEC [RFC 256 1825], TLS, or other security protocols.) 258 Protection is not provided against denial of service. 260 2.2 Key Distribution 262 A resource record format is defined to associate keys with DNS names. 263 This permits the DNS to be used as a public key distribution 264 mechanism in support of DNS security itself and other protocols. 266 The syntax of a KEY resource record (RR) is described in Section 3. 267 It includes an algorithm identifier, the actual public key 268 parameter(s), and a variety of flags including those indicating the 269 type of entity the key is associated with and/or asserting that there 270 is no key associated with that entity. 272 Under conditions described in Section 3.5, security aware DNS servers 273 will automatically attempt to return KEY resources as additional 274 information, along with those resource records actually requested, to 275 minimize the number of queries needed. 277 2.3 Data Origin Authentication and Integrity 279 Authentication is provided by associating with resource record sets 280 (RRsets [RFC 2181]) in the DNS cryptographically generated digital 281 signatures. Commonly, there will be a single private key that 282 authenticates an entire zone but there might be multiple keys for 283 different algorithms, signers, etc. If a security aware resolver 284 reliably learns a public key of the zone, it can authenticate, for 285 signed data read from that zone, that it is properly authorized. The 286 most secure implementation is for the zone private key(s) to be kept 287 off-line and used to re-sign all of the records in the zone 288 periodically. However, there are cases, for example dynamic update 289 [RFCs 2136, 2137], where DNS private keys need to be on-line. 290 [draft-ietf-dnssec-secops-*.txt] 292 The data origin authentication key(s) are associated with the zone 293 and not with the servers that store copies of the data. That means 294 compromise of a secondary server or, if the key(s) are kept off line, 295 even the primary server for a zone, will not necessarily affect the 296 degree of assurance that a resolver has that it can determine whether 297 data is genuine. 299 A resolver could learn a public key of a zone either by reading it 300 from the DNS or by having it staticly configured. To reliably learn 301 a public key by reading it from the DNS, the key itself must be 302 signed with a key the resolver trusts. The resolver must be 303 configured with at least a public key which authenticates one zone as 304 a starting point. From there, it can securely read public keys of 305 other zones, if the intervening zones in the DNS tree are secure and 306 their signed keys accessible. 308 Adding data origin authentication and integrity requires no change to 309 the "on-the-wire" DNS protocol beyond the addition of the signature 310 resource type and the key resource type needed for key distribution. 311 (Data non-existence authentication also requires the NXT RR as 312 described in 2.3.2.) This service can be supported by existing 313 resolver and caching server implementations so long as they can 314 support the additional resource types (see Section 9). The one 315 exception is that CNAME referrals in a secure zone can not be 316 authenticated if they are from non-security aware servers (see 317 Section 2.3.5). 319 If signatures are separately retrieved and verified when retrieving 320 the information they authenticate, there will be more trips to the 321 server and performance will suffer. Security aware servers mitigate 322 that degradation by attempting to send the signature(s) needed (see 323 Section 4.2). 325 2.3.1 The SIG Resource Record 327 The syntax of a SIG resource record (signature) is described in 328 Section 4. It cryptographicly binds the RRset being signed to the 329 signer and a validity interval. 331 Every name in a secured zone will have associated with it at least 332 one SIG resource record for each resource type under that name except 333 for glue address RRs and delegation point NS RRs. A security aware 334 server will attempt to return, with RRs retrieved, the corresponding 335 SIGs. If a server is not security aware, the resolver must retrieve 336 all the SIG records for a name and select the one or ones that sign 337 the resource record set(s) that resolver is interested in. 339 2.3.2 Authenticating Name and Type Non-existence 341 The above security mechanism only provides a way to sign existing 342 RRsets in a zone. "Data origin" authentication is not obviously 343 provided for the non-existence of a domain name in a zone or the 344 non-existence of a type for an existing name. This gap is filled by 345 the NXT RR which authenticatably asserts a range of non-existent 346 names in a zone and the non-existence of types for the existing name 347 just before that range. 349 Section 5 below covers the NXT RR. 351 2.3.3 Special Considerations With Time-to-Live 353 A digital signature will fail to verify if any change has occurred to 354 the data between the time it was originally signed and the time the 355 signature is verified. This conflicts with our desire to have the 356 time-to-live (TTL) field of resource records tick down while they are 357 cached. 359 This could be avoided by leaving the time-to-live out of the digital 360 signature, but that would allow unscrupulous servers to set 361 arbitrarily long TTL values undetected. Instead, we include the 362 "original" TTL in the signature and communicate that data along with 363 the current TTL. Unscrupulous servers under this scheme can 364 manipulate the TTL but a security aware resolver will bound the TTL 365 value it uses at the original signed value. Separately, signatures 366 include a signature inception time and a signature expiration time. A 367 resolver that knows the absolute time can determine securely whether 368 a signature is in effect. It is not possible to rely solely on the 369 signature expiration as a substitute for the TTL, however, since the 370 TTL is primarily a database consistency mechanism and non-security 371 aware servers that depend on TTL must still be supported. 373 2.3.4 Special Considerations at Delegation Points 375 DNS security would like to view each zone as a unit of data 376 completely under the control of the zone owner with each entry 377 (RRset) signed by a special private key held by the zone manager. 378 But the DNS protocol views the leaf nodes in a zone, which are also 379 the apex nodes of a subzone (i.e., delegation points), as "really" 380 belonging to the subzone. These nodes occur in two master files and 381 might have RRs signed by both the upper and lower zone's keys. A 382 retrieval could get a mixture of these RRs and SIGs, especially since 383 one server could be serving both the zone above and below a 384 delegation point. [RFC 2181] 386 There MUST be a zone KEY RR, signed by its superzone, for every 387 subzone if the superzone is secure. This will normally appear in the 388 subzone and may also be included in the superzone. But, in the case 389 of an unsecured subzone which can not or will not be modified to add 390 any security RRs, a KEY declaring the subzone to be unsecured MUST 391 appear with the superzone signature in the superzone, if the 392 superzone is secure. For all but one other RR type the data from the 393 subzone is more authoritative so only the subzone KEY RR should be 394 signed in the superzone if it appears there. The NS and any glue 395 address RRs SHOULD only be signed in the subzone. The SOA and any 396 other RRs that have the zone name as owner should appear only in the 397 subzone and thus are signed only there. The NXT RR type is the 398 exceptional case that will always appear differently and 399 authoritatively in both the superzone and subzone, if both are 400 secure, as described in Section 5. 402 2.3.5 Special Considerations with CNAME 404 There is a problem when security related RRs with the same owner name 405 as a CNAME RR are retrieved from a non-security-aware server. In 406 particular, an initial retrieval for the CNAME or any other type may 407 not retrieve any associated SIG, KEY, or NXT RR. For retrieved types 408 other than CNAME, it will retrieve that type at the target name of 409 the CNAME (or chain of CNAMEs) and will also return the CNAME. In 410 particular, a specific retrieval for type SIG will not get the SIG, 411 if any, at the original CNAME domain name but rather a SIG at the 412 target name. 414 Security aware servers must be used to securely CNAME in DNS. 415 Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along 416 with CNAME RRs, (2) suppress CNAME processing on retrieval of these 417 types as well as on retrieval of the type CNAME, and (3) 418 automatically return SIG RRs authenticating the CNAME or CNAMEs 419 encountered in resolving a query. This is a change from the previous 420 DNS standard [RFCs 1034/1035] which prohibited any other RR type at a 421 node where a CNAME RR was present. 423 2.3.6 Signers Other Than The Zone 425 There are cases where the signer in a SIG resource record is other 426 than one of the private key(s) used to authenticate a zone. 428 One is for support of dynamic update [RFC 2136] (or future requests 429 which require secure authentication) where an entity is permitted to 430 authenticate/update its records [RFC 2137] and the zone is operating 431 in a mode where the zone key is not on line. The public key of the 432 entity must be present in the DNS and be signed by a zone level key 433 but the other RR(s) may be signed with the entity's key. 435 A second case is support of transaction and request authentication as 436 described in Section 2.4. 438 In additions, signatures can be included on resource records within 439 the DNS for use by applications other than DNS. DNS related 440 signatures authenticate that data originated with the authority of a 441 zone owner or that a request or transaction originated with the 442 relevant entity. Other signatures can provide other types of 443 assurances. 445 2.4 DNS Transaction and Request Authentication 447 The data origin authentication service described above protects 448 retrieved resource records and the non-existence of resource records 449 but provides no protection for DNS requests or for message headers. 451 If header bits are falsely set by a bad server, there is little that 452 can be done. However, it is possible to add transaction 453 authentication. Such authentication means that a resolver can be 454 sure it is at least getting messages from the server it thinks it 455 queried and that the response is from the query it sent (i.e., that 456 these messages have not been diddled in transit). This is 457 accomplished by optionally adding a special SIG resource record at 458 the end of the reply which digitally signs the concatenation of the 459 server's response and the resolver's query. 461 Requests can also be authenticated by including a special SIG RR at 462 the end of the request. Authenticating requests serves no function 463 in older DNS servers and requests with a non-empty additional 464 information section produce error returns or may even be ignored by 465 many of them. However, this syntax for signing requests is defined as 466 a way of authenticating secure dynamic update requests [RFC 2137] or 467 future requests requiring authentication. 469 The private keys used in transaction security belong to the entity 470 composing the reply, not to the zone involved. Request 471 authentication may also involve the private key of the host or other 472 entity composing the request or other private keys depending on the 473 request authority it is sought to establish. The corresponding public 474 key(s) are normally stored in and retrieved from the DNS for 475 verification. 477 Because requests and replies are highly variable, message 478 authentication SIGs can not be pre-calculated. Thus it will be 479 necessary to keep the private key on-line, for example in software or 480 in a directly connected piece of hardware. 482 3. The KEY Resource Record 484 The KEY resource record (RR) is used to store a public key that is 485 associated with a Domain Name System (DNS) name. This can be the 486 public key of a zone, a user, or a host or other end entity. Security 487 aware DNS implementations MUST be designed to handle at least two 488 simultaneously valid keys of the same type associated with the same 489 name. 491 The type number for the KEY RR is 25. 493 A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs 494 must be signed by a zone level key. 496 3.1 KEY RDATA format 498 The RDATA for a KEY RR consists of flags, a protocol octet, the 499 algorithm number octet, and the public key itself. The format is as 500 follows: 502 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | flags | protocol | algorithm | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | / 508 / public key / 509 / / 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 512 The KEY RR is not intended for storage of certificates and a separate 513 certificate RR has been developed for that purpose, defined in 514 [draft-ietf-dnssec-certs-*.txt]. 516 The meaning of the KEY RR owner name, flags, and protocol octet are 517 described in Sections 3.1.1 through 3.1.5 below. The flags and 518 algorithm must be examined before any data following the algorithm 519 octet as they control the existence and format of any following data. 520 The algorithm and public key fields are described in Section 3.2. 521 The format of the public key is algorithm dependent. 523 KEY RRs do not specify their validity period but their authenticating 524 SIG RR(s) do as described in Section 4 below. 526 3.1.1 Object Types, DNS Names, and Keys 528 The public key in a KEY RR is for the object named in the owner name. 530 A DNS name may refer to three different categories of things. For 531 example, foo.host.example could be (1) a zone, (2) a host or other 532 end entity , or (3) the mapping into a DNS name of the user or 533 account foo@host.example. Thus, there are flag bits, as described 534 below, in the KEY RR to indicate with which of these roles the owner 535 name and public key are associated. Note that an appropriate zone 536 KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs 537 occur only at delegation points. 539 3.1.2 The KEY RR Flag Field 541 In the "flags" field: 543 1 1 1 1 1 1 544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 545 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 546 | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG | 547 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 549 Bit 0 and 1 are the key "type" bits whose values have the following 550 meanings: 551 10: Use of the key is prohibited for authentication. 552 01: Use of the key is prohibited for confidentiality. 553 00: Use of the key for authentication and/or confidentiality 554 is permitted. Note that DNS security makes use of keys for 555 authentication only. Confidentiality use flagging is provided for 556 use of keys in other protocols. Implementations not intended to 557 support key distribution for confidentiality MAY require that the 558 confidentiality use prohibited bit be on for keys they serve. 559 11: If both bits are one, the "no key" value, there is no key 560 information and the RR stops after the algorithm octet. By the 561 use of this "no key" value, a signed KEY RR can authenticatably 562 assert that, for example, a zone is not secured. See section 3.4 563 below. 565 Bits 2 is reserved and must be zero. 567 Bits 3 is reserved as a flag extension bit. If it is a one, a second 568 16 bit flag field is added after the algorithm octet and before 569 the key data. This bit MUST NOT be set unless one or more such 570 additional bits have been defined and are non-zero. 572 Bits 4-5 are reserved and must be zero. 574 Bits 6 and 7 form a field that encodes the name type. Field values 575 have the following meanings: 576 00: indicates that this is a key associated with a "user" or 577 "account" at an end entity, usually a host. The coding of the 578 owner name is that used for the responsible individual mailbox in 579 the SOA and RP RRs: The owner name is the user name as the name of 580 a node under the entity name. For example, "j_random_user" on 581 host.subdomain.example could have a public key associated through 582 a KEY RR with name j_random_user.host.subdomain.example. It could 583 be used in a security protocol where authentication of a user was 584 desired. This key might be useful in IP or other security for a 585 user level service such a telnet, ftp, rlogin, etc. 586 01: indicates that this is a zone key for the zone whose name 587 is the KEY RR owner name. This is the public key used for the 588 primary DNS security feature of data origin authentication. Zone 589 KEY RRs occur only at delegation points. 590 10: indicates that this is a key associated with the non-zone 591 "entity" whose name is the RR owner name. This will commonly be a 592 host but could, in some parts of the DNS tree, be some other type 593 of entity such as a telephone number [RFC 1530] or numeric IP 594 address. This is the public key used in connection with DNS 595 request and transaction authentication services. It could also be 596 used in an IP-security protocol where authentication at the host, 597 rather than user, level was desired, such as routing, NTP, etc. 598 11: reserved. 600 Bits 8-11 are reserved and must be zero. 602 Bits 12-15 are the "signatory" field. If non-zero, they indicate 603 that the key can validly sign things as specified in DNS dynamic 604 update [RFC 2137]. Note that zone keys (see bits 6 and 7 above) 605 always have authority to sign any RRs in the zone regardless of 606 the value of the signatory field. 608 3.1.3 The Protocol Octet 610 It is anticipated that keys stored in DNS will be used in conjunction 611 with a variety of Internet protocols. It is intended that the 612 protocol octet and possibly some of the currently unused (must be 613 zero) bits in the KEY RR flags as specified in the future will be 614 used to indicate a key's validity for different protocols. 616 The following values of the Protocol Octet are reserved as indicated: 618 VALUE Protocol 620 0 -reserved 621 1 TLS 622 2 email 623 3 dnssec 624 4 IPSEC 625 5-254 - available for assignment by IANA 626 255 All 628 In more detail: 629 1 is reserved for use in connection with TLS. 630 2 is reserved for use in connection with email. 631 3 is used for DNS security. The protocol field SHOULD be set to 632 this value for zone keys and other keys used in DNS security. 633 Implementations that can determine that a key is a DNS security key 634 by the fact that flags label it a zone key or the signatory flag 635 field is non-zero are NOT REQUIRED to check the protocol field. 636 4 is reserved to refer to the Oakley/IPSEC [RFC 1825] protocol 638 and indicates that this key is valid for use in conjunction with that 639 security standard. This key could be used in connection with secured 640 communication on behalf of an end entity or user whose name is the 641 owner name of the KEY RR if the entity or user flag bits are set. 642 The presence of a KEY resource with this protocol value is an 643 assertion that the host speaks Oakley/IPSEC. 644 255 indicates that the key can be used in connection with any 645 protocol for which KEY RR protocol octet values have been defined. 646 The use of this value is discouraged and the use of different keys 647 for different protocols is encouraged. 649 3.2 The KEY Algorithm Number Specification 651 This octet is the key algorithm parallel to the same field for the 652 SIG resource as described in Section 4.1. The following values are 653 assigned: 655 VALUE Algorithm 657 0 - reserved, see Section 11 658 1 RSA/MD5 [draft-ietf-dnssec-rsa-*.txt] - recommended 659 2 Diffie-Hellman [draft-ietf-dnssec-dhk-*.txt] - optional, key only 660 3 DSA [draft-ietf-dnssec-dss-*.txt] - MANDATORY 661 4 reserved for elliptic curve crypto 662 5-251 - available, see Section 11 663 252 reserved for indirect keys 664 253 private - domain name (see below) 665 254 private - OID (see below) 666 255 - reserved, see Section 11 668 Algorithm specific formats and procedures are given in separate 669 documents. The mandatory to implement for interoperability algorithm 670 is number 3, DSA. It is recommended that the RSA/MD5 algorithm, 671 number 1, also be implemented. Algorithm 2 is used to indicate 672 Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve. 674 Algorithm number 252 indicates an indirect key format where the 675 actual key material is elsewhere. This format is to be defined in a 676 separate document. 678 Algorithm numbers 253 and 254 are reserved for private use and will 679 never be assigned a specific algorithm. For number 253, the public 680 key area and the signature begin with a wire encoded domain name. 681 Only local domain name compression is permitted. The domain name 682 indicates the private algorithm to use and the remainder of the 683 public key area is whatever is required by that algorithm. For 684 number 254, the public key area for the KEY RR and the signature 685 begin with an unsigned length byte followed by a BER encoded Object 686 Identifier (ISO OID) of that length. The OID indicates the private 687 algorithm in use and the remainder of the area is whatever is 688 required by that algorithm. Entities should only use domain names 689 and OIDs they control to designate their private algorithms. 691 Values 0 and 255 are reserved but the value 0 is used in the 692 algorithm field when that field is not used. An example is in a KEY 693 RR with the top two flag bits on, the "no-key" value, where no key is 694 present. 696 3.3 Interaction of Flags, Algorithm, and Protocol Bytes 698 Various combinations of the no-key type flags, algorithm byte, 699 protocol byte, and any future assigned protocol indicating flags are 700 possible. The meaning of these combinations is indicated below: 702 NK = no key type (flags bits 0 and 1 on) 703 AL = algorithm byte 704 PR = protocols indicated by protocol byte or future assigned flags 706 x represents any valid non-zero value(s). 708 AL PR NK Meaning 709 0 0 0 Illegal, claims key but has bad algorithm field. 710 0 0 1 Specifies total lack of security for owner zone. 711 0 x 0 Illegal, claims key but has bad algorithm field. 712 0 x 1 Specified protocols unsecured, others may be secure. 713 x 0 0 Gives key but no protocols to use it. 714 x 0 1 Denies key for specific algorithm. 715 x x 0 Specifies key for protocols. 716 x x 1 Algorithm not understood for protocol. 718 3.4 Determination of Zone Secure/Unsecured Status 720 A zone KEY RR with the "no-key" type field value (both key type flag 721 bits 0 and 1 on) indicates that the zone named is unsecured while a 722 zone KEY RR with a key present indicates that the zone named is 723 secure. The secured versus unsecured status of a zone may vary with 724 different cryptographic algorithms. Even for the same algorithm, 725 conflicting zone KEY RRs may be present. 727 Zone KEY RRs, like all RRs, are only trusted if they are 728 authenticated by a SIG RR whose signer field is a signer for which 729 the resolver has a public key they trust and where resolver policy 730 permits that signer to sign for the KEY owner name. Untrusted zone 731 KEY RRs MUST be ignored in determining the security status of the 732 zone. However, there can be multiple sets of trusted zone KEY RRs 733 for a zone with different algorithms, signers, etc. 735 For any particular algorithm, zones can be (1) secure, indicating 736 that any retrieved RR must be authenticated by a SIG RR or it will be 737 discarded as bogus, (2) unsecured, indicating that SIG RRs are not 738 expected or required for RRs retrieved from the zone, or (3) 739 experimentally secure, which indicates that SIG RRs might or might 740 not be present but must be checked if found. The status of a zone is 741 determined as follows: 743 1. If, for a zone and algorithm, every trusted zone KEY RR for the 744 zone says there is no key for that zone, it is unsecured for that 745 algorithm. 747 2. If, there is at least one trusted no-key zone KEY RR and one 748 trusted key specifying zone KEY RR, then that zone is only 749 experimentally secure for the algorithm. Both authenticated and 750 non-authenticated RRs for it should be accepted by the resolver. 752 3. If every trusted zone KEY RR that the zone and algorithm has is 753 key specifying, then it is secure for that algorithm and only 754 authenticated RRs from it will be accepted. 756 Examples: 758 (1) A resolver initially trusts only signatures by the superzone of 759 zone Z within the DNS hierarchy. Thus it will look only at the KEY 760 RRs that are signed by the superzone. If it finds only no-key KEY 761 RRs, it will assume the zone is not secure. If it finds only key 762 specifying KEY RRs, it will assume the zone is secure and reject any 763 unsigned responses. If it finds both, it will assume the zone is 764 experimentally secure 766 (2) A resolver trusts the superzone of zone Z (to which it got 767 securely from its local zone) and a third party, cert-auth.example. 768 When considering data from zone Z, it may be signed by the superzone 769 of Z, by cert-auth.example, by both, or by neither. The following 770 table indicates whether zone Z will be considered secure, 771 experimentally secure, or unsecured, depending on the signed zone KEY 772 RRs for Z; 773 c e r t - a u t h . e x a m p l e 775 KEY RRs| None | NoKeys | Mixed | Keys | 776 S --+-----------+-----------+----------+----------+ 777 u None | illegal | unsecured | experim. | secure | 778 p --+-----------+-----------+----------+----------+ 779 e NoKeys | unsecured | unsecured | experim. | secure | 780 r --+-----------+-----------+----------+----------+ 781 Z Mixed | experim. | experim. | experim. | secure | 782 o --+-----------+-----------+----------+----------+ 783 n Keys | secure | secure | secure | secure | 784 e +-----------+-----------+----------+----------+ 786 3.5 KEY RRs in the Construction of Responses 788 An explicit request for KEY RRs does not cause any special additional 789 information processing except, of course, for the corresponding SIG 790 RR from a security aware server (see Section 4.2). 792 Security aware DNS servers include KEY RRs as additional information 793 in responses, where a KEY is available, in the following cases: 795 (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same 796 name (perhaps just a zone key) SHOULD be included as additional 797 information if space is available. If not all additional information 798 will fit, type A and AAAA glue RRs have higher priority than KEY 799 RR(s). 801 (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same 802 name (usually just a host RR and NOT the zone key (which usually 803 would have a different name)) SHOULD be included if space is 804 available. On inclusion of A or AAAA RRs as additional information, 805 the KEY RRset with the same name should also be included but with 806 lower priority than the A or AAAA RRs. 808 4. The SIG Resource Record 810 The SIG or "signature" resource record (RR) is the fundamental way 811 that data is authenticated in the secure Domain Name System (DNS). As 812 such it is the heart of the security provided. 814 The SIG RR unforgably authenticates an RRset [RFC 2181] of a 815 particular type, class, and name and binds it to a time interval and 816 the signer's domain name. This is done using cryptographic 817 techniques and the signer's private key. The signer is frequently 818 the owner of the zone from which the RR originated. 820 The type number for the SIG RR type is 24. 822 4.1 SIG RDATA Format 824 The RDATA portion of a SIG RR is as shown below. The integrity of 825 the RDATA information is protected by the signature field. 827 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | type covered | algorithm | labels | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | original TTL | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | signature expiration | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | signature inception | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | key tag | | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + 840 | / 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 842 / / 843 / signature / 844 / / 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 4.1.1 Type Covered Field 849 The "type covered" is the type of the other RRs covered by this SIG. 851 4.1.2 Algorithm Number Field 853 This octet is as described in section 3.2. 855 4.1.3 Labels Field 857 The "labels" octet is an unsigned count of how many labels there are 858 in the original SIG RR owner name not counting the null label for 859 root and not counting any initial "*" for a wildcard. If a secured 860 retrieval is the result of wild card substitution, it is necessary 861 for the resolver to use the original form of the name in verifying 862 the digital signature. This field makes it easy to determine the 863 original form. 865 If, on retrieval, the RR appears to have a longer name than indicated 866 by "labels", the resolver can tell it is the result of wildcard 867 substitution. If the RR owner name appears to be shorter than the 868 labels count, the SIG RR must be considered corrupt and ignored. The 869 maximum number of labels allowed in the current DNS is 127 but the 870 entire octet is reserved and would be required should DNS names ever 871 be expanded to 255 labels. The following table gives some examples. 872 The value of "labels" is at the top, the retrieved owner name on the 873 left, and the table entry is the name to use in signature 874 verification except that "bad" means the RR is corrupt. 876 labels= | 0 | 1 | 2 | 3 | 4 | 877 --------+-----+------+--------+----------+----------+ 878 .| . | bad | bad | bad | bad | 879 d.| *. | d. | bad | bad | bad | 880 c.d.| *. | *.d. | c.d. | bad | bad | 881 b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | 882 a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | 884 4.1.4 Original TTL Field 886 The "original TTL" field is included in the RDATA portion to avoid 887 (1) authentication problems that caching servers would otherwise 888 cause by decrementing the real TTL field and (2) security problems 889 that unscrupulous servers could otherwise cause by manipulating the 890 real TTL field. This original TTL is protected by the signature 891 while the current TTL field is not. 893 NOTE: The "original TTL" must be restored into the covered RRs when 894 the signature is verified (see Section 8). This generaly implies 895 that all RRs for a particular type, name, and class, that is, all the 896 RRs in any particular RRset, must have the same TTL to start with. 898 4.1.5 Signature Expiration and Inception Fields 900 The SIG is valid from the "signature inception" time until the 901 "signature expiration" time. Both are unsigned numbers of seconds 902 since the start of 1 January 1970, GMT, ignoring leap seconds. (See 903 also Section 4.4.) Ring arithmetic is used as for DNS SOA serial 904 numbers [RFC 1982] which means that these times can never be more 905 than about 68 years in the past or the future. This means that these 906 times are ambiguous modulo ~136.09 years. However there is no 907 security flaw because keys are required to be changed to new random 908 keys by [draft-ietf-dnssec-secops-*.txt] at least every five years. 909 This means that the probability that the same key is in use N*136.09 910 years later should be the same as the probability that a random guess 911 will work. 913 A SIG RR may have an expiration time numerically less than the 914 inception time if the expiration time is near the 32 bit wrap around 915 point and/or the signature is long lived. 917 (To prevent misordering of network requests to update a zone 918 dynamically, monotonically increasing "signature inception" times may 919 be necessary.) 921 A secure zone must be considered changed for SOA serial number 922 purposes not only when its data is updated but also when new SIG RRs 923 are inserted (ie, the zone or any part of it is re-signed). 925 4.1.6 Key Tag Field 927 The "key Tag" is a two octet quantity that is used to efficiently 928 select between multiple keys which may be applicable and thus check 929 that a public key about to be used for the computationally expensive 930 effort to check the signature is possibly valid. For algorithm 1 931 (MD5/RSA) as defined in [draft-ietf-dnssec-rsa-*.txt], it is the next 932 to the bottom two octets of the public key modulus needed to decode 933 the signature field. That is to say, the most significant 16 of the 934 least significant 24 bits of the modulus in network (big endian) 935 order. For all other algorithms, including private algorithms, it is 936 calculated as a simple checksum of the KEY RR as described in 937 Appendix C. 939 4.1.7 Signer's Name Field 941 The "signer's name" field is the domain name of the signer generating 942 the SIG RR. This is the owner name of the public KEY RR that can be 943 used to verify the signature. It is frequently the zone which 944 contained the RRset being authenticated. Which signers should be 945 authorized to sign what is a significant resolver policy question as 946 discussed in Section 6. The signer's name may be compressed with 947 standard DNS name compression when being transmitted over the 948 network. 950 4.1.8 Signature Field 952 The actual signature portion of the SIG RR binds the other RDATA 953 fields to the RRset of the "type covered" RRs with that owner name 954 and class. This covered RRset is thereby authenticated. To 955 accomplish this, a data sequence is constructed as follows: 957 data = RDATA | RR(s)... 959 where "|" is concatenation, 961 RDATA is the wire format of all the RDATA fields in the SIG RR itself 962 (including the canonical form of the signer's name) before but not 963 including the signature, and 965 RR(s) is the RRset of the RR(s) of the type covered with the same 966 owner name and class as the SIG RR in canonical form and order as 967 defined in Section 8. 969 How this data sequence is processed into the signature is algorithm 970 dependent. These algorithm dependent formats and procedures are 971 described in separate documents (Section 3.2). 973 SIGs SHOULD NOT be included in a zone for any "meta-type" such as 974 ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR). 976 4.1.8.1 Calculating Transaction and Request SIGs 978 A response message from a security aware server may optionally 979 contain a special SIG at the end of the additional information 980 section to authenticate the transaction. 982 This SIG has a "type covered" field of zero, which is not a valid RR 983 type. It is calculated by using a "data" (see Section 4.1.8) of the 984 entire preceding DNS reply message, including DNS header but not the 985 IP header and before the reply RR counts have been adjusted for the 986 inclusion of any transaction SIG, concatenated with the entire DNS 987 query message that produced this response, including the query's DNS 988 header and any request SIGs but not its IP header. That is 990 data = full response (less transaction SIG) | full query 992 Verification of the transaction SIG (which is signed by the server 993 host key, not the zone key) by the requesting resolver shows that the 994 query and response were not tampered with in transit, that the 995 response corresponds to the intended query, and that the response 996 comes from the queried server. 998 A DNS request may be optionally signed by including one or more SIGs 999 at the end of the query. Such SIGs are identified by having a "type 1000 covered" field of zero. They sign the preceding DNS request message 1001 including DNS header but not including the IP header or any request 1002 SIGs at the end and before the request RR counts have been adjusted 1003 for the inclusions of any request SIG(s). 1005 WARNING: Request SIGs are unnecessary for any currently defined 1006 request other than update [RFC 2136, 2137] and will cause some old 1007 DNS servers to give an error return or ignore a query. However, such 1008 SIGs may in the future be needed for other requests. 1010 Except where needed to authenticate an update or similar privileged 1011 request, servers are not required to check request SIGs. 1013 4.2 SIG RRs in the Construction of Responses 1015 Security aware DNS servers SHOULD, for every authenticated RRset the 1016 query will return, attempt to send the available SIG RRs which 1017 authenticate the requested RRset. The following rules apply to the 1018 inclusion of SIG RRs in responses: 1020 1. when an RRset is placed in a response, its SIG RR has a higher 1021 priority for inclusion than additional RRs that may need to be 1022 included. If space does not permit its inclusion, the response 1023 MUST be considered truncated except as provided in 2 below. 1025 2. When a SIG RR is present in the zone for an additional 1026 information section RR, the response MUST NOT be considered 1027 truncated merely because space does not permit the inclusion of 1028 the SIG RR with the additional information. 1030 3. SIGs to authenticate glue records and NS RRs for subzones at a 1031 delegation point are unnecessary and MUST NOT be sent. 1033 4. If a SIG covers any RR that would be in the answer section of 1034 the response, its automatic inclusion MUST be in the answer 1035 section. If it covers an RR that would appear in the authority 1036 section, its automatic inclusion MUST be in the authority 1037 section. If it covers an RR that would appear in the additional 1038 information section it MUST appear in the additional information 1039 section. This is a change in the existing standard [RFCs 1034, 1040 1035] which contemplates only NS and SOA RRs in the authority 1041 section. 1043 5. Optionally, DNS transactions may be authenticated by a SIG RR at 1044 the end of the response in the additional information section 1045 (Section 4.1.8.1). Such SIG RRs are signed by the DNS server 1046 originating the response. Although the signer field MUST be a 1047 name of the originating server host, the owner name, class, TTL, 1048 and original TTL, are meaningless. The class and TTL fields 1049 SHOULD be zero. To conserve space, the owner name SHOULD be 1050 root (a single zero octet). If transaction authentication is 1051 desired, that SIG RR must be considered the highest priority for 1052 inclusion. 1054 4.3 Processing Responses and SIG RRs 1056 The following rules apply to the processing of SIG RRs included in a 1057 response: 1059 1. A security aware resolver that receives a response from a 1060 security aware server via a secure communication with the AD bit 1061 (see Section 6.1) set, MAY choose to accept the RRs as received 1062 without verifying the zone SIG RRs. 1064 2. In other cases, a security aware resolver SHOULD verify the SIG 1065 RRs for the RRs of interest. This may involve initiating 1066 additional queries for SIG or KEY RRs, especially in the case of 1067 getting a response from a server that does not implement 1068 security. (As explained in 2.3.5 above, it will not be possible 1069 to secure CNAMEs being served up by non-secure resolvers.) 1071 NOTE: Implementers might expect the above SHOULD to be a MUST. 1072 However, local policy or the calling application may not require 1073 the security services. 1075 3. If SIG RRs are received in response to a user query explicitly 1076 specifying the SIG type, no special processing is required. 1078 If the message does not pass integrity checks or the SIG does not 1079 check against the signed RRs, the SIG RR is invalid and should be 1080 ignored. If all of the SIG RR(s) purporting to authenticate an RRset 1081 are invalid, then the RRset is not authenticated. 1083 If the SIG RR is the last RR in a response in the additional 1084 information section and has a type covered of zero, it is a 1085 transaction signature of the response and the query that produced the 1086 response. It MAY be optionally checked and the message rejected if 1087 the checks fail. But even if the checks succeed, such a transaction 1088 authentication SIG does NOT directly authenticate any RRs in the 1089 message. Only a proper SIG RR signed by the zone or a key tracing 1090 its authority to the zone or to static resolver configuration can 1091 directly authenticate RRs, depending on resolver policy (see Section 1092 6). If a resolver does not implement transaction and/or request 1093 SIGs, it MUST ignore them without error. 1095 If all checks indicate that the SIG RR is valid then RRs verified by 1096 it should be considered authenticated. 1098 4.4 Signature Lifetime, Expiration, TTLs, and Validity 1100 Security aware servers MUST NOT consider SIG RRs to authenticate 1101 anything before their signature inception or after its expiration 1102 time (see also Section 6). Security aware servers MUST NOT consider 1103 any RR to be authenticated after all its signatures have expired. 1104 When a secure server caches authenticated data, if the TTL would 1105 expire at a time further in the future than the authentication 1106 expiration time, the server SHOULD trim the TTL in the cache entry 1107 not to extent beyond the authentication expiration time. Within 1108 these constraints, servers should continue to follow DNS TTL aging. 1109 Thus authoritative servers should continue to follow the zone refresh 1110 and expire parameters and a non-authoritative server should count 1111 down the TTL and discard RRs when the TTL is zero (even for a SIG 1112 that has not yet reached its authentication expiration time). In 1113 addition, when RRs are transmitted in a query response, the TTL 1114 should be trimmed so that current time plus the TTL does not extend 1115 beyond the authentication expiration time. Thus, in general, the TTL 1116 on a transmitted RR would be 1118 min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) 1120 When signatures are generated, signature expiration times should be 1121 set far enough in the future that it is quite certain that new 1122 signatures can be generated before the old ones expire. However, 1123 setting expiration too far into the future could mean a long time to 1124 flush any bad data or signatures that may have been generated. 1126 It is recommended that signature lifetime be a small multiple of the 1127 TTL (ie, 4 to 16 times the TTL) but not less than a reasonable 1128 maximum re-signing interval and not less than the zone expiry time. 1130 5. Non-existent Names and Types 1132 The SIG RR mechanism described in Section 4 above provides strong 1133 authentication of RRs that exist in a zone. But it is not clear 1134 above how to verifiably deny the existence of a name in a zone or a 1135 type for an existent name. 1137 The nonexistence of a name in a zone is indicated by the NXT ("next") 1138 RR for a name interval containing the nonexistent name. An NXT RR or 1139 RRs and its or their SIG(s) are returned in the authority section, 1140 along with the error, if the server is security aware. The same is 1141 true for a non-existent type under an existing name except that there 1142 is no error indication other than an empty answer section 1143 accompanying the NXT(s). This is a change in the existing standard 1144 [RFCs 1034/1035] which contemplates only NS and SOA RRs in the 1145 authority section. NXT RRs will also be returned if an explicit query 1146 is made for the NXT type. 1148 The existence of a complete set of NXT records in a zone means that 1149 any query for any name and any type to a security aware server 1150 serving the zone will result in an reply containing at least one 1151 signed RR unless it is a query for delegation point NS or glue A or 1152 AAAA RRs. 1154 5.1 The NXT Resource Record 1156 The NXT resource record is used to securely indicate that RRs with an 1157 owner name in a certain name interval do not exist in a zone and to 1158 indicate what RR types are present for an existing name. 1160 The owner name of the NXT RR is an existing name in the zone. It's 1161 RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone 1162 create a chain of all of the literal owner names in that zone, 1163 including unexpanded wildcards but omitting the owner name of glue 1164 address records unless they would otherwise be included. This implies 1165 a canonical ordering of all domain names in a zone as described in 1166 Section 8. The presence of the NXT RR means that no name between its 1167 owner name and the name in its RDATA area exists and that no other 1168 types exist under its owner name. 1170 There is a potential problem with the last NXT in a zone as it wants 1171 to have an owner name which is the last existing name in canonical 1172 order, which is easy, but it is not obvious what name to put in its 1173 RDATA to indicate the entire remainder of the name space. This is 1174 handled by treating the name space as circular and putting the zone 1175 name in the RDATA of the last NXT in a zone. 1177 The NXT RRs for a zone SHOULD be automatically calculated and added 1178 to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed 1179 the zone minimum TTL. 1181 The type number for the NXT RR is 30. 1183 NXT RRs are only signed by zone level keys. 1185 5.2 NXT RDATA Format 1187 The RDATA for an NXT RR consists simply of a domain name followed by 1188 a bit map, as shown below. 1190 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1191 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 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | next domain name / 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | type bit map / 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 The NXT RR type bit map format currently defined is one bit per RR 1199 type present for the owner name. A one bit indicates that at least 1200 one RR of that type is present for the owner name. A zero indicates 1201 that no such RR is present. All bits not specified because they are 1202 beyond the end of the bit map are assumed to be zero. Note that bit 1203 30, for NXT, will always be on so the minimum bit map length is 1204 actually four octets. Trailing zero octets are prohibited in this 1205 format. The first bit represents RR type zero (an illegal type which 1206 can not be present) and so will be zero in this format. This format 1207 is not used if there exists an RR with a type number greater than 1208 127. If the zero bit of the type bit map is a one, it indicates that 1209 a different format is being used which will always be the case if a 1210 type number greater than 127 is present. 1212 The domain name may be compressed with standard DNS name compression 1213 when being transmitted over the network. The size of the bit map can 1214 be inferred from the RDLENGTH and the length of the next domain name. 1216 5.3 Additional Complexity Due to Wildcards 1218 Proving that a non-existent name response is correct or that a 1219 wildcard expansion response is correct makes things a little more 1220 complex. 1222 In particular, when a non-existent name response is returned, an NXT 1223 must be returned showing that the exact name queried did not exist 1224 and, in general, one or more additional NXT's need to be returned to 1225 also prove that there wasn't a wildcard whose expansion should have 1226 been returned. (There is no need to return multiple copies of the 1227 same NXT.) These NXTs, if any, are returned in the authority section 1228 of the response. 1230 Furthermore, if a wildcard expansion is returned in a response, in 1231 general one or more NXTs needs to also be returned in the authority 1232 section to prove that no more specific name (including possibly more 1233 specific wildcards in the zone) existed on which the response should 1234 have been based. 1236 5.4 Example 1238 Assume zone foo.nil has entries for 1240 big.foo.nil, 1241 medium.foo.nil. 1242 small.foo.nil. 1243 tiny.foo.nil. 1245 Then a query to a security aware server for huge.foo.nil would 1246 produce an error reply with an RCODE of NXDOMAIN and the authority 1247 section data including something like the following: 1249 foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil 1250 foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 1251 19970102030405 ;signature expiration 1252 19961211100908 ;signature inception 1253 2143 ;key identifier 1254 foo.nil. ;signer 1255 AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm 1256 fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) 1257 ) 1258 big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil 1259 big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 1260 19970102030405 ;signature expiration 1261 19961211100908 ;signature inception 1262 2143 ;key identifier 1263 foo.nil. ;signer 1264 MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 1265 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) 1266 ) 1268 Note that this response implies that big.foo.nil is an existing name 1269 in the zone and thus has other RR types associated with it than NXT. 1270 However, only the NXT (and its SIG) RR appear in the response to this 1271 query for huge.foo.nil, which is a non-existent name. 1273 5.5 Special Considerations at Delegation Points 1275 A name (other than root) which is the head of a zone also appears as 1276 the leaf in a superzone. If both are secure, there will always be 1277 two different NXT RRs with the same name. They can be easily 1278 distinguished by their signers, the next domain name fields, the 1279 presence of the SOA type bit, etc. Security aware servers should 1280 return the correct NXT automatically when required to authenticate 1281 the non-existence of a name and both NXTs, if available, on explicit 1282 query for type NXT. 1284 Non-security aware servers will never automatically return an NXT and 1285 some old implementations may only return the NXT from the subzone on 1286 explicit queries. 1288 5.6 Zone Transfers 1290 The subsections below describe how full and incremental zone 1291 transfers are secured. 1293 SIG RRs secure all authoritative RRs transferred for both full and 1294 incremental [RFC 1995] zone transfers. NXT RRs are an essential 1295 element in secure zone transfers and assure that every authoritative 1296 name and type will be present; however, if there are multiple SIGs 1297 with the same name and type covered, a subset of the SIGs could be 1298 sent as long as at least one is present and, in the case of unsigned 1299 delegation point NS or glue A or AAAA RRs a subset of these RRs or 1300 simply a modified set could be sent as long as at least one of each 1301 type is included. 1303 When an incremental or full zone transfer request is received with 1304 the same or newer version number than that of the server's copy of 1305 the zone, it is replied to with just the SOA RR of the server's 1306 current version and the SIG RRset verifying that SOA RR. 1308 The complete NXT chains specified in this document enable a resolver 1309 to obtain, by successive queries chaining through NXTs, all of the 1310 names in a zone even if zone transfers are prohibited. Different 1311 format NXTs may be specified in the future to avoid this. 1313 5.6.1 Full Zone Transfers 1315 To provide server authentication that a complete transfer has 1316 occurred, transaction authentication SHOULD be used on full zone 1317 transfers. This provides strong server based protection for the 1318 entire zone in transit. 1320 5.6.2 Incremental Zone Transfers 1322 Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be 1323 verified in the same way as for a full zone transfer and the 1324 integrity of the NXT name chain and correctness of the NXT type bits 1325 for the zone after the incremental RR deletes and adds can check each 1326 disjoint area of the zone updated. But the completeness of an 1327 incremental transfer can not be confirmed because usually neither the 1328 deleted RR section nor the added RR section has a compete zone NXT 1329 chain. As a result, a server which securely supports IXFR must 1330 handle IXFR SIG RRs for each incremental transfer set that it 1331 maintains. 1333 The IXFR SIG is calculated over the incremental zone update 1334 collection of RRs in the order in which it is transmitted: old SOA, 1335 then deleted RRs, then new SOA and added RRs. Within each section, 1336 RRs must be ordered as specified in Section 8. If condensation of 1337 adjacent incremental update sets is done by the zone owner, the 1338 original IXFR SIG for each set included in the condensation must be 1339 discarded and a new on IXFR SIG calculated to cover the resulting 1340 condensed set. 1342 The IXFR SIG really belongs to the zone as a whole, not to the zone 1343 name. Although it SHOULD be correct for the zone name, the labels 1344 field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only 1345 sent as part of an incremental zone transfer. After validation of 1346 the IXFR SIG, the transferred RRs MAY be considered valid without 1347 verification of the internal SIGs if such trust in the server 1348 conforms to local policy. 1350 6. How to Resolve Securely and the AD and CD Bits 1352 Retrieving or resolving secure data from the Domain Name System (DNS) 1353 involves starting with one or more trusted public keys that have been 1354 staticly configured at the resolver. With starting trusted keys, a 1355 resolver willing to perform cryptography can progress securely 1356 through the secure DNS structure to the zone of interest as described 1357 in Section 6.3. Such trusted public keys would normally be configured 1358 in a manner similar to that described in Section 6.2. However, as a 1359 practical matter, a security aware resolver would still gain some 1360 confidence in the results it returns even if it was not configured 1361 with any keys but trusted what it got from a local well known server 1362 as if it were staticly configured. 1364 Data stored at a security aware server needs to be internally 1365 categorized as Authenticated, Pending, or Insecure. There is also a 1366 fourth transient state of Bad which indicates that all SIG checks 1367 have explicitly failed on the data. Such Bad data is not retained at 1368 a security aware server. Authenticated means that the data has a 1369 valid SIG under a KEY traceable via a chain of zero or more SIG and 1370 KEY RRs allowed by the resolvers policies to a KEY staticly 1371 configured at the resolver. Pending data has no authenticated SIGs 1372 and at least one additional SIG the resolver is still trying to 1373 authenticate. Insecure data is data which it is known can never be 1374 either Authenticated or found Bad in the zone where it was found 1375 because it is in or has been reached via a unsecured zone or because 1376 it is unsigned glue address or delegation point NS data. Behavior in 1377 terms of control of and flagging based on such data labels is 1378 described in Section 6.1. 1380 The proper validation of signatures requires a reasonably secure 1381 shared opinion of the absolute time between resolvers and servers as 1382 described in Section 6.4. 1384 6.1 The AD and CD Header Bits 1386 Two previously unused bits are allocated out of the DNS 1387 query/response format header. The AD (authentic data) bit indicates 1388 in a response that all the data included in the answer and authority 1389 portion of the response has been authenticated by the server 1390 according to the policies of that server. The CD (checking disabled) 1391 bit indicates in a query that Pending (non-authenticated) data is 1392 acceptable to the resolver sending the query. 1394 These bits are allocated from the previously must-be-zero Z field as 1395 follows: 1397 1 1 1 1 1 1 1398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1399 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1400 | ID | 1401 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1402 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 1403 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1404 | QDCOUNT | 1405 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1406 | ANCOUNT | 1407 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1408 | NSCOUNT | 1409 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1410 | ARCOUNT | 1411 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1413 These bits are zero in old servers and resolvers. Thus the responses 1414 of old servers are not flagged as authenticated to security aware 1415 resolvers and queries from non-security aware resolvers do not assert 1416 the checking disabled bit and thus will be answered by security aware 1417 servers only with Authenticated or Insecure data. Security aware 1418 resolvers MUST NOT trust the AD bit unless they trust the server they 1419 are talking to and either have a secure path to it or use DNS 1420 transaction security. 1422 Any security aware resolver willing to do cryptography SHOULD assert 1423 the CD bit on all queries to permit it to impose its own policies and 1424 to reduce DNS latency time by allowing security aware servers to 1425 answer with Pending data. 1427 Security aware servers MUST NOT return Bad data. For non-security 1428 aware resolvers or security aware resolvers requesting service by 1429 having the CD bit clear, security aware servers MUST return only 1430 Authenticated or Insecure data in the answer and authority sections 1431 with the AD bit set in the response. Security aware servers SHOULD 1432 return Pending data, with the AD bit clear in the response, to 1433 security aware resolvers requesting this service by asserting the CD 1434 bit in their request. The AD bit MUST NOT be set on a response 1435 unless all of the RRs in the answer and authority sections of the 1436 response are either Authenticated or Insecure. The AD bit does not 1437 cover the additional information section. 1439 6.2 Staticly Configured Keys 1441 The public key to authenticate a zone SHOULD be defined in local 1442 configuration files before that zone is loaded at the primary server 1443 so the zone can be authenticated. 1445 While it might seem logical for everyone to start with a public key 1446 associated with the root zone and staticly configure this in every 1447 resolver, this has problems. The logistics of updating every DNS 1448 resolver in the world should this key ever change would be severe. 1449 Furthermore, many organizations will explicitly wish their "interior" 1450 DNS implementations to completely trust only their own DNS servers. 1451 Interior resolvers of such organizations can then go through the 1452 organization's zone servers to access data outside the organization's 1453 domain and need not be configured with keys above the organization's 1454 DNS apex. 1456 Host resolvers that are not part of a larger organization may be 1457 configured with a key for the domain of their local ISP whose 1458 recursive secure DNS caching server they use. 1460 6.3 Chaining Through The DNS 1462 Starting with one or more trusted keys for any zone, it should be 1463 possible to retrieve signed keys for that zone's subzones which have 1464 a key. A secure sub-zone is indicated by a KEY RR with non-null key 1465 information appearing with the NS RRs in the sub-zone and which may 1466 also be present in the parent. These make it possible to descend 1467 within the tree of zones. 1469 6.3.1 Chaining Through KEYs 1471 In general, some RRset that you wish to validate in the secure DNS 1472 will be signed by one or more SIG RRs. Each of these SIG RRs has a 1473 signer under whose name is stored the public KEY to use in 1474 authenticating the SIG. Each of those KEYs will, generally, also be 1475 signed with a SIG. And those SIGs will have signer names also 1476 referring to KEYs. And so on. As a result, authentication leads to 1477 chains of alternating SIG and KEY RRs with the first SIG signing the 1478 original data whose authenticity is to be shown and the final KEY 1479 being some trusted key staticly configured at the resolver performing 1480 the authentication. 1482 In testing such a chain, the validity periods of the SIGs encountered 1483 must be intersected to determine the validity period of the 1484 authentication of the data, a purely algorithmic process. In 1485 addition, the validation of each SIG over the data with reference to 1486 a KEY must meet the objective cryptographic test implied by the 1487 cryptographic algorithm used (although even here the resolver may 1488 have policies as to trusted algorithms and key lengths). Finally, 1489 the judgement that a SIG with a particular signer name can 1490 authenticate data (possibly a KEY RRset) with a particular owner 1491 name, is primarily a policy question. Ultimately, this is a policy 1492 local to the resolver and any clients that depend on that resolver's 1493 decisions. It is, however, recommended, that the policy below be 1494 adopted: 1496 Let A < B mean that A is a shorter domain name than B formed by 1497 dropping one or more whole labels from the left end of B, i.e., 1498 A is a direct or indirect superdomain of B. Let A = B mean that 1499 A and B are the same domain name (i.e., are identical after 1500 letter case canonicalization). Let A > B mean that A is a 1501 longer domain name than B formed by adding one or more whole 1502 labels on the left end of B, i.e., A is a direct or indirect 1503 subdomain of B 1505 Let Static be the owner names of the set of staticly configured 1506 trusted keys at a resolver. 1508 Then Signer is a valid signer name for a SIG authenticating an 1509 RRset (possibly a KEY RRset) with owner name Owner at the 1510 resolver if any of the following three rules apply: 1512 (1) Owner > or = Signer (except that if Signer is root, Owner 1513 must be root or a top level domain name). That is, Owner is the 1514 same as or a subdomain of Signer. 1516 (2) ( Owner < Signer ) and ( Signer > or = some Static ). That 1517 is, Owner is a superdomain of Signer and Signer is staticly 1518 configured or a subdomain of a staticly configured key. 1520 (3) Signer = some Static. That is, the signer is exactly some 1521 staticly configured key. 1523 Rule 1 is the rule for descending the DNS tree and includes a special 1524 prohibition on the root zone key due to the restriction that the root 1525 zone be only one label deep. This is the most fundamental rule. 1527 Rule 2 is the rule for ascending the DNS tree from one or more 1528 staticly configured keys. Rule 2 has no effect if only root zone 1529 keys are staticly configured. 1531 Rule 3 is a rule permitting direct cross certification. Rule 3 has 1532 no effect if only root zone keys are staticly configured. 1534 Great care should be taken that the consequences have been fully 1535 considered before making any local policy adjustments to these rules 1536 (other than dispensing with rules 2 and 3 if only root zone keys are 1537 staticly configured). 1539 6.3.2 Conflicting Data 1541 It is possible that there will be multiple SIG-KEY chains that appear 1542 to authenticate conflicting RRset answers to the same query. A 1543 resolver should choose only the most reliable answer to return and 1544 discard other data. This choice of most reliable is a matter of 1545 local policy which could take into account differing trust in 1546 algorithms, key sizes, staticly configured keys, zones traversed, 1547 etc. The technique given below is recommended for taking into 1548 account SIG-KEY chain length. 1550 A resolver should keep track of the number of successive secure zones 1551 traversed from a staticly configured key starting point to any secure 1552 zone it can reach. In general, the lower such a distance number is, 1553 the greater the confidence in the data. Staticly configured data 1554 should be given a distance number of zero. If a query encounters 1555 different Authenticated data for the same query with different 1556 distance values, that with a larger value should be ignored unless 1557 some other local policy covers the case. 1559 A security conscious resolver should completely refuse to step from a 1560 secure zone into a unsecured zone unless the unsecured zone is 1561 certified to be non-secure by the presence of an authenticated KEY RR 1562 for the unsecured zone with the no-key type value. Otherwise the 1563 resolver is getting bogus or spoofed data. 1565 If legitimate unsecured zones are encountered in traversing the DNS 1566 tree, then no zone can be trusted as secure that can be reached only 1567 via information from such non-secure zones. Since the unsecured zone 1568 data could have been spoofed, the "secure" zone reached via it could 1569 be counterfeit. The "distance" to data in such zones or zones 1570 reached via such zones could be set to 256 or more as this exceeds 1571 the largest possible distance through secure zones in the DNS. 1573 6.4 Secure Time 1575 Coordinated interpretation of the time fields in SIG RRs requires 1576 that reasonably consistent time be available to the hosts 1577 implementing the DNS security extensions. 1579 A variety of time synchronization protocols exist including the 1580 Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are 1581 used, they MUST be used securely so that time can not be spoofed. 1582 Otherwise, for example, a host could get its clock turned back and 1583 might then believe old SIG RRs, and the data they authenticate, which 1584 were valid but are no longer. 1586 7. ASCII Representation of Security RRs 1588 This section discusses the format for master file and other ASCII 1589 presentation of the three DNS security resource records. 1591 The algorithm field in KEY and SIG RRs can be represented as either 1592 an unsigned integer or symbolicly. The following initial symbols are 1593 defined as indicated: 1595 Value Symbol 1597 001 RSAMD5 1598 002 DH 1599 003 DSA 1600 004 ECC 1601 252 INDIRECT 1602 253 PRIVATEDNS 1603 254 PRIVATEOID 1605 7.1 Presentation of KEY RRs 1607 KEY RRs may appear as single logical lines in a zone data master file 1608 [RFC 1033]. 1610 The flag field is represented as an unsigned integer or a sequence of 1611 mnemonics as follows separated by instances of the verticle bar ("|") 1612 character: 1614 BIT Mnemonic Explanation 1615 0-1 key type 1616 NOCONF =1 confidentiality use prohibited 1617 NOAUTH =2 authentication use prohibited 1618 NOKEY =3 no key present 1619 2 FLAG2 - reserved 1620 3 EXTEND flags extension 1621 4 FLAG4 - reserved 1622 5 FLAG5 - reserved 1623 6-7 name type 1624 USER =0 (default, may be omitted) 1625 ZONE =1 1626 HOST =2 (host or other end entity) 1627 NTYP3 - reserved 1628 8 FLAG8 - reserved 1629 9 FLAG9 - reserved 1630 10 FLAG10 - reserved 1631 11 FLAG11 - reserved 1632 12-15 signatory field, values 0 to 15 1633 can be represented by SIG0, SIG1, ... SIG15 1635 No flag mnemonic need be present if the bit or field it represents is 1636 zero. 1638 The protocol octet can be represented as either an unsigned integer 1639 or symbolicly. The following initial symbols are defined: 1641 000 NONE 1642 001 TLS 1643 002 EMAIL 1644 003 DNSSEC 1645 004 IPSEC 1646 255 ALL 1648 Note that if the type flags field has the NOKEY value, nothing 1649 appears after the algorithm octet. 1651 The remaining public key portion is represented in base 64 (see 1652 Appendix A) and may be divided up into any number of white space 1653 separated substrings, down to single base 64 digits, which are 1654 concatenated to obtain the full signature. These substrings can span 1655 lines using the standard parenthesis. 1657 Note that the public key may have internal sub-fields but these do 1658 not appear in the master file representation. For example, with 1659 algorithm 1 there is a public exponent size, then a public exponent, 1660 and then a modulus. With algorithm 254, there will be an OID size, 1661 an OID, and algorithm dependent information. But in both cases only a 1662 single logical base 64 string will appear in the master file. 1664 7.2 Presentation of SIG RRs 1666 A data SIG RR may be represented as a single logical line in a zone 1667 data file [RFC 1033] but there are some special considerations as 1668 described below. (It does not make sense to include a transaction or 1669 request authenticating SIG RR in a file as they are a transient 1670 authentication that covers data including an ephemeral transaction 1671 number and so must be calculated in real time.) 1673 There is no particular problem with the signer, covered type, and 1674 times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY 1675 is the year, the first MM is the month number (01-12), DD is the day 1676 of the month (01-31), HH is the hour in 24 hours notation (00-23), 1677 the second MM is the minute (00-59), and SS is the second (00-59). 1679 The original TTL field appears as an unsigned integer. 1681 If the original TTL, which applies to the type signed, is the same as 1682 the TTL of the SIG RR itself, it may be omitted. The date field 1683 which follows it is larger than the maximum possible TTL so there is 1684 no ambiguity. 1686 The "labels" field appears as an unsigned integer. 1688 The key tag appears as an unsigned number. 1690 However, the signature itself can be very long. It is the last data 1691 field and is represented in base 64 (see Appendix A) and may be 1692 divided up into any number of white space separated substrings, down 1693 to single base 64 digits, which are concatenated to obtain the full 1694 signature. These substrings can be split between lines using the 1695 standard parenthesis. 1697 7.3 Presentation of NXT RRs 1699 NXT RRs do not appear in original unsigned zone master files since 1700 they should be derived from the zone as it is being signed. If a 1701 signed file with NXTs added is printed or NXTs are printed by 1702 debugging code, they appear as the next domain name followed by the 1703 RR type present bits as an unsigned interger or sequence of RR 1704 mnemonics. 1706 8. Canonical Form and Order of Resource Records 1708 This section specifies, for purposes of domain name system (DNS) 1709 security, the canonical form of resource records (RRs), their name 1710 order, and their overall order. A canonical name order is necessary 1711 to construct the NXT name chain. A canonical form and ordering 1712 within an RRset is necessary in consistently constructing and 1713 verifying SIG RRs. A canonical ordering of types within a name is 1714 required in connection with incremental transfer (Section 5.6.2). 1716 8.1 Canonical RR Form 1718 For purposes of DNS security, the canonical form for an RR is the 1719 wire format of the RR with domain names (1) fully expanded (no name 1720 compression via pointers), (2) all domain name letters set to lower 1721 case, (3) owner name wild cards in master file form (no substitution 1722 made for *), and (4) the original TTL substituted for the current 1723 TTL. 1725 8.2 Canonical DNS Name Order 1727 For purposes of DNS security, the canonical ordering of owner names 1728 is to sort individual labels as unsigned left justified octet strings 1729 where the absence of a octet sorts before a zero value octet and 1730 upper case letters are treated as lower case letters. Names in a 1731 zone are sorted by sorting on the highest level label and then, 1732 within those names with the same highest level label by the next 1733 lower label, etc. down to leaf node labels. Within a zone, the zone 1734 name itself always exists and all other names are the zone name with 1735 some prefix of lower level labels. Thus the zone name itself always 1736 sorts first. 1738 Example: 1739 foo.example 1740 a.foo.example 1741 yljkjljk.a.foo.example 1742 Z.a.foo.example 1743 zABC.a.FOO.EXAMPLE 1744 z.foo.example 1745 *.z.foo.example 1746 \200.z.foo.example 1748 8.3 Canonical RR Ordering Within An RRset 1750 Within any particular owner name and type, RRs are sorted by RDATA as 1751 a left justified unsigned octet sequence where the absence of an 1752 octet sorts before the zero octet. 1754 8.4 Canonical Ordering of RR Types 1756 When RRs of the same name but different types must be ordered, they 1757 are ordered by type, considering the type to be an unsigned integer, 1758 except that SIG RRs are placed immediately after the type they cover. 1759 Thus, for example, an A record would be put before an MX record 1760 because A is type 1 and MX is type 15 but if both were signed, the 1761 order would be A < SIG(A) < MX < SIG(MX). 1763 9. Conformance 1765 Levels of server and resolver conformance are defined below. 1767 9.1 Server Conformance 1769 Two levels of server conformance for DNS security are defined as 1770 follows: 1772 BASIC: Basic server compliance is the ability to store and retrieve 1773 (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or 1774 caching server for a secure zone MUST have at least basic compliance 1775 and even then some things, such as secure CNAMEs, will not work 1776 without full compliance. 1778 FULL: Full server compliance adds the following to basic compliance: 1779 (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) 1780 ability, given a zone file and private key, to add appropriate SIG 1781 and NXT RRs, possibly via a separate application, (3) proper 1782 automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) 1783 suppression of CNAME following on retrieval of the security type RRs, 1784 (5) recognize the CD query header bit and set the AD query header 1785 bit, as appropriate, and (6) proper handling of the two NXT RRs at 1786 delegation points. Primary servers for secure zones MUST be fully 1787 compliant and for complete secure operation, all secondary, caching, 1788 and other servers handling the zone SHOULD be fully compliant as 1789 well. 1791 9.2 Resolver Conformance 1793 Two levels of resolver compliance (including the resolver portion of 1794 a server) are defined for DNS Security: 1796 BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs 1797 when they are explicitly requested. 1799 FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT 1800 RRs including verification of SIGs at least for the mandatory 1801 algorithm, (2) maintains appropriate information in its local caches 1802 and database to indicate which RRs have been authenticated and to 1803 what extent they have been authenticated, (3) performs additional 1804 queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when 1805 needed, (4) normally sets the CD query header bit on its queries. 1807 10. Security Considerations 1809 This document specifies extensions to the Domain Name System (DNS) 1810 protocol to provide data integrity and data origin authentication, 1811 public key distribution, and optional transaction and request 1812 security. 1814 It should be noted that, at most, these extensions guarantee the 1815 validity of resource records, including KEY resource records, 1816 retrieved from the DNS. They do not magically solve other security 1817 problems. For example, using secure DNS you can have high confidence 1818 in the IP address you retrieve for a host name; however, this does 1819 not stop someone for substituting an unauthorized host at that 1820 address or capturing packets sent to that address and falsely 1821 responding with packets apparently from that address. Any reasonably 1822 complete security system will require the protection of many 1823 additional facets of the Internet beyond DNS. 1825 The implementation of NXT RRs as described herein enables a resolver 1826 to determine all the names in a zone even if zone transfers are 1827 prohibited (section 5.6). This is an active area of work and may 1828 change. 1830 A number of precautions in DNS implementation have evolved over the 1831 years to harden the insecure DNS against spoofing. These precautions 1832 should not be abandoned but should be considered to provide 1833 additional protection in case of key compromise in secure DNS. 1835 11. IANA Considerations 1837 KEY RR flag bits 2 and 8-11 and all flag extension field bits can be 1838 assigned by IETF consensus as defined in RFC 2434. The remaining 1839 values of the NAMTYP flag field and flag bits 4 and 5 (which could 1840 conceivably become an extension of the NAMTYP field) can only be 1841 assigned by an IETF Standards Action [RFC 2434]. 1843 Algorithm numbers 5 through 251 are available for assignment should 1844 sufficient reason arise. However, the designation of a new algorithm 1845 could have a major impact on interoperability and requires an IETF 1846 Standards Action [RFC 2434]. The existence of the private algorithm 1847 types 253 and 254 should satify most needs for private or proprietary 1848 algorithms. 1850 Additional values of the Protocol Octet (5-254) can be assigned by 1851 IETF Consensus [RFC 2434]. 1853 The meaning of the first bit of the NXT RR "type bit map" being a one 1854 can only be assigned by a standards action. 1856 References 1858 [RFC 1033] - M. Lottor, "Domain Administrators Operations Guide", 1859 November 1987. 1861 [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and 1862 Facilities", STD 13, November 1987. 1864 [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and 1865 Specifications", STD 13, November 1987. 1867 [RFC 1305] - D. Mills, "Network Time Protocol (v3)", March 1992. 1869 [RFC 1530] - C. Malamud, and M. Rose, "Principles of Operation for 1870 the TPC.INT Subdomain: General Principles and Policy", October 1993. 1872 [RFC 1825] - Ran Atkinson, "Security Architecture for the Internet 1873 Protocol", August 1995. 1875 [RFC 1982] - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", 1876 09/03/1996. 1878 [RFC 1995] - Masatka Ohta, "Incremental Zone Transfer in DNS", August 1879 1996. 1881 [RFC 2030] - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 1882 for IPv4, IPv6 and OSI", October 1996. 1884 [RFC 2045] - N. Freed & N. Borenstein, "Multipurpose Internet Mail 1885 Extensions (MIME) Part One: Format of Internet Message Bodies", 1886 November 1996. 1888 [RFC 2065] - Donald Eastlake 3rd, Charles Kaufman, "Domain Name 1889 System Security Extensions", 01/03/1997. 1891 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 1892 Requirement Levels", March 1997. 1894 [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 1895 Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. 1897 [RFC 2137] - Donald Eastlake 3rd, "Secure Domain Name System Dynamic 1898 Update", 04/21/1997. 1900 [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS 1901 Specification", July 1997. 1903 [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an 1904 IANA Considerations Section in RFCs", October 1998. 1906 draft-ietf-dnssec-rsa-*.txt, D. Eastlake, "RSA/MD5 KEYs and SIGs in 1907 the Domain Name System (DNS)". 1909 draft-ietf-dnssec-dhk-*.txt, D. Eastlake, "Storage of Diffie-Hellman 1910 Keys in the Domain Name System (DNS)". 1912 draft-ietf-dnssec-dss-*.txt, D. Eastlake, "DSA KEYs and SIGs in the 1913 Domain Name System (DNS)". 1915 draft-ietf-dsnssec-certs-*.txt, D. Eastlake, O. Gudmundsson, "Storing 1916 Certificates in the Domain Name System". 1918 draft-ietf-dnssec-secops-*.txt, D. Eastlake, "DNS Operational 1919 Security Considerations". 1921 [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. 1923 Author's Address 1925 Donald E. Eastlake 3rd 1926 IBM 1927 65 Shindegan Hill Road 1928 RR #1 1929 Carmel, NY 10512 1931 Telephone: +1-914-784-7913 (w) 1932 +1-914-276-2668 (h) 1933 fax: +1-914-784-3833 (w-fax) 1934 email: dee3@us.ibm.com 1936 Expiration and File Name 1938 This draft expires June 1999. 1940 Its file name is draft-ietf-dnssec-secext2-07.txt. 1942 Appendix A: Base 64 Encoding 1944 The following encoding technique is taken from [RFC 2045] by N. 1945 Borenstein and N. Freed. It is reproduced here in an edited form for 1946 convenience. 1948 A 65-character subset of US-ASCII is used, enabling 6 bits to be 1949 represented per printable character. (The extra 65th character, "=", 1950 is used to signify a special processing function.) 1952 The encoding process represents 24-bit groups of input bits as output 1953 strings of 4 encoded characters. Proceeding from left to right, a 1954 24-bit input group is formed by concatenating 3 8-bit input groups. 1955 These 24 bits are then treated as 4 concatenated 6-bit groups, each 1956 of which is translated into a single digit in the base 64 alphabet. 1958 Each 6-bit group is used as an index into an array of 64 printable 1959 characters. The character referenced by the index is placed in the 1960 output string. 1962 Table 1: The Base 64 Alphabet 1964 Value Encoding Value Encoding Value Encoding Value Encoding 1965 0 A 17 R 34 i 51 z 1966 1 B 18 S 35 j 52 0 1967 2 C 19 T 36 k 53 1 1968 3 D 20 U 37 l 54 2 1969 4 E 21 V 38 m 55 3 1970 5 F 22 W 39 n 56 4 1971 6 G 23 X 40 o 57 5 1972 7 H 24 Y 41 p 58 6 1973 8 I 25 Z 42 q 59 7 1974 9 J 26 a 43 r 60 8 1975 10 K 27 b 44 s 61 9 1976 11 L 28 c 45 t 62 + 1977 12 M 29 d 46 u 63 / 1978 13 N 30 e 47 v 1979 14 O 31 f 48 w (pad) = 1980 15 P 32 g 49 x 1981 16 Q 33 h 50 y 1983 Special processing is performed if fewer than 24 bits are available 1984 at the end of the data being encoded. A full encoding quantum is 1985 always completed at the end of a quantity. When fewer than 24 input 1986 bits are available in an input group, zero bits are added (on the 1987 right) to form an integral number of 6-bit groups. Padding at the 1988 end of the data is performed using the '=' character. Since all base 1989 64 input is an integral number of octets, only the following cases 1990 can arise: (1) the final quantum of encoding input is an integral 1991 multiple of 24 bits; here, the final unit of encoded output will be 1992 an integral multiple of 4 characters with no "=" padding, (2) the 1993 final quantum of encoding input is exactly 8 bits; here, the final 1994 unit of encoded output will be two characters followed by two "=" 1995 padding characters, or (3) the final quantum of encoding input is 1996 exactly 16 bits; here, the final unit of encoded output will be three 1997 characters followed by one "=" padding character. 1999 Appendix B: Changes from RFC 2065 2001 This section summarizes the most important changes that have been 2002 made since RFC 2065. 2004 1. Most of Section 7 of [RFC 2065] called "Operational 2005 Considerations", has been removed and may be made into a separate 2006 document [draft-ietf-dnssec-secops-*.txt]. 2008 2. The KEY RR has been changed by (2a) eliminating the "experimental" 2009 flag as unnecessary, (2b) reserving a flag bit for flags 2010 expansion, (2c) more compactly encoding a number of bit fields in 2011 such a way as to leave unchanged bits actually used by the limited 2012 code currently deployed, (2d) eliminating the IPSEC and email flag 2013 bits which are replaced by values of the protocol field and adding 2014 a protocol field value for DNS security itself, (2e) adding 2015 material to indicate that zone KEY RRs occur only at delegation 2016 points, and (2f) removing the description of the RSA/MD5 algorithm 2017 to a separate document [draft-ietf-dnssec-rsa-*.txt]. Section 3.4 2018 describing the meaning of various combinations of "no-key" and key 2019 present KEY RRs has been added and the secure / unsecure status of 2020 a zone has been clarified as being per algorithm. 2022 3. The SIG RR has been changed by (3a) renaming the "time signed" 2023 field to be the "signature inception" field, (3b) clarifying that 2024 signature expiration and inception use serial number ring 2025 arithmetic, (3c) changing the definition of the key footprint/tag 2026 for algorithms other than 1 and adding Appendix C to specify its 2027 calculation. In addition, the SIG covering type AXFR has been 2028 eliminated while one covering IXFR [RFC 1995] has been added (see 2029 section 5.6). 2031 4. Algorithm 3, the DSA algorithm, is now designated as the mandatory 2032 to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is 2033 now a recommended option. Algorithm 2 and 4 are designated as the 2034 Diffie-Hellman key and elliptic cryptography algorithms 2035 respectively, all to be defined in separate documents. Algorithm 2036 code point 252 is designated to indicate "indirect" keys, to be 2037 defined in a separate document, where the actual key is elsewhere. 2038 Both the KEY and SIG RR definitions have been simplified by 2039 eliminating the "null" algorithm 253 as defined in [RFC 2065]. 2040 That algorithm had been included because at the time it was 2041 thought it might be useful in DNS dynamic update [RFC 2136]. It 2042 was in fact not so used and it is dropped to simplify DNS 2043 security. Howver, that algorithm number has been re-used to 2044 indicate private algorithms where a domain name specifies the 2045 algorithm. 2047 5. The NXT RR has been changed so that (5a) the NXT RRs in a zone 2048 cover all names, including wildcards as literal names without 2049 expansion, except for glue address records whose names would not 2050 otherwise appear, (5b) all NXT bit map areas whose first octet has 2051 bit zero set have been reserved for future definition, (5c) the 2052 number of and circumstances under which an NXT must be returned in 2053 connection with wildcard names has been extended, and (5d) in 2054 connection with the bit map, references to the WKS RR have been 2055 removed and verticle bars ("|") have been added between the RR 2056 type mnemonics in the ASCII representation. 2058 6. Information on the canonical form and ordering of RRs has been 2059 moved into a separate Section 8. 2061 7. A subsection covering incremental and full zone transfer has been 2062 added in Section 5. 2064 8. Concerning DNS chaining: Further specification and policy 2065 recommendations on secure resolution have been added, primarily in 2066 Section 6.3.1. It is now clearly stated that authenticated data 2067 has a validity period of the intersection of the validity periods 2068 of the SIG RRs in its authentication chain. The requirement to 2069 staticly configure a superzone's key signed by a zone in all of 2070 the zone's authoritative servers has been removed. The 2071 recommendation to continue DNS security checks in a secure island 2072 of DNS data that is separated from other parts of the DNS tree by 2073 insecure zones and does not contain a zone for which a key has 2074 been staticly configured was dropped. 2076 9. It was clarified that the presence of the AD bit in a response 2077 does not apply to the additional information section or to glue 2078 address or delegation point NS RRs. The AD bit only indicates 2079 that the answer and authority sections of the response are 2080 authoritative. 2082 10. It is now required that KEY RRs and NXT RRs be signed only with 2083 zone-level keys. 2085 11. Add IANA Considerations section and references to RFC 2434. 2087 Appendix C: Key Tag Calculation 2089 The key tag field in the SIG RR is just a means of more efficiently 2090 selecting the correct KEY RR to use when there is more than one KEY 2091 RR candidate available, for example, in verifying a signature. It is 2092 possible for more than one candidate key to have the same tag, in 2093 which case each must be tried until one works or all fail. The 2094 following reference implementation of how to calculate the Key Tag, 2095 for all algorithms other than algorithm 1, is in ANSI C. It is coded 2096 for clarity, not efficiency. (See section 4.1.6 for how to determine 2097 the Key Tag of an algorithm 1 key.) 2099 /* assumes int is at least 16 bits 2100 first byte of the key tag is the most significant byte of return value 2101 second byte of the key tag is the least significant byte of return value 2102 */ 2104 int keytag ( 2106 unsigned char key[], /* the RDATA part of the KEY RR */ 2107 unsigned int keysize, /* the RDLENGTH */ 2108 ) 2109 { 2110 long int ac; /* assumed to be 32 bits or larger */ 2112 for ( ac = 0, i = 0; i < keysize; ++i ) 2113 ac += (i&1) ? key[i] : key[i]<<8; 2114 ac += (ac>>16) & 0xFFFF; 2115 return ac & 0xFFFF; 2116 }