idnits 2.17.1 draft-ihren-dnsop-interim-signed-root-01.txt: -(584): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 623 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 20 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 159: '...al property that MUST be preserved in ...' RFC 2119 keyword, line 162: '... failure SHOULD NOT be introduced by...' RFC 2119 keyword, line 240: '...tures in the signed root zone MUST NOT...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2535' on line 523 looks like a reference -- Missing reference section? 'RFC3090' on line 526 looks like a reference -- Missing reference section? 'DS' on line 108 looks like a reference -- Missing reference section? 'RFC1996' on line 531 looks like a reference -- Missing reference section? 'RFC1995' on line 529 looks like a reference -- Missing reference section? 'AXFR-clarify' on line 561 looks like a reference -- Missing reference section? 'RFC2845' on line 534 looks like a reference -- Missing reference section? 'RFC2930' on line 540 looks like a reference -- Missing reference section? 'RFC3007' on line 543 looks like a reference -- Missing reference section? 'RFC3008' on line 546 looks like a reference -- Missing reference section? 'RFC3110' on line 549 looks like a reference -- Missing reference section? 'RFC3225' on line 552 looks like a reference -- Missing reference section? 'RFC3226' on line 555 looks like a reference -- Missing reference section? 'Delegation-Signer' on line 558 looks like a reference -- Missing reference section? 'AD-secure' on line 565 looks like a reference -- Missing reference section? 'Opt-In' on line 569 looks like a reference -- Missing reference section? 'Wild-card-optimize' on line 573 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Johan Ihren 2 draft-ihren-dnsop-interim-signed-root-01.txt Autonomica 3 October 2002 4 Expires in six months 6 An Interim Scheme for Signing the Public DNS Root 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo documents a proposed mechanism for a first stage of a 33 transition from an unsigned DNS root to a signed root, such that 34 the data in the root zone is accompanied by DNSSEC signatures to 35 allow validation. 37 The underlying reason for signing the root is to be able to provide 38 a more secure DNS hierarchy, where it is possible to distinguish 39 false answers from correct answers. 41 For the special case of the DNS root zone, an interim scheme is 42 proposed. This scheme is mostly aimed at securing the root zone 43 itself for technical and operational reasons, and to give 44 operational experience of DNSSEC. 46 1. Terminology 48 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 49 and "MAY" in this document are to be interpreted as described in 50 RFC 2119. 52 The term "zone" refers to the unit of administrative control in the 53 Domain Name System. "Name server" denotes a DNS name server that is 54 authoritative (i.e. knows all there is to know) for a DNS zone, 55 typically the root zone. A "resolver", finally, is a DNS "client", 56 i.e. an entity that sends DNS queries to authoritative nameservers 57 and interpret the results. 59 2. Motivation for signing the DNS root. 61 In the special case of the root zone there are very strong reasons 62 to take a slow and conservative approach to any changes with 63 operational impact. Signing the root is such a change. 65 DNSSEC[RFC2535, RFC3090] has been in development for a number of 66 years now and still has not reached the point where the last flag 67 day is behind us. 69 However, during the years of DNSSEC development and 70 refinement[RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, 71 AD-secure, Opt-in, Wild-card-optimize], the Internet has matured 72 and more and more businesses and other organizations have become 73 dependent on the stability and constant availability of the 74 Internet. 76 It is therefore prudent to do everything in our power to ensure 77 that the DNS infrastructure works as well as possible and, when 78 appropriate and possible, adding enhancements and functionality. 80 The time is now right for yet another step of improvement by 81 signing the root zone. By doing that any Internet user that so 82 wishes will obtain the ability of verifying the responses received 83 from the root nameservers. 85 Since this is new operational ground the objective is not maximum 86 security but rather an "Internet-wide" controlled experiment with a 87 signed root zone, where the trade off is that we utilize the fact 88 that there are operators in place that can help but they are not 89 sufficiently staffed to do off-line signing in a 24x7 mode. For 90 this reason it is fully possible to even do automatic signing, 91 since the purpose is to ensure that DNSSEC works operationally with 92 a signed root zone and gain experience from the exercise. 94 It should be pointed out, however, that the experimental part is 95 only the added DNSSEC records. The traditional records in the root 96 zone remain unchanged and the new records will only be visible to 97 DNSSEC-aware resolvers. 99 2.1. Motivation for signing the root zone now. 101 The reason DNSSEC is not yet widely deployable is that the problem 102 of key management remains unsolved, especially where communication 103 between the zone administrators for a parent zone and child zone is 104 required. 106 However, during the past year a solution to this problem has been 107 found (in the form of a new record type, DS aka Delegation 108 Signer)[DS], discussed, implemented and tested. Therefore, it is 109 finally reasonable to consider DNSSEC deployment to be a real 110 possibility within the next 12 months. 112 In the case of the root zone the particular importance of managing 113 the transition with zero operational mistakes is a strong reason to 114 separate the signing of the zone itself, with the associated key 115 management issues, from the future management of signed delegations 116 (of top level domains). 118 Although support for Delegation Signer has been implemented and 119 tested it is not yet generally available except experimentally. For 120 this reason signed delegations for productions zones will have to 121 wait a bit longer. Furthermore, it will take some time to ensure 122 that the entire RSS aka Root Server System is capable of supporting 123 the protocol changes that accompany the new support for Delegation 124 Signer. 126 By signing now it will be possible to work through the operational 127 issues with signing the zone itself without at the same time having 128 to manage the additional complexity of signed delegations. Also, by 129 explicitly not supporting any signed delegations, it is also 130 possible to recover in a graceful way should new operational 131 problems turn up. 133 Because of these operational and technical issues there is a 134 "window of opportunity" to sign the root zone before the status of 135 implementation of Delegation Signer support change to "generally 136 available", thereby increasing the pressure for signed delegations. 138 3. Interim signing of the root zone. 140 At present all the authoritative servers for the root zone pull the 141 zone from a primary master. I.e. any changes at the primary master 142 will propagate via NOTIFY[RFC1996] and subsequent 143 AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers. 145 Between the primary master and the slaves transactions are signed 146 with TSIG[RFC2845] signatures. This mechanism is already in place, 147 and there is operational experience with periodic key rollover of 148 the TSIG keys. 150 3.1. Design philosophy. 152 By introducing a signing step into the distribution of the zone 153 file complexity is increased. To avoid introducing new single 154 points of failure it is therefore important to ensure that any 155 added or changed steps are as redundant as possible. 157 The assumption is that the operators of the root servers are 158 trusted and that consistency of the zone among the root servers is 159 a crucial property that MUST be preserved in emergencies. 161 To ensure that consistency is maintained new single points of 162 failure SHOULD NOT be introduced by the signing step. Therefore a 163 structure where several parties have the ability to sign the zone 164 is proposed. Furthermore, such a design helps avoid any individual 165 party becoming a de facto single zone signing authority. 167 3.2. Proposed new management structure for the root zone. 169 Taking into account the already existing infrastructure for 170 management of TSIG keys and rollover of these keys the following 171 structure is proposed: 173 * Day-to-day signing of the root zone is performed by a subgroup of 174 the root server operators. For this task individual operator keys 175 are used. 177 * The set of operator keys are signed by one key-signing key 178 (sometimes referred to as a "master key") at any particular 179 time. The key-signing key in use has to be statically configured 180 in all resolvers that want to be able to perform validation of 181 responses. 183 * Key rollover, the operation when an old key-signing key is 184 exchanged for a new key-signing key, is managed with minimal 185 overlap and on a frequent basis of no less than three times per 186 year. The rollover schedule is chosen to be frequent enough to 187 not make long-term trust possible while being low enough to not 188 become operationally infeasible. 190 3.2.1. Management and distribution of the zone file. 192 The present, unsigned zone is published by the official slaves, the 193 "root nameservers" transferring the zone securely from a primary 194 master and subsequently using the data to respond to queries. This 195 mechanism is changed into: 197 * The unsigned root zone is transferred securely from the primary 198 master to a set of "signing primaries" managed by the operators 199 participating in signing the zone. This is done via the 200 traditional mechanisms NOTIFY + AXFR/IXFR + TSIG. 202 * The root nameservers change their configuration so that they 203 replace the present, single, primary master as the source of the 204 zone with a set of multiple possible "signing primaries" as 205 masters that provide the signed zone. 207 * When a new, unsigned zone, is published by the primary master it 208 will automatically be transferred to the pre-signing servers. The 209 responsible operator will then sign the new zone and publish it 210 from his signing primary. Since the serial number is higher than 211 what the official root nameservers presently have the official 212 root nameservers will all transfer the zone from this source 213 (because of the redundant configuration with multiple possible 214 masters for the signed zone). 216 * The operators that participate in signing rotate the signing 217 responsibility among themselves. Should the responsible operator 218 be unable to do this for any reason then any of the others are 219 able to do the signing instead. Traceability is maintained since 220 the operator keys are individual. 222 * To avoid having several "backup signing operators" possibly sign 223 at exactly the same time backups are allocated "time windows" 224 within which they are allowed to publish a signed zone. 226 With N signers, each signer is assigned a unique number R in 227 [1..N]. 229 T = 2*k*((S-R) mod N) 231 T is time to wait in seconds, S current serial number. The length 232 of the window is k, thereby separating each signing window with 233 an interval where signing is not allowed. 235 The constant k is used to create sufficient separation of the 236 signers with respect to time used to sign and time needed to 237 distribute the zone. A reasonable value for k would be in the 238 order of 1800 seconds. 240 * Because the digital signatures in the signed root zone MUST NOT 241 expire it is necessary to ensure that the unsigned zone does 242 change sufficiently often to cause new signing to occur within 243 the validity period of the old signatures. This is most easily 244 accomplished by a dummy update that only increments the serial 245 number in the SOA record. 247 This new requirement will not cause any operational problems, 248 since in fact the root zone is maintained this way since several 249 years back. 251 3.2.2. Management of the key-signing keys. 253 The key-signing keys are periodically issued by the Regional 254 Internet Registries, RIRs, individually. The RIRs should all 255 perform the task of generating individual key-signing keys and 256 signing the "keyset". However, only one keyset should be included 257 in the signed zone file. 259 The RIRs were chosen on the grounds of 261 * their proven record of service to the Internet community 263 * not having the domain name system as their primary field of 264 activity 266 * their geographical diversity 268 * the fact that they are, by definition, not a single entity, but 269 rather a collective of organizations, thereby alleviating the 270 risk of the "signing authority" sticking in one place. 272 The requirement on the individual RIRs is that they must be able to 274 * establish a secure out-of-band communication path in 275 collaboration with the signing operators which will be used for 276 authenticated exchange of the unsigned keyset. 278 * periodically generate strong keys using a good random number 279 generator 281 * manage their keys (i.e. use them for signing the operator keyset 282 and keeping the private key appropriately secret) 284 Technically the operation of signing the operator keys works by the 285 key-signing key signing the set of keys (i.e. itself plus all the 286 operator keys). The result is called a "signed keyset". 288 3.2.3. Management of the operator keys and the signed "keyset". 290 A subgroup of the root operators that choose to participate in 291 signing the zone each hold an individual "operator key". The 292 subgroup of operators may include all operators, but that is not 293 necessary as long as a sufficient number to achieve redundancy in 294 "signing ability" participates. 296 * The set of operator keys should be sent as a signed, 297 authenticated block of data to all of the RIRs via an out-of-band 298 mechanism. 300 * Each RIR should generate a new signed keyset and send this back 301 to the signing operators via an out-of-band mechanism. 303 * The signing operators should include one of the received signed 304 keysets in the zone file according to an agreed upon rotation 305 schedule. 307 3.2.4. Management of key rollover. 309 The key-signing keys should be short-lived and rolled over 310 frequently. The direct intent is that it should not be possible to 311 put long term trust in the keys. Therefore, by design, every 312 resolver that chooses to configure the key (to be able to validate 313 lookups) will have to change the "trusted key" periodically. 315 This is, after all, only an interim method of root zone signing. 317 * Key rollover is executed by changing from one signed keyset to 318 another. I.e. from a keyset signed by a key-signing key held by 319 one RIR to a keyset signed by a key-signing key held by the next 320 RIR in the chain. 322 * Technically the signing operators are able to initiate key 323 rollover, although except for the case of a suspected key 324 compromise (with subsequent immediate key rollover) this ability 325 should only be used according to an established schedule. 327 * New key-signing keys will be published as widely as possible, 328 however exactly how and where to publish the keys is by itself an 329 area where it is necessary to acquire more experience. Especially 330 for the case of individual hosts and other devices this will be a 331 significant tissue to deal with. 333 * Since the keys expire within a few months the aim is to make it 334 impossible to configure an interim key and then forget about it 335 long enough to still trust an interim key when a long term design 336 for signing the root zone emerges. 338 4. Risk Analysis 340 A change in the management of the root zone is always a risk. But 341 that is all the more reason to do it carefully and after due 342 consideration, rather than as a result of an immediate and urgent 343 need. The gains of a signed root zone have to be judged against the 344 added complexity of the signing step. 346 However, added complexity, in one form or another, is basically 347 unavoidable. It is possible to argue for or against implementation 348 details, but in the end the benefits of a signed root will have to 349 be compared against some amount of added complexity. If the cost or 350 risk of this complexity is deemed to be too high, then it is not 351 possible to sign the DNS root zone. If that is the conclusion; then 352 it is obviously important to reach it as soon as possible. 354 The same is true for the need for operational experience with a 355 signed root zone. There is no method of acquiring this experience 356 except by signing the root zone, so that is what is being proposed. 358 Some identified scenarios: 360 4.1. What will the consequences of a signed root zone be for old 361 resolver software? 363 Nameservers that are authoritative for signed zones only give out 364 these signatures when explicitly asked for them. Therefore, the 365 presence of signatures in the root zone will not have any impact at 366 all on the majority of resolvers on the Internet that does not 367 validate lookups. 369 4.2. What happens if a signing operator fails to sign the zone on 370 time? 372 Literally nothing. I.e. the root zone that is published will be the 373 version prior to the last change. This is not believed to be a 374 major problem, since all changes to the data in the root zone are 375 characterized by long overlaps in time. Furthermore every change is 376 preceded by an administrative process that takes several days. 377 Because of this, a failure to install a new version of the root 378 zone for even so long as a day will not noticeably change the 379 turn-around time for changes in the root zone. 381 4.3. What happens if several signing operators by mistake sign the 382 same version? 384 Literally nothing. One signing operator will be first, according to 385 the mechanism designed to separate the different backup signing 386 operators described in 3.2.1. The signed zone published by this 387 operator will be the version of the signed root zone that all the 388 root nameservers pick up. 390 When the second signing operator signs the zone the serial number 391 in the zone will be unchanged, and therefore the root nameservers 392 will not pick this zone up but instead stay with the first version. 394 4.4. What happens if the unsigned zone is compromised between the 395 primary master and the signing primaries? 397 This is basically the same threat as the zone being compromised 398 between the primary master and the root servers in the traditional 399 unsigned case. To guard against this possibility every zone 400 transfer is already protected by a TSIG signature. 402 Because of this the root zone file cannot get transferred to the 403 signing primaries unless the transaction signature matches, thereby 404 proving that the zone contents are uncompromised. The consequence 405 is that if the zone transfers are somehow compromised in transit, 406 they will not get signed and therefore the published root zone will 407 remain the signed version of the last uncompromised transfer. 409 4.5. What are the security implications for the new "signing 410 primaries"? Will they not have to be as secure as the primary 411 master is now? 413 Yes. However, the entire root server system is based upon trust, 414 i.e. the entire Internet is trusting the present root server system 415 because there is no alternative to doing that. This proposal is not 416 about changing the need for trust in the root server system. It is 417 about providing a method of determining authenticity of data, 418 something that is presently missing. 420 The root operators are already trusted to provide a root server 421 system based upon secure servers lacking validation mechanisms. It 422 is therefore a bit difficult to argue for not trusting them to 423 provide an improved system that adds exactly the lacking validation 424 mechanisms on a basis of not trusting them to secure the servers 425 involved. In both cases trust is involved, the difference is that 426 in the latter case validation is possible. 428 Furthermore, the proposed signing primaries will not need to have 429 publicly known addresses (just as the present primary master is not 430 publicly known), nor will they need to be able to communicate with 431 anyone outside the well defined set of servers that are part of the 432 root server system. Because of this it will be significantly easier 433 to secure the signing primaries than the already present task of 434 securing the DNS root nameservers. 436 4.6. What happens if an operator key is compromised? 438 If this happens it is necessary to do an emergency rollover of the 439 keyset including the compromised key. I.e. a new set of operator 440 keys is generated, the new keyset is signed by the "RIR on duty" 441 using the active key-signing key and then the root zone is 442 re-signed using one of the new operator keys. 444 This problem is not unique to a signed root zone, it is inherent in 445 any activity involving cryptographic keys. 447 4.7. What happens if the key-signing key is compromised? 449 If this happens it is necessary to do an emergency rollover of the 450 keyset including the compromised key and the suggested method is by 451 switching to a keyset signed by a key-signing key issued by the 452 next RIR "in line", i.e. just re-schedule the next planned rollover 453 to take place immediately.. 455 The new signed keyset is added to the root zone and then the zone 456 is re-signed using one of the new operator keys. In this case, 457 since the key-signing key is changed, every resolver will have to 458 configure the new key to be able to validate lookups. 460 This problem is not unique to a signed root zone, it is inherent in 461 any activity involving cryptographic keys. 463 4.8. Does the out-of-band communication between the signing operators 464 and the RIRs holding the key-signing keys add a new failure mode? 466 Yes. The traditional DNSSEC design assumes that (for an arbitrary 467 zone, not particularly for the root zone) the key-signing key is 468 managed by the same entity that manages the operator keys and hence 469 no communication issue exists. 471 In this case it is important that the signing operators do not hold 472 the responsibility for the key-signing keys. The root server 473 operators should only act as a "publishing service" for the root 474 zone contents, not as the entity that verifies correctness of the 475 published data. 477 However, apart from established secure methods of out-of-band 478 communication being available, there is also the very real 479 possibility of managing these exchanges with actual eye-to-eye 480 contact. Representatives for the RIRs and the root server operators 481 already meet on a regular basis during IETF meetings and the 482 different RIR meetings. 484 5. Security Considerations 486 Signing the DNS root zone is all about security. A signed root zone 487 will aid applications and organizations all over the Internet in 488 improving their security. 490 Signing the root zone does add a new management step and therefore 491 it is important to ensure that possible failures in this management 492 step does not leave the published root zone in a state that is 493 actually worse than the original unsigned state. 495 The various failure modes that have been identified all show this 496 property of not being any worse than the unsigned case. 498 There is however one scenario that changes drastically with the 499 proposed distributed signing scheme and that is the consequences of 500 one signing operator intentionally changing the contents of the 501 root zone prior to the actual signing. In the unsigned case this 502 will cause the root zone to become inconsistent (i.e. the responses 503 vary depending upon which server it comes from), while in the 504 signed case the root zone will remain consistent but with erroneous 505 data in it. 507 It is my belief (this is impossible to prove) that the risk of 508 human error among the operators, however small, is still far 509 greater than the risk of willful misconduct. Therefore, the 510 proposed design that enforces consistency among the roots, is 511 actually also an improvement in stability and security. 513 Se further section 4 for a more complete risk analysis. 515 6. IANA Considerations. 517 NONE. 519 7. References 521 7.1. Normative. 523 [RFC2535] Domain Name System Security Extensions. D. Eastlake. 524 March 1999. 526 [RFC3090] DNS Security Extension Clarification on Zone Status. 527 E. Lewis. March 2001. 529 [RFC1995] Incremental Zone Transfer in DNS. M. Ohta. August 1996. 531 [RFC1996] A Mechanism for Prompt Notification of Zone Changes 532 (DNS NOTIFY). P. Vixie. August 1996. 534 [RFC2845] Secret Key Transaction Authentication for DNS (TSIG). 535 P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. 536 May 2000. 538 7.2. Informative. 540 [RFC2930] Secret Key Establishment for DNS (TKEY RR). D. Eastlake. 541 September 2000. 543 [RFC3007] Secure Domain Name System (DNS) Dynamic Update. 544 B. Wellington. November 2000. 546 [RFC3008] Domain Name System Security (DNSSEC) Signing Authority. 547 B. Wellington. November 2000. 549 [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System 550 (DNS). D. Eastlake 3rd. May 2001. 552 [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 553 December 2001. 555 [RFC3226] DNSSEC and IPv6 A6 aware server/resolver message size 556 requirements. O. Gudmundsson. December 2001. 558 [Delegation-Signer] Delegation Signer Resource Record. 559 O. Gudmundsson. October 2002. Work In Progress. 561 [AXFR-clarify] draft-ietf-dnsext-axfr-clarify-NN.txt DNS Zone 562 Transfer Protocol Clarifications. A. Gustafsson. March 563 2002. Work In Progress. 565 [AD-secure] draft-ietf-dnsext-ad-is-secure-NN.txt Redefinition of 566 DNS AD bit. B. Wellington, O Gudmundsson. June 2002. 567 Work In Progress. 569 [Opt-In] draft-ietf-dnsext-dnssec-opt-in-NN.txt DNSSEC Opt-In 570 R. Arends, M Kosters, D. Blacka. June 2002. Work In 571 Progress. 573 [Wild-card-optimize] draft-olaf-dnsext-dnssec-wildcard- 574 optimization-NN.txt DNSSEC Wildcard optimization. 575 O. Kolkman, J. Ihren, R. Arends. September 2002. 576 Work In Progress. 578 8. Acknowledgments. 580 To help me produce this document I have received lots and lots of 581 comments from many people around the Internet with suggestions for 582 lots and lots sorely needed improvements. Among the folks who 583 helped out are, in no particular order: Paul Vixie, Bill Manning, 584 �lafur Gumundsson, Rob Austein, Patrik F�ltstr�m, Olaf Kolkman, 585 Harald Alvestrand, Suzanne Woolf, John M. Brown, Lars-Johan Liman 586 and M�ns Nilsson. 588 9. Authors' Address 590 Johan Ihren 591 Autonomica AB 592 Bellmansgatan 30 593 SE-118 47 Stockholm, Sweden 594 johani@autonomica.se