idnits 2.17.1 draft-ietf-dnssec-update2-00.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-26) 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-update2-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-update2-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-update2-00.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-update2-00.txt,', but the file name used is 'draft-ietf-dnssec-update2-00' == 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. ** The abstract seems to contain references ([RFC2137]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 276: '...on, such KEY RRs MUST be entity or use...' RFC 2119 keyword, line 279: '...he actual update MUST be within the sc...' RFC 2119 keyword, line 375: '... MUST be zero if dynamic update is n...' RFC 2119 keyword, line 376: '... MUST be non-zero if it is....' RFC 2119 keyword, line 409: '...rong and unique name restrictions MUST...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (August 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2137' is mentioned on line 41, but not defined ** Obsolete undefined reference: RFC 2137 (Obsoleted by RFC 3007) == Missing Reference: 'RFC 1034' is mentioned on line 100, but not defined -- Looks like a reference, but probably isn't: '1035' on line 100 == Unused Reference: 'RFC1035' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RFC2065' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC2137' is defined on line 522, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (Obsoleted by RFC 3007) Summary: 14 errors (**), 1 flaw (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Donald E. Eastlake 3rd 3 OBSOLETES RFC 2137 Transfinite Systems Company 4 Expires: February 1999 August 1998 6 Secure Domain Name System (DNS) Dynamic Update 7 ------ ------ ---- ------ ----- ------- ------ 9 Status of This Document 11 This draft, file name draft-ietf-dnssec-update2-00.txt, is intended 12 to become a Proposed Standard RFC obsoleting RFC 2137. Distribution 13 of this document is unlimited. Comments should be sent to the DNS 14 security mailing list or the author. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet- 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 30 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 31 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 Revised Domain Name System (DNS) protocol extensions to authenticate 36 the data in DNS and provide key distribution services have been 37 defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the 38 original DNS security protocol definition in RFC 2065. In addition, 39 symetric key DNS transaction signatures have been defined in draft- 40 ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were 41 also been defined [RFC 2137] in connection RFC 2065. This document 42 updates secure dynamic update in light of draft-ietf-dnssec-secext2- 43 *.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use 44 digital signatures covering requests and data to secure updates and 45 restrict updates to those authorized to perform them as indicated by 46 the updater's possession of cryptographic keys. 48 Table of Contents 50 Status of This Document....................................1 52 Abstract...................................................2 54 Table of Contents..........................................3 56 1. Introduction............................................4 57 1.1. Overview of DNS Dynamic Update........................4 58 1.2. Overview of Public Key DNS Security...................4 59 1.3 Overview of Secret Key DNS Security....................5 61 2. Two Basic Modes.........................................6 62 2.1. Mode A................................................6 63 2.2. Mode B................................................7 65 3. Keys....................................................8 66 3.1. Update Keys...........................................8 67 3.1.1. Public Update Key Name Scope........................8 68 3.1.2. Public Update Key Class Scope.......................8 69 3.1.3. Public Update Key Signatory Field...................9 70 3.2. Zone Keys and Update Modes...........................10 71 3.3. Wildcard Public Key Punch Through....................11 73 4. Update Signatures......................................13 74 4.1. Update Request Signatures............................13 75 4.2. Update Data Signatures...............................13 77 5. Security Considerations................................14 78 6. IANA Considerations....................................14 80 References................................................15 81 Author's Address..........................................15 82 Expiration and File Name..................................15 84 1. Introduction 86 Dynamic update operations have been defined for the Domain Name 87 System (DNS) in RFC 2136 but that RFC does not include a description 88 of security for those updates. Public key means of securing DNS data 89 and transactions and using it for public key distribution were 90 defined in RFC 2065 which has been updated by draft-ietf-dnssec- 91 sexect2-*.txt, and secret key means of securing DNS transactions are 92 defined in draft-ietf-dnsind-tsig-*.txt. 94 This document provides techniques based on the updated DNS security 95 RFC draft-ietf-dnssec-sexect2-*.txt and draft-ietf-dnsind-tsig-*.txt 96 to authenticate DNS updates of secure zones. (Secret key signatures 97 could be used to authenticate updates on non-secured DNS zones. That 98 case In not considered in this document.) 100 Familiarity with the DNS system [RFC 1034, 1035] is assumed. 101 Familiarity with the DNS security and dynamic update will be helpful. 103 1.1. Overview of DNS Dynamic Update 105 DNS dynamic update defines a new DNS opcode, new DNS request and 106 response structure if that opcode is used, and new error codes. An 107 update can specify complex combinations of deletion and insertion 108 (with or without pre-existence testing) of resource records (RRs) 109 with one or more owner names; however, all testing and changes for 110 any particular DNS update request are restricted to a single zone. 111 Updates occur at the primary server for a zone. 113 The primary server for a dynamic zone must increment the zone SOA 114 serial number when an update occurs or the next time the SOA is 115 retrieved if one or more updates have occurred since the previous SOA 116 retrieval and the updates themselves did not update the SOA. 118 1.2. Overview of Public Key DNS Security 120 DNS security authenticates data in the DNS by also storing digital 121 signatures in the DNS as SIG resource records (RRs). A SIG RR 122 provides a digital signature on the set of all RRs with the same 123 owner name and class as the SIG and whose type is the type covered by 124 the SIG. The SIG RR cryptographically binds the covered RR set to 125 the signer, signature inception and expiration date, etc. There are 126 one or more keys associated with every secure zone and all data in 127 the secure zone is signed either by a zone key or by a dynamic update 128 key tracing its authority to a zone key. 130 DNS security also defines transaction SIGs and request SIGs. 132 Transaction SIGs appear at the end of a response. They authenticate 133 the response and bind it to the corresponding request using the key 134 of the host where the responding DNS server is. 136 Request SIGs appear at the end of a request and authenticate the 137 request with the key of the submitting entity. 139 DNS security also permits the storage of public keys in the DNS via 140 KEY RRs. These KEY RRs are also, of course, authenticated by SIG 141 RRs. KEY RRs for zones may be stored in their superzone and/or their 142 authoritive subzone servers so that the secure DNS tree of zones can 143 be traversed by a security aware resolver. 145 1.3 Overview of Secret Key DNS Security 147 draft-ietf-dnsind-tsig-*.txt provides a means for two processes that 148 share a secret key to authenticate DNS requests and responses sent 149 between them by appending TSIG digital signature RRs to those 150 requests and responses. Secret key digital signatures are generally 151 much faster to calculate and verify than public key digital 152 signatures. In addition, the need, in general, to cache KEY RRs and 153 perform the KEY-SIG chain verifications is avoided. 155 However, the cost for this speed and simplicity in TSIG use is the 156 requirement to securely achieve key distribution or agreement between 157 the communicating processes and to achieve agreement as to the 158 authority represented by a correct TSIG on a requested using a 159 partciular key. 161 2. Two Basic Modes 163 A dynamic secure zone is any secure DNS zone that 164 (1) has a zone KEY RR signatory field indicates that updates are 165 implemented and either 166 (2a) contains one or more KEY RRs that can authorize dynamic 167 updates, i.e., entity or user KEY RRs with the signatory field 168 non-zero, or 169 (2b) has a primary server with one or more secret keys configured 170 to authorize updates requests and shared with one or more 171 update requesters. 173 Note: 2a and 2b can both be true for a zone. 175 There are two basic modes of dynamic secure zone which relate to the 176 update strategy, mode A and mode B. A summary comparison table is 177 given below and then each mode is described. 179 SUMMARY OF DYNAMIC SECURE ZONE MODES 181 CRITERIA: | MODE A | MODE B 182 =========================+====================+=================== 183 Definition: | Zone Key Off line | Zone Key On line 184 =========================+====================+=================== 185 Server Workload | Medium | High 186 -------------------------+--------------------+------------------- 187 Key Restrictions | Fine grain | Coarse grain 188 -------------------------+--------------------+------------------- 189 Dynamic Data Temporality | Transient | Permanent 190 -------------------------+--------------------+------------------- 191 Dynamic Key Rollover | No | Yes 192 -------------------------+--------------------+------------------- 194 NOTE: The Mode A / Mode B distinction only effects the validation 195 and performance of update requests. It has no effect on retrievals. 197 2.1. Mode A 199 For mode A, the zone owner private key and static zone master file 200 are kept off-line for maximum security of the static zone contents. 202 As a consequence, any dynamicly added or changed RRs are signed in 203 the secure zone by their authorizing dynamic update key and they are 204 backed up, along with this SIG RR, in a separate online dynamic 205 master file. In this type of zone, server computation is generally 206 reduced since the server need only check signatures on the update 207 data and request, which have already been signed by the updater 208 (generally a much faster operation than signing data) and update the 209 NXT RRs which need to be changed, if any. Because the dynamicly 210 added RRs retain their update KEY signed SIG, finer grained control 211 of updates can be implemented via the KEY RR signatory field (unique 212 name restriction and weak update key restriction). Because dynamic 213 data is only stored in the online dynamic master file and only 214 authenticated by dynamic keys which expire, updates are transient in 215 nature. Key rollover for an entity that can authorize dynamic 216 updates is more cumbersome since the authority of their key must be 217 traceable to a zone key and so, in general, they must securely 218 communicate a new key to the zone authority for manual transfer to 219 the off line static master file. NOTE: for this mode the zone SOA and 220 NXT RRs must be signed by a dynamic update key, which will be an end 221 entity key with an owner name of the zone name, and that private key 222 must be kept on line so that the SOA and NXTs can be changed for 223 updates. 225 2.2. Mode B 227 For mode B, the zone owner private key and master file are kept on- 228 line at the zone primary server. When authenticated updates succeed, 229 SIGs under the zone key for the resulting data (as well as possible 230 NXT and SOA changes) are calculated and these SIG (and possible 231 SOA/NXT) changes are entered into the zone and the unified on-line 232 master file. 234 As a consequence, this mode generally requires more computational 235 effort on the part of the server as it computes zone data signatures 236 in addition to verifying the signatures on requests. Because signing 237 generally takes more effort than verification, these signatures 238 generally will take more effort to calculate than it would take to 239 verify the data signatures required in Mode A. Because the zone key 240 is used to sign all the zone data, the information as to who 241 originated the current state of dynamic RR sets and even that data is 242 the result of a dynamic update as opposed to coming from an original 243 master file, is lost, making unavailable the fine grain control of 244 some values of the KEY RR signatory field. In addition, the 245 incorporation of the updates into the primary master file and their 246 authentication by the zone key makes them permanent in nature. 247 Maintaining the zone key on-line also means that dynamic update keys 248 which are signed by the zone key can be dynamically updated in real 249 time since the zone key is available to dynamically sign new values. 251 3. Keys 253 Dynamic update requests depend on update keys as described in section 254 3.1 below. In addition, the zone secure dynamic update mode and 255 availability of some options is indicated in the zone KEY(s). 256 Finally, a special rule is used in searching for KEYs to validate 257 updates as described in section 3.3. 259 3.1. Update Keys 261 All update requests to a secure zone must include signature(s) by one 262 or more private or secret keys that together can authorize that 263 update. In order for the Domain Name System (DNS) server executing 264 the update request to confirm this (1) any secret keys must be know 265 to it, along with the authority represented by the secret key, and 266 (2) any private key or keys must have the corresponding public key or 267 keys available to and authenticatable by that server as specially 268 flagged KEY Resource Records (RRs). 270 The scope of authority of any secret keys is as configured at the 271 Server. Methods of describing and configuring such authority are not 272 discussed in this document. 274 The scope of authority of public update keys is indicated by their 275 KEY RR owner name, class, and signatory field flags as described 276 below. In addition, such KEY RRs MUST be entity or user keys and not 277 have the authentication use prohibited bit on. 279 All parts of the actual update MUST be within the scope/authority of 280 at least one of the keys used for a request SIG or TSIG on the update 281 request as described in section 4. 283 3.1.1. Public Update Key Name Scope 285 The owner name of any update authorizing KEY RR must (1) be the same 286 as the owner name of any RRs being added or deleted or (2) a wildcard 287 name including within its extended scope (see section 3.3) the name 288 of any RRs being added or deleted and those RRs must be in the same 289 zone. 291 3.1.2. Public Update Key Class Scope 293 The class of any update authorizing KEY RR must be the same as the 294 class of any RR's being added or deleted. 296 3.1.3. Public Update Key Signatory Field 298 The four bit "signatory field" (see draft-ietf-dnssec-secext2-*.txt) 299 of any update authorizing KEY RR must be non-zero. The bits have the 300 meanings described below for non-zone keys (see section 3.2 for zone 301 type keys). 303 UPDATE KEY RR SIGNATORY FIELD BITS 305 0 1 2 3 306 +-----------+-----------+-----------+-----------+ 307 | zone | strong | unique | general | 308 +-----------+-----------+-----------+-----------+ 310 Bit 0, zone control - If nonzero, this key is authorized to attach, 311 detach, and move zones by creating and deleting NS, glue A, and 312 zone KEY RR(s). If zero, the key can not authorize any update 313 that would effect such RRs. This bit is meaningful for both 314 type A and type B dynamic secure zones. An update attempting to 315 add an NS or zone KEY RR to a node (i.e., make the node a 316 delegation point) is illegal if there are any deeper nodes in 317 the zone. 319 NOTE: do not confuse the "zone" signatory field bit with the 320 "zone" key type bit. 322 Bit 1, strong update - If zero, the key can only authorize updates 323 where any existing RRs of the same owner and class are 324 authenticated by a SIG using the same key. If nonzero, this key 325 is authorized to add and delete RRs even if there are other RRs 326 with the same owner name and class that are authenticated by a 327 SIG signed with a different dynamic update KEY. This bit is 328 meaningful only for type A dynamic zones that have a zone KEY 329 advertising that the feature is available. It is ignored in 330 type B dynamic zones. 332 Keeping this bit zero on multiple KEY RRs with the same or 333 nested wild card owner names permits multiple entities to exist 334 that can create and delete names but can not effect RRs with 335 different owner names from any they created. In effect, this 336 creates two levels of dynamic update key, strong and weak, where 337 weak keys are prohibited from interfering with each other but a 338 strong key can interfere with any weak keys or other strong 339 keys. 341 Bit 2, unique name update - This bit is useful only if the owner name 342 is a wildcard. (Any dynamic update KEY with a non-wildcard name 343 is, in effect, a unique name update key.) If zero, this key is 344 authorized to add and updates RRs for any number of names within 345 its wildcard scope. If nonzero, this key is authorized to add 346 and update RRs for only a single owner name. If there already 347 exist RRs with one or more names signed by this key, they may be 348 updated but no new name created until the number of existing 349 names is reduced to zero. This bit is meaningful only for mode 350 A dynamic zones that have a zone KEY advertising that the 351 feature is available. It is ignored in mode B dynamic zones. 353 This bit can be used to restrict a KEY from flooding a zone with 354 new names. In conjunction with a local administratively imposed 355 limit on the number of dynamic RRs with a particular name, it 356 can completely restrict a KEY from flooding a zone with RRs. 358 Bit 3, general update - The general update signatory field bit has no 359 special meaning. If the other three bits are all zero, it must 360 be one so that the field is non-zero to designate that the key 361 is an update key. The meaning of all values of the signatory 362 field with the general bit on and one or more other signatory 363 field bits on is reserved. 365 All the signatory bit update authorizations described above only 366 apply if the update is within the name and class scope as per 367 sections 3.1.1 and 3.1.2. 369 3.2. Zone Keys and Update Modes 371 Zone type keys are automatically authorized to sign anything in their 372 zone, of course, regardless of the value of their signatory field. 373 For zone keys, the signatory field bits have different means than 374 they they do for update keys, as shown below. The signatory field 375 MUST be zero if dynamic update is not supported for a secure zone and 376 MUST be non-zero if it is. 378 ZONE KEY RR SIGNATORY FIELD BITS 380 0 1 2 3 381 +-----------+-----------+-----------+-----------+ 382 | mode | strong | unique | general | 383 +-----------+-----------+-----------+-----------+ 385 Bit 0, mode - This bit indicates the update mode for this zone. Zero 386 indicates mode A while a one indicates mode B. 388 Bit 1, strong update - If nonzero, this indicates that the "strong" 389 key feature described in section 3.1.3 above is implemented and 390 enabled for this secure zone. If zero, the feature is not 391 available and all update keys are treated as strong. Has no 392 effect if the zone is a mode B secure update zone. 394 Bit 2, unique name update - If nonzero, this indicates that the 395 "unique name" feature described in section 3.1.3 above is 396 implemented and enabled for this secure zone. If zero, this 397 feature is not available and no wildcard update key is treated 398 as restricted to a single name. Has no effect if the zone is a 399 mode B secure update zone. 401 Bit 3, general - This bit has no special meaning. If dynamic update 402 for a zone is supported and the other bits in the zone key 403 signatory field are zero, it must be a one. The meaning of zone 404 keys where the signatory field has the general bit and one or 405 more other bits on is reserved. 407 If there are multiple zone KEY RRs with non-zero signatory fields and 408 zone policy is in transition, they might have different signatory 409 field values. In that case, strong and unique name restrictions MUST 410 be enforced as long as there is a non-expired zone key being 411 advertised that indicates mode A with the strong or unique name bit 412 on respectively. Mode B updates (i.e., no data signatures) MUST be 413 supported as long as there is a non-expired zone key that indicates 414 mode B. Mode A or mode ambiguous updates may be treated as mode B 415 updates at server option if non-expired zone keys indicate that both 416 are supported. 418 A server that will be executing update operations on a zone, that is, 419 the primary master server, MUST NOT advertize a zone key that will 420 attract requests for a mode or features that it can not support. 422 3.3. Wildcard Public Key Punch Through 424 Just as a zone key is valid throughout the entire zone, public update 425 keys with wildcard names are valid throughout their extended scope, 426 within the zone. That is, they remain valid for any name that would 427 match them, even existing specific names within their apparent scope. 429 (If this were not so, then whenever a name within a wildcard scope 430 was created by dynamic update using a wildcard named public update 431 key for authorization, it would be necessary to first create a copy 432 of the KEY RR with this name, because otherwise the existence of the 433 more specific name would hide the authorizing KEY RR and would make 434 later updates impossible. An updater could create such a KEY RR but 435 could not zone sign it with their authorizing signer. They would 436 have to sign it with the same key using the wildcard name as signer. 437 (This would create update KEYs signed by update KEYs which was 438 permitted in RFC 2065 but, for simplicity, is prohibit in draft- 439 ietf-dnssec-secext2-*.txt which requires all KEYs to be signed by 440 zone keys.) Thus in creating, for example, one hundred type A RRs 441 authorized by a *.1.1.1.in-addr.arpa KEY RR, without key punch 442 through 100 As, 100 KEYs, and 200 SIGs would have to be created as 443 opposed to merely 100 As and 100 SIGs with wildcard key punch 444 through.) 446 4. Update Signatures 448 Two kinds of signatures can appear in updates. Request signatures, 449 which are always required, cover the entire request and authenticate 450 the DNS header, including opcode, counts, etc., as well as the data. 451 Data signatures, on the other hand, appear only among the RRs to be 452 added and are only required for mode A operation. These two types of 453 signatures are described further below. 455 4.1. Update Request Signatures 457 An update can effect multiple owner names in a zone. It may be that 458 these different names are covered by different public or secret 459 dynamic update keys. For every owner name effected, the updater must 460 know a private or secret key valid to authorize updates for that name 461 (and the zone's class) and must prove this by appending request SIG 462 and/or TSIG RRs under each such key. 464 Request signatures occur in the Additional Information section. As 465 specified in draft-ietf-dnssec-secext2-*.txt, a public request 466 signature is a SIG RR occurring at the end of a request with a type 467 covered field of zero. As specified in draft-ietf-dnsind-tsig-*.txt, 468 a secret key request signature is a TSIG RR occuring at the end of 469 the request. Each request SIG or TSIG signs the entire request, 470 including DNS header, but excluding any other request signatures and 471 with the ARCOUNT in the DNS header set to what it would be without 472 the request signatures. 474 4.2. Update Data Signatures 476 Mode A dynamic secure zones require that the update requester provide 477 SIG RRs that will authenticate the after-update state of all RR sets 478 that are changed by the update and are non-empty after the update. 479 These SIG RRs appear in the request as RRs to be added and the 480 request must delete any previous data SIG RRs that are invalidated by 481 the request. 483 In Mode B dynamic secure zones, all zone data is authenticated by 484 zone key SIG RRs. In this case, data signatures need not be included 485 with the update. A prospective updater can determine which mode an 486 updatable secure zone is using by examining the signatory field bits 487 of the zone KEY RR or RRs (see section 3.2). 489 5. Security Considerations 491 Any secure zone permitting dynamic updates is inherently less secure 492 than a static secure zone maintained off line as recommended in 493 draft-ietf-dnssec-secops-*.txt. If nothing else, secure dynamic 494 update requires on line change to and re-signing of the zone SOA 495 resource record (RR) to increase the SOA serial number. This means 496 that compromise of the primary server host could lead to arbitrary 497 serial number changes. 499 Isolation of dynamic RRs to separate zones from those holding most 500 static RRs can limit the damage that could occur from breach of a 501 dynamic zone's security. 503 6. IANA Considerations 505 Allocations of values of the KEY RR Signatory field described herein 506 as "reserved" requires an IETF consensus. 508 References 510 [RFC1035] - Domain Names - Implementation and Specifications, P. 511 Mockapetris, November 1987. 513 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 514 November 1987. 516 [RFC2065] - Domain Name System Security Extensions. D. Eastlake, 3rd, 517 C. Kaufman. January 1997 519 [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE). 520 P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. 522 [RFC2137] - Secure Domain Name System Dynamic Update. D. Eastlake. 523 April 1997. 525 draft-ietf-dnsind-tsig-*.txt 527 draft-ietf-dnssec-secext2-*.txt. 529 draft-ietf-dnssec-secops-*.txt. 531 Author's Address 533 Donald E. Eastlake, 3rd 534 Transfinite Systems Company 535 318 Acton Street 536 Carlisle, MA 01741 USA 538 Telephone: +1 978-287-4877 539 +1 978-371-7148 (fax) 540 email: dee3@torque.pothole.com 542 Expiration and File Name 544 This draft expires February 1999. 546 Its file name is draft-ietf-dnssec-update2-00.txt.