diff --git a/doc/draft/draft-ietf-dnsext-signing-auth-02.txt b/doc/draft/draft-ietf-dnsext-signing-auth-02.txt deleted file mode 100644 index e80c4fecb0..0000000000 --- a/doc/draft/draft-ietf-dnsext-signing-auth-02.txt +++ /dev/null @@ -1,389 +0,0 @@ -DNSEXT Working Group Brian Wellington (Nominum) -INTERNET-DRAFT October 2000 - - - -Updates: RFC 2535 - - - - Domain Name System Security (DNSSEC) Signing Authority - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Comments should be sent to the authors or the DNSEXT WG mailing list - namedroppers@ops.ietf.org. - - This draft expires on April 2, 2000. - - Copyright Notice - - Copyright (C) The Internet Society (2000). All rights reserved. - - -Abstract - - This document proposes a revised model of Domain Name System Security - (DNSSEC) Signing Authority. The revised model is designed to clarify - earlier documents and add additional restrictions to simplify the - - - -Expires April 2001 [Page 1] - -INTERNET-DRAFT DNSSEC Signing Authority October 2000 - - - secure resolution process. Specifically, this affects the - authorization of keys to sign sets of records. - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in RFC 2119 [RFC2119]. - - -1 - Introduction - -This document defines additional restrictions on DNSSEC signatures (SIG) -records relating to their authority to sign associated data. The intent -is to establish a standard policy followed by a secure resolver; this -policy can be augmented by local rules. This builds upon [RFC2535], -updating section 2.3.6 of that document. - -The most significant change is that in a secure zone, zone data is -required to be signed by the zone key. - -Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security -extensions [RFC2535] is assumed. - -2 - The SIG Record - -A SIG record is normally associated with an RRset, and ``covers'' (that -is, demonstrates the authenticity and integrity of) the RRset. This is -referred to as a ``data SIG''. Note that there can be multiple SIG -records covering an RRset, and the same validation process should be -repeated for each of them. Some data SIGs are considered ``material'', -that is, relevant to a DNSSEC capable resolver, and some are -``immaterial'' or ``extra-DNSSEC'', as they are not relevant to DNSSEC -validation. Immaterial SIGs may have application defined roles. SIG -records may exist which are not bound to any RRset; these are also -considered immaterial. The validation process determines which SIGs are -material; once a SIG is shown to be immaterial, no other validation is -necessary. - -SIGs may also be used for transaction security. In this case, a SIG -record with a type covered field of 0 is attached to a message, and is -used to protect message integrity. This is referred to as a SIG(0) -[RFC2535, RFC2931]. - -The following sections define requirements for all of the fields of a -SIG record. These requirements MUST be met in order for a DNSSEC -capable resolver to process this signature. If any of these -requirements are not met, the SIG cannot be further processed. -Additionally, once a KEY has been identified as having generated this -SIG, there are requirements that it MUST meet. - - - -Expires April 2001 [Page 2] - -INTERNET-DRAFT DNSSEC Signing Authority October 2000 - - -2.1 - Type Covered - -For a data SIG, the type covered MUST be the same as the type of data in -the associated RRset. For a SIG(0), the type covered MUST be 0. - - -2.2 - Algorithm Number - -The algorithm specified in a SIG MUST be recognized by the client, and -it MUST be an algorithm that has a defined SIG rdata format. - - -2.3 - Labels - -The labels count MUST be less than or equal to the number of labels in -the SIG owner name, as specified in [RFC2535, section 4.1.3]. - - -2.4 - Original TTL - -The original TTL MUST be greater than or equal to the TTL of the SIG -record itself, since the TTL cannot be increased by intermediate -servers. This field can be ignored for SIG(0) records. - - -2.5 - Signature Expiration and Inception - -The current time at the time of validation MUST lie within the validity -period bounded by the inception and expiration times. - - -2.6 - Key Tag - -There are no restrictions on the Key Tag field, although it is possible -that future algorithms will impose contraints. - - -2.7 - Signer's Name - -The signer's name field of a data SIG MUST contain the name of the zone -to which the data and signature belong. The combination of signer's -name, key tag, and algorithm MUST identify a zone key if the SIG is to -be considered material. The only exception that the signer's name field -in a SIG KEY at a zone apex SHOULD contain the parent zone's name, -unless the KEY set is self-signed. This document defines a standard -policy for DNSSEC validation; local policy may override the standard -policy. - - - - -Expires April 2001 [Page 3] - -INTERNET-DRAFT DNSSEC Signing Authority October 2000 - - -There are no restrictions on the signer field of a SIG(0) record. The -combination of signer's name, key tag, and algorithm MUST identify a key -if this SIG(0) is to be processed. - - -2.8 - Signature - -There are no restrictions on the signature field. The signature will be -verified at some point, but does not need to be examined prior to -verification unless a future algorithm imposes constraints. - -3 - The Signing KEY Record - -Once a signature has been examined and its fields validated (but before -the signature has been verified), the resolver attempts to locate a KEY -that matches the signer name, key tag, and algorithm fields in the SIG. -If one is not found, the SIG cannot be verified and is considered -immaterial. If KEYs are found, several fields of the KEY record MUST -have specific values if the SIG is to be considered material and -authorized. If there are multiple KEYs, the following checks are -performed on all of them, as there is no way to determine which one -generated the signature until the verification is performed. - - -3.1 - Type Flags - -The signing KEY record MUST have a flags value of 00 or 01 -(authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A -DNSSEC resolver MUST only trust signatures generated by keys that are -permitted to authenticate data. - - -3.2 - Name Flags - -The interpretation of this field is considerably different for data SIGs -and SIG(0) records. - - -3.2.1 - Data SIG - -If the SIG record covers an RRset, the name type of the associated KEY -MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section -2.3.6. The DNSSEC validation process performed by a resolver MUST -ignore all keys that are not zone keys unless local policy dictates -otherwise. - -The primary reason that RFC 2535 allows host and user keys to generate -material DNSSEC signatures is to allow dynamic update without online - - - -Expires April 2001 [Page 4] - -INTERNET-DRAFT DNSSEC Signing Authority October 2000 - - -zone keys; that is, avoid storing private keys in an online server. The -desire to avoid online signing keys cannot be achieved, though, because -they are necessary to sign NXT and SOA sets [SSU]. These online zone -keys can sign any incoming data. Removing the goal of having no online -keys removes the reason to allow host and user keys to generate material -signatures. - -Limiting material signatures to zone keys simplifies the validation -process. The length of the verification chain is bounded by the name's -label depth. The authority of a key is clearly defined; a resolver does -not need to make a potentially complicated decision to determine whether -a key can sign data. amount of work to determine if all such keys have -the proper authority. - -Finally, there is no additional flexibility granted by allowing -host/user key generated material signatures. As long as users and hosts -have the ability to authenticate update requests to the primary zone -server, signatures by zone keys are sufficient to protect the integrity -of the data to the world at large. - - -3.2.2 - SIG(0) - -If the SIG record is a SIG(0) protecting a message, the name type of the -associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions -are initiated by a host or user, not a zone, so zone keys SHOULD not -generate SIG(0) records. - -A client is either explicitly executed by a user or on behalf of a host, -therefore the name type of a SIG(0) generated by a client SHOULD be -either user or host. A nameserver is associated with a host, and its -use of SIG(0) is not associated with a particular zone, so the name type -of a SIG(0) generated by a nameserver SHOULD be host. - - -3.3 - Signatory Flags - -This document does not assign any values to the signatory field, nor -require any values to be present. - - -3.4 - Protocol - -The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 -(ALL). If a key is not specified for use with DNSSEC, a DNSSEC resolver -MUST NOT trust any signature that it generates. - - - - - -Expires April 2001 [Page 5] - -INTERNET-DRAFT DNSSEC Signing Authority October 2000 - - -3.5 - Algorithm Number - -The algorithm field MUST be identical to that of the generated SIG -record, and MUST meet all requirements for an algorithm value in a SIG -record. - -4 - Security considerations - -This document defines a standard baseline for a DNSSEC capable resolver. -This is necessary for a thorough security analysis of DNSSEC, if one is -to be done. - -Specifically, this document places additional restrictions on SIG -records that a resolver must validate before the signature can be -considered worthy of DNSSEC trust. This simplifies the protocol, making -it more robust and able to withstand scrutiny by the security community. - - -5 - Acknowledgements - -The author would like to thank the following people for review and -informative comments (in alphabetical order): - - Olafur Gudmundsson - Ed Lewis - - -6 - References - -[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' - RFC 1034, ISI, November 1987. - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, ISI, November 1987. - -[RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate - Requirement Levels,'' BCP 14, RFC 2119, Harvard, March 1997. - -[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic - Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore - & Cisco & DEC, April 1997. - -[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC - 2535, IBM, March 1999. - -[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures ( - SIG(0)s ),'' RFC 2931, Motorola, September 2000. - - - - -Expires April 2001 [Page 6] - -INTERNET-DRAFT DNSSEC Signing Authority October 2000 - - -[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS) - Dynamic Update,'' draft-ietf-dnsext-simple-secure- - update-02.txt, Nominum, October 2000. - -7 - Author's Address - - - Brian Wellington - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 6022 - - - -8 - Full Copyright Statement - -Copyright (C) The Internet Society (2000). All Rights Reserved. - -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it or -assist in its implmentation may be prepared, copied, published and -distributed, in whole or in part, without restriction of any kind, -provided that the above copyright notice and this paragraph are included -on all such copies and derivative works. However, this document itself -may not be modified in any way, such as by removing the copyright notice -or references to the Internet Society or other Internet organizations, -except as needed for the purpose of developing Internet standards in -which case the procedures for copyrights defined in the Internet -Standards process must be followed, or as required to translate it into -languages other than English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an "AS -IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK -FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT -LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT -INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR -FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - -Expires April 2001 [Page 7] - diff --git a/doc/draft/draft-ietf-dnsext-simple-secure-update-02.txt b/doc/draft/draft-ietf-dnsext-simple-secure-update-02.txt deleted file mode 100644 index eba65663bb..0000000000 --- a/doc/draft/draft-ietf-dnsext-simple-secure-update-02.txt +++ /dev/null @@ -1,501 +0,0 @@ -DNSEXT Working Group Brian Wellington (Nominum) -INTERNET-DRAFT October 2000 - - - -Updates: RFC 2535, RFC 2136 -Replaces: RFC 2137 - - - - Secure Domain Name System (DNS) Dynamic Update - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Comments should be sent to the authors or the DNSEXT WG mailing list - namedroppers@ops.ietf.org. - - This draft expires on April 2, 2000. - - Copyright Notice - - Copyright (C) The Internet Society (2000). All rights reserved. - - -Abstract - - This document proposes a method for performing secure Domain Name - System (DNS) dynamic updates. The method described here is intended - - - -Expires April 2001 [Page 1] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - - to be flexible and useful while requiring as few changes to the - protocol as possible. The authentication of the dynamic update - message is separate from later DNSSEC validation of the data. Secure - communication based on authenticated requests and transactions is - used to provide authorization. - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in RFC 2119 [RFC2119]. - - -1 - Introduction - -This document defines a means to secure dynamic updates of the Domain -Name System (DNS), allowing only authorized sources to make changes to a -zone's contents. The existing unsecured dynamic update operations form -the basis for this work. - -Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update -[RFC2136] is helpful and is assumed by this document. In addition, -knowledge of DNS security extensions [RFC2535], SIG(0) transaction -security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] is -recommended. - -This document updates portions of RFC 2535, in particular section 3.1.2, -and RFC 2136. This document obsoletes RFC 2137, an alternate proposal -for secure dynamic update, due to implementation experience. - -1.1 - Overview of DNS Dynamic Update - -DNS dynamic update defines a new DNS opcode and a new interpretation of -the DNS message if that opcode is used. An update can specify -insertions or deletions of data, along with prerequisites necessary for -the updates to occur. All tests and changes for a DNS update request -are restricted to a single zone, and are performed at the primary server -for the zone. The primary server for a dynamic zone must increment the -zone SOA serial number when an update occurs or before the next -retrieval of the SOA. - -1.2 - Overview of DNS Transaction Security - -Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0) -[RFC2535, RFC2931] records allow two DNS entities to authenticate DNS -requests and responses sent between them. A TSIG MAC (message -authentication code) is derived from a shared secret, and a SIG(0) is -generated from a private key whose public counterpart is stored in DNS. -In both cases, a record containing the message signature/MAC is included -as the final resource record in a DNS message. Keyed hashes, used in - - - -Expires April 2001 [Page 2] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - -TSIG, are inexpensive to calculate and verify. Public key encryption, -as used in SIG(0), is more scalable as the public keys are stored in -DNS. - -1.3 - Comparison of data authentication and message authentication - -Message based authentication, using TSIG or SIG(0), provides protection -for the entire message with a single signing and single verification -which, in the case of TSIG, is a relatively inexpensive MAC creation and -check. For update requests, this signature can establish, based on -policy or key negotation, the authority to make the request. - -DNSSEC SIG records can be used to protect the integrity of individual -RRs or RRsets in a DNS message with the authority of the zone owner. -However, this cannot sufficiently protect the dynamic update request. - -Using SIG records to secure RRsets in an update request is incompatible -with the design of update, as described below, and would in any case -require multiple expensive public key signatures and verifcations. - -SIG records do not cover the message header, which includes record -counts. Therefore, it is possibly to maliciously insert or remove -RRsets in an update request without causing a verification failure. - -If SIG records were used to protect the prerequisite section, it would -be impossible to determine whether the SIGs themselves were a -prerequisite or simply used for validation. - -In the update section of an update request, signing requests to add an -RRset is straightforward, and this signature could be permanently used -to protect the data, as specified in [RFC2535]. However, if an RRset is -deleted, there is no data for a SIG to cover. - -1.4 - Data and message signatures - -As specified in [signing-auth], the DNSSEC validation process performed -by a resolver MUST NOT process any non-zone keys unless local policy -dictates otherwise. When performing secure dynamic update, all zone -data modified in a signed zone MUST be signed by a relevant zone key. -This completely disassociates authentication of an update request from -authentication of the data itself. - -The primary usefulness of host and user keys, with respect to DNSSEC, is -to authenticate messages, including dynamic updates. Thus, host and -user keys MAY be used to generate SIG(0) records to authenticate updates -and MAY be used in the TKEY [RFC2930] process to generate TSIG shared -secrets. In both cases, no SIG records generated by non-zone keys will -be used in a DNSSEC validation process unless local policy dictates. - - - -Expires April 2001 [Page 3] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - -Authentication of data, once it is present in DNS, only involves DNSSEC -zone keys and signatures generated by them. - -1.5 - Signatory strength - -[RFC2535, section 3.1.2] defines the signatory field of a key as the -final 4 bits of the flags field, but does not define its value. This -proposal leaves this field undefined. Updating [RFC2535], this field -SHOULD be set to 0 in KEY records, and MUST be ignored. - -2 - Authentication - -TSIG or SIG(0) records MUST be included in all secure dynamic update -messages. This allows the server to verifiably determine the originator -of a message. If the message contains authentication in the form of a -SIG(0), the identity of the sender (that is, the principal) is the owner -of the KEY RR that generated the SIG(0). If the message contains a TSIG -generated by a statically configured shared secret, the principal is the -same as or derived from the shared secret name. If the message contains -a TSIG generated by a dynamically configured shared secret, the -principal is the same as the one that authenticated the TKEY process; if -the TKEY process was unauthenticated, no information is known about the -principal, and the associated TSIG shared secret MUST NOT be used for -secure dynamic update. - -SIG(0) signatures SHOULD NOT be generated by zone keys, since -transactions are initiated by a host or user, not a zone. - -DNSSEC SIG records (other than SIG(0)) MAY be included in an update -message, but MUST NOT be used to authenticate the update request. - -If an update fails because it is signed with an unauthorized key, the -server MUST indicate failure by returning a message with RCODE REFUSED. -Other TSIG, SIG(0), or dynamic update errors are returned as specified -in the appropriate protocol description. - - - - - - - - - - - - - - - - -Expires April 2001 [Page 4] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - -3 - Policy - -All policy is configured by the zone administrator and enforced by the -zone's primary name server. Policy dictates the authorized actions that -an authenticated principal can take. Policy checks are based on the -principal and the desired action, where the principal is derived from -the message signing key and applied to dynamic update messages signed -with that key. - -The server's policy defines criteria which determine if the key used to -sign the update is permitted to perform the requested updates. By -default, a principal MUST NOT be permitted to make any changes to zone -data; any permissions MUST be enabled though configuration. - -The policy is fully implemented in the primary zone server's -configuration for several reasons. This removes limitations imposed by -encoding policy into a fixed number of bits (such as the KEY RR's -signatory field). Policy is only relevant in the server applying it, so -there is no reason to expose it. Finally, a change in policy or a new -type of policy should not affect the DNS protocol or data format, and -should not cause interoperability failures. - -3.1 - Standard policies - -Implementations SHOULD allow access control policies to use the -principal as an authorization token, and MAY also allow policies to -grant permission to a signed message regardless of principal. - -A common practice would be to restrict the permissions of a principal by -domain name. That is, a principal could be permitted to add, delete, or -modify entries corresponding to one or more domain names. -Implementations SHOULD allow per-name access control, and SHOULD provide -a concise representation of the principal's own name, its subdomains, -and all names in the zone. - -Additionally, a server SHOULD restrict updates by RR type, so that a -principal could add, delete, or modify specific record types at certain -names. Implementations SHOULD allow per-type access control, and SHOULD -provide concise representations of all types and all ``user'' types, -where a user type is defined as one that does not affect the operation - - - - - - - - - - - -Expires April 2001 [Page 5] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - -of DNS itself. - -3.1.1 - User types - -User types include all data types except SOA, NS, SIG, and NXT. SOA and -NS SHOULD NOT be modified by normal users, since these types create or -modify delegation points. The addition of SIG records can lead to -attacks resulting in additional workload for resolvers, and the deletion -of SIG records could lead to extra work for the server if the zone SIG -was deleted. Note that these records are not forbidden, but not -recommended for normal users. - -NXT records MUST NOT be created, modified, or deleted by dynamic update, -as their update may cause instability in the protocol. This is an -update to RFC 2136. - -Issues concerning updates of KEY records are discussed in the Security -Considerations section. - -3.2 - Additional policies - -Users are free to implement any policies. Policies may be as specific -or general as desired, and as complex as desired. They may depend on -the principal or any other characteristics of the signed message. - -4 - Interaction with DNSSEC - -Although this protocol does not change the way updates to secure zones -are processed, there are a number of issues that should be clarified. - -4.1 - Adding SIGs -An authorized update request MAY include SIG records with each RRset. -Since SIG records (except SIG(0) records) MUST NOT be used for -authentication of the update message, they are not required. - -If a principal is authorized to update SIG records and there are SIG -records in the update, the SIG records are added without verification. -The server MAY examine SIG records and drop SIGs with a temporal -validity period in the past. - -4.2 - Deleting SIGs - -If a principal is authorized to update SIG records and the update -specifies the deletion of SIG records, the server MAY choose to override -the authority and refuse the update. For example, the server may allow - - - - - - -Expires April 2001 [Page 6] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - -all SIG records not generated by a zone key to be deleted. - -4.3 - Non-explicit updates to SIGs - -If the updated zone is secured, the RRset affected by an update -operation MUST, at the completion of the update, be signed in accordance -with the zone's signing policy. This will usually require one or more -SIG records to be generated by one or more zone keys whose private -components MUST be online [signing-auth]. - -When the contents of an RRset are updated, the server MAY delete all -associated SIG records, since they will no longer be valid. - -4.4 - Effects on the zone - -If any changes are made, the server MUST, if necessary, generate a new -SOA record and new NXT records, and sign these with the appropriate zone -keys. Changes to NXT records by secure dynamic update are explicitly -forbidden. SOA updates are allowed, since the maintenance of SOA -parameters is outside of the scope of the DNS protocol. - -5 - Security considerations - -This document requires that a zone key and possibly other cryptographic -secret material be held in an on-line, network-connected host, most -likely a name server. This material is at the mercy of host security to -remain a secret. Exposing this secret puts DNS data at risk of -masquerade attacks. The data at risk is that in both zones served by -the machine and delegated from this machine. - -Allowing updates of KEY records may lead to undesirable results, since a -principal may be allowed to insert a public key without holding the -private key, and possibly masquerade as the key owner. - -6 - Acknowledgements - -The author would like to thank the following people for review and -informative comments (in alphabetical order): - - Harald Alvestrand - Donald Eastlake - Olafur Gudmundsson - Andreas Gustafsson - Bob Halley - Stuart Kwan - Ed Lewis - - - - - -Expires April 2001 [Page 7] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - -7 - References - -[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' - RFC 1034, ISI, November 1987. - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, ISI, November 1987. - -[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic - Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore - & Cisco & DEC, April 1997. - -[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC - 2137, CyberCash, April 1997. - -[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC - 2535, IBM, March 1999. - -[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington ``Secret - Key Transaction Signatures for DNS (TSIG),'' RFC 2845, ISC & - NAILabs & Motorola & Nominum, May 2000. - -[RFC2930] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),'' - RFC 2930, Motorola, September 2000. - -[RFC2931] D. Eastlake ``DNS Request and Transaction Signatures ( - SIG(0)s ),'' RFC 2931, Motorola, September 2000. - -[signing-auth] - B. Wellington ``Domain Name System Security (DNSSEC) Signing - Authority,'' draft-ietf-dnsext-signing-auth-02.txt, Nominum, - October 2000. - - - - - - - - - - - - - - - - - - - -Expires April 2001 [Page 8] - -INTERNET-DRAFT Secure Dynamic Update October 2000 - - -8 - Author's Address - - - Brian Wellington - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 6022 - - - -9 - Full Copyright Statement - -Copyright (C) The Internet Society (2000). All Rights Reserved. - -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it or -assist in its implmentation may be prepared, copied, published and -distributed, in whole or in part, without restriction of any kind, -provided that the above copyright notice and this paragraph are included -on all such copies and derivative works. However, this document itself -may not be modified in any way, such as by removing the copyright notice -or references to the Internet Society or other Internet organizations, -except as needed for the purpose of developing Internet standards in -which case the procedures for copyrights defined in the Internet -Standards process must be followed, or as required to translate it into -languages other than English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an "AS -IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK -FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT -LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT -INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR -FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - - - - - -Expires April 2001 [Page 9] -