idnits 2.17.00 (12 Aug 2021) /tmp/idnits31051/draft-ietf-dnssec-update-03.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 (2022-05-14) 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) 2022 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-update-03.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-update-03.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-update-03.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-update-03.txt,', but the file name used is 'draft-ietf-dnssec-update-03' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 352: '... MUST be zero if dynamic update is n...' RFC 2119 keyword, line 388: '... Mode B updates MUST be supported as ...' RFC 2119 keyword, line 394: '...y master server, MUST not advertize a ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A server that will be executing update operations on a zone, that is, the primary master server, MUST not advertize a zone key that will attract requests for a mode or features that it can not support. == 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 (24 December 1996) is 9272 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 1034' is mentioned on line 101, but not defined -- Looks like a reference, but probably isn't: '1035' on line 101 == Unused Reference: 'RFC1034' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 479, but no explicit reference was found in the text Summary: 11 errors (**), 1 flaw (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 CyberCash, Inc. 3 Expires: 23 June 1997 24 December 1996 5 Secure Domain Name System Dynamic Update 6 ------ ------ ---- ------ ------- ------ 8 Status of This Document 10 This draft, file name draft-ietf-dnssec-update-03.txt, is intended to 11 be become a Proposed Standard RFC. Distribution of this document is 12 unlimited. Comments should be sent to the DNS security mailing list 13 or the author. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet- 23 Drafts as reference material or to cite them other than as a 24 ``working draft'' or ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 29 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 30 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 32 Abstract 34 Domain Name System (DNS) protocol extensions have been defined to 35 authenticate the data in DNS and provide key distribution services 36 (draft-ietf-dnssec-secext-10.txt). DNS Dynamic Update operations 37 have also been defined (draft-ietf-dnsind-dynDNS-*.txt>, but without 38 a detailed description of security for the update operation. This 39 draft describes how to use DNSSEC digital signatures covering 40 requests and data to secure updates and restrict updates to those 41 authorized to perform them as indicated by the updater's possession 42 of cryptographic keys. 44 Acknowledgements 46 The contributions of the following persons (who are listed in 47 alphabetic order) to this draft are gratefully acknowledged: 49 Olafur Gudmundsson (ogud@tis.com> 50 Charlie Kaufman 51 Stuart Kwan 52 Edward Lewis 54 Table of Contents 56 Status of This Document....................................1 58 Abstract...................................................2 59 Acknowledgements...........................................2 61 Table of Contents..........................................3 63 1. Introduction............................................4 64 1.1 Overview of DNS Dynamic Update.........................4 65 1.2 Overview of DNS Security...............................4 67 2. Two Basic Modes.........................................6 69 3. Keys....................................................8 70 3.1 Update Keys............................................8 71 3.1.1 Update Key Name Scope................................8 72 3.1.2 Update Key Class Scope...............................8 73 3.1.3 Update Key Signatory Field...........................8 74 3.2 Zone Keys and Update Modes............................10 75 3.3 Wildcard Key Punch Through............................11 77 4. Update Signatures......................................12 78 4.1 Update Request Signatures.............................12 79 4.2 Update Data Signatures................................12 81 5. Security Considerations................................13 82 References................................................13 83 Author's Address..........................................13 84 Expiration and File Name..................................13 86 1. Introduction 88 Dynamic update operations have been defined for the Domain Name 89 System (DNS) in draft-ietf-dnsind-dynDNS-*.txt but without a detailed 90 description of security for those updates. Means of securing the DNS 91 and using it for key distribution have been defined in draft-ietf- 92 dnssec-sexect-10.txt [approved as a Proposed Standard but not yet 93 issued as an RFC]. 95 This draft proposes techniques based on the defined DNS security 96 mechanisms to authenticate DNS updates. In addition, a secure in- 97 key.int. domain is defined with special security policies. This in- 98 key domain permits access to entities by their key if the entity has 99 been registered in that domain. 101 Familiarity with the DNS system [RFC 1034, 1035] is assumed. 102 Familiarity with the DNS security and dynamic update proposals will 103 be helpful. 105 1.1 Overview of DNS Dynamic Update 107 DNS dynamic update defines a new DNS opcode, new DNS request and 108 response structure if that opcode is used, and new error codes. An 109 update can specify complex combinations of deletion and insertion 110 (with or without pre-existence testing) of resource records (RRs) 111 with one or more owner names; however, all testing and changes for 112 any particular DNS update request are restricted to a single zone. 113 Updates occur at the primary server for a zone. 115 The primary server for a secure dynamic zone must increment the zone 116 SOA serial number when an update occurs or the next time the SOA is 117 retrieved if one or more updates have occurred since the previous SOA 118 retrieval and the updates themselves did not update the SOA. 120 1.2 Overview of DNS Security 122 DNS security authenticates data in the DNS by also storing digital 123 signatures in the DNS as SIG resource records (RRs). A SIG RR 124 provides a digital signature on the set of all RRs with the same 125 owner name and class as the SIG and whose type is the type covered by 126 the SIG. The SIG RR cryptographically binds the covered RR set to 127 the signer, time signed, signature expiration date, etc. There are 128 one or more keys associated with every secure zone and all data in 129 the secure zone is signed either by a zone key or by a dynamic update 130 key tracing its authority to a zone key. 132 DNS security also defines transaction SIGs and request SIGs. 133 Transaction SIGs appear at the end of a response. Transaction SIGs 134 authenticate the response and bind it to the corresponding request 135 with the key of the host where the responding DNS server is. Request 136 SIGs appear at the end of a request and authenticate the request with 137 the key of the submitting entity. 139 Request SIGs are the primary means of authenticating update requests. 141 DNS security also permits the storage of public keys in the DNS via 142 KEY RRs. These KEY RRs are also, of course, authenticated by SIG 143 RRs. KEY RRs for zones are stored in their superzone and subzone 144 servers, if any, so that the secure DNS tree of zones can be 145 traversed by a security aware resolver. 147 2. Two Basic Modes 149 A dynamic secure zone is any secure DNS zone containing one or more 150 KEY RRs that can authorize dynamic updates, i.e., entity or user KEY 151 RRs with the signatory field non-zero, and whose zone KEY RR 152 signatory field indicates that updates are implemented. There are two 153 basic modes of dynamic secure zone which relate to the update 154 strategy, mode A and mode B. A summary comparison table is given 155 below and then each mode is described. 157 SUMMARY OF DYNAMIC SECURE ZONE MODES 159 CRITERIA: | MODE A | MODE B 160 =========================+====================+=================== 161 Definition: | Zone Key Off line | Zone Key On line 162 =========================+====================+=================== 163 Server Workload | Low | High 164 -------------------------+--------------------+------------------- 165 Static Data Security | Very High | Medium-High 166 -------------------------+--------------------+------------------- 167 Dynamic Data Security | Medium | Medium-High 168 -------------------------+--------------------+------------------- 169 Key Restrictions | Fine grain | Coarse grain 170 -------------------------+--------------------+------------------- 171 Dynamic Data Temporality | Transient | Permanent 172 -------------------------+--------------------+------------------- 173 Dynamic Key Rollover | No | Yes 174 -------------------------+--------------------+------------------- 176 For mode A, the zone owner key and static zone master file are always 177 kept off-line for maximum security of the static zone contents. 179 As a consequence, any dynamicly added or changed RRs are signed in 180 the secure zone by their authorizing dynamic update key and they are 181 backed up, along with this SIG RR, in a separate online dynamic 182 master file. In this type of zone, server computation is minimized 183 since the server need only check signatures on the update data and 184 request, which have already been signed by the updater, generally a 185 much faster operation than signing data. However, the AXFR SIG and 186 NXT RRs which covers the zone under the zone key will not cover 187 dynamically added data. Thus, for type A dynamic secure zones, zone 188 transfer security is not automatically provided for dynamically added 189 RRs, where they could be omitted, and authentication is not provided 190 for the server denial of the existence of a dynamically added type. 191 Because the dynamicly added RRs retain their update KEY signed SIG, 192 finer grained control of updates can be implemented via bits in the 193 KEY RR signatory field. Because dynamic data is only stored in the 194 online dynamic master file and only authenticated by dynamic keys 195 which expire, updates are transient in nature. Key rollover for an 196 entity that can authorize dynamic updates is more cumbersome since 197 the authority of their key must be traceable to a zone key and so, in 198 general, they must securely communicate a new key to the zone 199 authority for manual transfer to the off line static master file. 200 NOTE: for this mode the zone SOA must be signed by a dynamic update 201 key and that private key must be kept on line so that the SOA can be 202 changed for updates. 204 For mode B, the zone owner key and master file are kept on-line at 205 the zone primary server. When authenticated updates succeed, SIGs 206 under the zone key for the resulting data (including the possible NXT 207 type bit map changes) are calculated and these SIG (and possible NXT) 208 changes are entered into the zone and the unified on-line master 209 file. (The zone transfer AXFR SIG may be recalculated for each 210 update or on demand when a zone transfer is requested and it is out 211 of date.) 213 As a consequence, this mode requires considerably more computational 214 effort on the part of the server as the public/private keys are 215 generally arranged so that signing (calculating a SIG) is more effort 216 than verifying a signature. The security of static data in the zone 217 is decreased because the ultimate state of the static data being 218 served and the ultimate zone authority private key are all on-line on 219 the net. This means that if the primary server is subverted, false 220 data could be authenticated to secondaries and other 221 servers/resolvers. On the other hand, this mode of operation means 222 that data added dynamically is more secure than in mode A. Dynamic 223 data will be covered by the AXFR SIG and thus always protected during 224 zone transfers and will be included in NXT RRs so that it can be 225 falsely denied by a server only to the same extent that static data 226 can (i.e., if it is within a wild card scope). Because the zone key 227 is used to sign all the zone data, the information as to who 228 originated the current state of dynamic RR sets is lost, making 229 unavailable the effects of some of the update control bits in the KEY 230 RR signatory field. In addition, the incorporation of the updates 231 into the primary master file and their authentication by the zone key 232 makes then permanent in nature. Maintaining the zone key on-line 233 also means that dynamic update keys which are signed by the zone key 234 can be dynamically updated since the zone key is available to 235 dynamically sign new values. 237 NOTE: The Mode A / Mode B distinction only effects the validation 238 and performance of update requests. It has no effect on retrievals. 239 One reasonable operational scheme may be to keep a mostly static main 240 zone operating in Mode A and have one or more dynamic subzones 241 operating in Mode B. 243 3. Keys 245 Dynamic update requests depend on update keys as described in section 246 3.1 below. In addition, the zone secure dynamic update mode and 247 availability of some options is indicated in the zone key. Finally, 248 a special rule is used in searching for KEYs to validate updates as 249 described in section 3.3. 251 3.1 Update Keys 253 All update requests to a secure zone must include signatures by one 254 or more key(s) that together can authorize that update. In order for 255 the Domain Name System (DNS) server receiving the request to confirm 256 this, the key or keys must be available to and authenticated by that 257 server as a specially flagged KEY Resource Record. 259 The scope of authority of such keys is indicated by their KEY RR 260 owner name, class, and signatory field flags as described below. In 261 addition, such KEY RRs must be entity or user keys and not have the 262 authentication use prohibited bit on. All parts of the actual update 263 must be within the scope of at least one of the keys used for a 264 request SIG on the update request as described in section 4. 266 3.1.1 Update Key Name Scope 268 The owner name of any update authorizing KEY RR must (1) be the same 269 as the owner name of any RRs being added or deleted or (2) a wildcard 270 name including within its extended scope (see section 3.3) the name 271 of any RRs being added or deleted and those RRs must be in the same 272 zone. 274 3.1.2 Update Key Class Scope 276 The class of any update authorizing KEY RR must be the same as the 277 class of any RR's being added or deleted. 279 3.1.3 Update Key Signatory Field 281 The four bit "signatory field" (see draft-ietf-dnssec-secext-10.txt) 282 of any update authorizing KEY RR must be non-zero. The bits have the 283 meanings described below for non-zone keys (see section 3.2 for zone 284 type keys). 286 UPDATE KEY RR SIGNATORY FIELD BITS 288 0 1 2 3 289 +-----------+-----------+-----------+-----------+ 290 | zone | strong | unique | general | 291 +-----------+-----------+-----------+-----------+ 293 Bit 0, zone control - If nonzero, this key is authorized to attach, 294 detach, and move zones by creating and deleting NS, glue A, and 295 zone KEY RR(s). If zero, the key can not authorize any update 296 that would effect such RRs. This bit is meaningful for both 297 type A and type B dynamic secure zones. 299 NOTE: do not confuse the "zone" signatory field bit with the 300 "zone" key type bit. 302 Bit 1, strong update - If nonzero, this key is authorized to add and 303 delete RRs even if there are other RRs with the same owner name 304 and class that are authenticated by a SIG signed with a 305 different dynamic update KEY. If zero, the key can only 306 authorize updates where any existing RRs of the same owner and 307 class are authenticated by a SIG using the same key. This bit 308 is meaningful only for type A dynamic zones and is ignored in 309 type B dynamic zones. 311 Keeping this bit zero on multiple KEY RRs with the same or 312 nested wild card owner names permits multiple entities to exist 313 that can create and delete names but can not effect RRs with 314 different owner names from any they created. In effect, this 315 creates two levels of dynamic update key, strong and weak, where 316 weak keys are limited in interfering with each other but a 317 strong key can interfere with any weak keys or other strong 318 keys. 320 Bit 2, unique name update - If nonzero, this key is authorized to add 321 and update RRs for only a single owner name. If there already 322 exist RRs with one or more names signed by this key, they may be 323 updated but no new name created until the number of existing 324 names is reduced to zero. This bit is meaningful only for mode 325 A dynamic zones and is ignored in mode B dynamic zones. This bit 326 is meaningful only if the owner name is a wildcard. (Any 327 dynamic update KEY with a non-wildcard name is, in effect, a 328 unique name update key.) 330 This bit can be used to restrict a KEY from flooding a zone with 331 new names. In conjunction with a local administratively imposed 332 limit on the number of dynamic RRs with a particular name, it 333 can completely restrict a KEY from flooding a zone with RRs. 335 Bit 3, general update - The general update signatory field bit has no 336 special meaning. If the other three bits are all zero, it must 337 be one so that the field is non-zero to designate that the key 338 is an update key. The meaning of all values of the signatory 339 field with the general bit and one or more other signatory field 340 bits on is reserved. 342 All the signatory bit update authorizations described above only 343 apply if the update is within the name and class scope as per 344 sections 3.1.1 and 3.1.2. 346 3.2 Zone Keys and Update Modes 348 Zone type keys are automatically authorized to sign anything in their 349 zone, of course, regardless of the value of their signatory field. 350 For zone keys, the signatory field bits have different means than 351 they they do for update keys, as shown below. The signatory field 352 MUST be zero if dynamic update is not supported for a zone and MUST 353 be non-zero if it is. 355 ZONE KEY RR SIGNATORY FIELD BITS 357 0 1 2 3 358 +-----------+-----------+-----------+-----------+ 359 | mode | strong | unique | general | 360 +-----------+-----------+-----------+-----------+ 362 Bit 0, mode - This bit indicates the update mode for this zone. Zero 363 indicates mode A while a one indicates mode B. 365 Bit 1, strong update - If nonzero, this indicates that the "strong" 366 key feature described in section 3.1.3 above is implemented and 367 enabled for this secure zone. If zero, the feature is not 368 available. Has no effect if the zone is a mode B secure update 369 zone. 371 Bit 2, unique name update - If nonzero, this indicates that the 372 "unique name" feature described in section 3.1.3 above is 373 implemented and enabled for this secure zone. If zero, this 374 feature is not available. Has no effect if the zone is a mode B 375 secure update zone. 377 Bit 3, general - This bit has no special meeting. If dynamic update 378 for a zone is supported and the other bits in the zone key 379 signatory field are zero, it must be a one. The meaning of zone 380 keys where the signatory field has the general bit and one or 381 more other bits on is reserved. 383 If there are multiple dynamic update KEY RRs for a zone and zone 384 policy is in transition, they might have different non-zero signatory 385 fields. In that case, strong and unique name restrictions must be 386 enforced as long as there is a non-expired zone key being advertised 387 that indicates mode A with the strong or unique name bit on 388 respectively. Mode B updates MUST be supported as long as there is a 389 non-expired zone key that indicates mode B. Mode A updates may be 390 treated as mode B updates at server option if non-expired zone keys 391 indicate that both are supported. 393 A server that will be executing update operations on a zone, that is, 394 the primary master server, MUST not advertize a zone key that will 395 attract requests for a mode or features that it can not support. 397 3.3 Wildcard Key Punch Through 399 Just as a zone key is valid throughout the entire zone, update keys 400 with wildcard names are valid throughout their extended scope, within 401 the zone. That is, they remain valid for any name that would match 402 them, even existing specific names within their apparent scope. 404 If this were not so, then whenever a name within a wildcard scope was 405 created by dynamic update, it would be necessary to first create a 406 copy of the KEY RR with this name, because otherwise the existence of 407 the more specific name would hide the authorizing KEY RR and would 408 make later updates impossible. An updater could create such a KEY RR 409 but could not zone sign it with their authorizing signer. They would 410 have to sign it with the same key using the wildcard name as signer. 411 Thus in creating, for example, one hundred type A RRs authorized by a 412 *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100 413 KEYs, and 200 SIGs would have to be created as opposed to merely 100 414 As and 100 SIGs with key punch through. 416 4. Update Signatures 418 Two kinds of signatures can appear in updates. Request signatures, 419 which are always required, cover the entire request and authenticate 420 the DNS header, including opcode, counts, etc., as well as the data. 421 Data signatures, on the other hand, appear only among the RRs to be 422 added and are only required for mode A operation. These two types of 423 signatures are described further below. 425 4.1 Update Request Signatures 427 An update can effect multiple owner names in a zone. It may be that 428 these different names are covered by different dynamic update keys. 429 For every owner name effected, the updater must know a private key 430 valid for that name (and the zone's class) and must prove this by 431 appending request SIG RRs under each such key. 433 As specified in draft-ietf-dnssec-secext-10.txt [approved as a 434 Proposed Standard but not yet issues as an RFC], a request signature 435 is a SIG RR occurring at the end of a request with a type covered 436 field of zero. For an update, request signatures occur in the 437 Additional information section. Each request SIG signs the entire 438 request, including DNS header, but excluding any other request SIG(s) 439 and with the ARCOUNT in the DNS header set to what it wold be without 440 the request SIGs. 442 4.2 Update Data Signatures 444 Mode A dynamic secure zones require that the update requester provide 445 SIG RRs that will authenticate the after update state of all RR sets 446 that are changed by the update and are non-empty after the update. 447 These SIG RRs appear in the request as RRs to be added and the 448 request must delete any previous data SIG RRs that are invalidated by 449 the request. 451 In Mode B dynamic secure zones, all zone data is authenticated by 452 zone key SIG RRs. In this case, data signatures need not be included 453 with the update. A resolver can determine which mode an updatable 454 secure zone is using by examining the signatory field bits of the 455 zone KEY RR (see section 3.2). 457 5. Security Considerations 459 Any zone permitting dynamic updates is inherently less secure than a 460 static secure zone maintained off line as recommended in draft-ietf- 461 dnssec-secext-10.txt. If nothing else, secure dynamic update requires 462 on line change to and re-signing of the zone SOA resource record (RR) 463 to increase the SOA serial number. This means that compromise of the 464 primary server host could lead to arbitrary serial number changes. 466 Isolation of dynamic RRs to separate zones from those holding most 467 static RRs can limit the damage that could occur from breach of a 468 dynamic zone's security. 470 References 472 draft-ietf-dnssec-secext-10.txt. 474 draft-ietf-dnsind-dynDNS-*.txt. 476 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 477 November 1987. 479 [RFC1035] - Domain Names - Implementation and Specifications, P. 480 Mockapetris, November 1987. 482 Author's Address 484 Donald E. Eastlake, 3rd 485 CyberCash, Inc. 486 318 Acton Street 487 Carlisle, MA 01741 USA 489 Telephone: +1 508-287-4877 490 +1 508-371-7148 (fax) 491 +1 703-620-4200 (main office, Reston, Virginia, USA) 492 email: dee@cybercash.com 494 Expiration and File Name 496 This draft expires 23 June 1997. 498 Its file name is draft-ietf-dnssec-update-03.txt.