From: Andreas Gustafsson Date: Tue, 17 Oct 2000 01:24:05 +0000 (+0000) Subject: updated drafts X-Git-Tag: v9.0.1^4~20 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=d8b60149a58439aa2fc68e0f501a11f40d3b3645;p=thirdparty%2Fbind9.git updated drafts --- diff --git a/doc/draft/draft-ietf-dnsext-message-size-00.txt b/doc/draft/draft-ietf-dnsext-message-size-01.txt similarity index 64% rename from doc/draft/draft-ietf-dnsext-message-size-00.txt rename to doc/draft/draft-ietf-dnsext-message-size-01.txt index 2a276d010d2..d0948dcfdcb 100644 --- a/doc/draft/draft-ietf-dnsext-message-size-00.txt +++ b/doc/draft/draft-ietf-dnsext-message-size-01.txt @@ -5,11 +5,11 @@ DNSEXT Working Group Olafur Gudmundsson (NAI Labs) -INTERNET-DRAFT June 2000 +INTERNET-DRAFT October 2000 - + -Updates: RFC 2535 +Updates: RFC 2535, RFC 2874 @@ -40,7 +40,7 @@ Status of this Memo Comments should be sent to the authors or the DNSEXT WG mailing list namedroppers@ops.ietf.org - This draft expires on December 29, 2000. + This draft expires on March 29, 2001. Copyright Notice @@ -55,9 +55,9 @@ Status of this Memo -Expires December 2000 [Page 1] +Expires March 2001 [Page 1] -INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 +INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 Abstract @@ -65,7 +65,7 @@ Abstract This document mandates support for EDNS0 in DNS entities claiming to support DNS Security Extensions and A6 records. This requirement is necessary because these new features increase the size of DNS - messages. If EDNS0 is not supported fallback to TCP will happen, + messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. @@ -73,8 +73,8 @@ Abstract 1 - Introduction - Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions - [RFC2535], EDNS0[RFC2671] and A6 [RFCA6] is helpful. + Familiarity with the DNS[RFC1034, RFC1035], DNS Security + Extensions[RFC2535], EDNS0[RFC2671] and A6[RFC2874] is helpful. RFC 1035[RFC1035] Section 2.3.4 requires that DNS messages over UDP have a data payload of 512 octets or less. Most DNS software today @@ -88,13 +88,16 @@ Abstract Compared to UDP, TCP is an expensive protocol to use for a simple transaction like DNS: a TCP connection requires 5 packets for setup - and teardown, excluding data packets, thus requiring at least 3 + and tear down, excluding data packets, thus requiring at least 3 round trips on top of the one for the original UDP query. The DNS server also needs to keep a state of the connection during this transaction. As many DNS servers answer thousands of queries per second, requiring them to use TCP will cause significant overhead and delays. + +1.1 - DNSSEC motivations + DNSSEC[RFC2535] secures DNS by adding a Public Key signature on each RR set. These signatures range in size from about 80 octets to 800 octets most are going to be in the range of 80..200 octets. The @@ -102,30 +105,40 @@ Abstract will significantly increase the size of DNS answers from secure zones. + It is important that security aware servers and resolvers get all the + data in Answer and Authority section in one query without truncation. + In some cases it is important that some Additional Data be sent + + + +Expires March 2001 [Page 2] + +INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 + + + along, mainly in delegation cases. TSIG[RFC2845] allows for the light weight authentication of DNS messages, but increases the size of the messages by at least 70 octets. DNSSEC allows for computationally expensive message authentication with a standard public key signature. As only one TSIG or SIG(0) can be attached to each DNS answer the size increase of + message authentication is not significant, but may still lead to a + truncation. +1.2 - IPv6 Motivations -Expires December 2000 [Page 2] - -INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 - - - message authentication is not significant. - - - IPv6 addresses[A6] are 128 bits and are represented in the DNS by - multiple A6 records, each consisting of a domain name and a bit + IPv6 addresses[RFC2874] are 128 bits and are represented in the DNS + by multiple A6 records, each consisting of a domain name and a bit field. The domain name refers to an address prefix that may require additional A6 RRs to be included in the answer. Answers where queried name has multiple A6 addresses may overflow a 512-octet UDP packet size. + +1.3 Root server and TLD server motivations + The current number of root servers is limited to 13 as that is the maximum number of name servers and their address records that fit in one 512-octet DNS message. If root servers start advertising A6 or @@ -133,17 +146,50 @@ INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 an single 512-octet DNS message. Resulting in a large number of TCP connections to the root servers. + It is important that a high level domains have a high number of + domain name servers for redundancy, latency and load balancing + reasons. + + +1.4 UDP vs TCP for DNS messages + Given all these factors, it is essential that any implementations that supports DNSSEC and or A6 be able to use larger DNS messages than 512 octets. + The original 512 restriction was put in place to avoid fragmentation + of DNS responses. A fragmented UDP message that suffers a loss off + one of the fragments renders the answer useless and DNS must + retransmit the query. TCP connection requires number of round trips + for establishment, data transfer and tear down, but only the lost + data segments are retransmitted. + + + + +Expires March 2001 [Page 3] + +INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 + + + In the early days number of IP implementations did not handle + fragmentation well, but all modern operating systems have overcome + that issue thus sending fragmented messages is fine from that + standpoint. The open issue is the effect of losses on fragmented + messages. If connection has high loss ratio only TCP will allow + reliable transfer of DNS data, most links have low loss ratios thus + sending fragmented UDP packet in one round trip is better than + establishing a TCP connection to transfer few thousand octets. + + +1.5 EDNS0 and large UDP messages + EDNS0[RFC2671] allows clients to declare the maximum size of UDP message they are willing to handle. Thus, if the expected answer is between 512 octets and the maximum size that the client can accept, the additional overhead of a TCP connection can be avoided. - -1.2 - Requirements +1.7 - Requirements The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119. @@ -151,14 +197,24 @@ INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 2 - Protocol changes: - This document updates [RFC2535] and [A6]. + This document updates [RFC2535] and [RFC2874], by adding new + requirements. All RFC2535-compliant servers and resolvers MUST support EDNS0 and - advertise message size of at least 1280 octets. + advertise message size of at least 1220 octets, but SHOULD advertise + message size of 4000. This value might be too low to get full + answers for high level servers and successor of this document may + require a larger value. + + All RFC2874-compliant servers and resolver MUST support EDNS0 and + advertise message size of at least 1024 octets, but SHOULD advertise + message size of 2048. - All [A6] compliant servers and resolver MUST support EDNS0 and - advertise message size of at least 1280 octets. + All RFC2535 and RFC2874 compliant entities MUST be able to handle + fragmented IP and IPv6 UDP packets. + All hosts supporting both RFC2535 and RFC2874 MUST use the larger + required value in EDNS0 advertisements. @@ -167,16 +223,16 @@ INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 -Expires December 2000 [Page 3] +Expires March 2001 [Page 4] -INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 +INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 3 Acknowledgments Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas - Gustafsson, Bob Halley and Edward Lewis where instrumental in - motivating and shaping this document. + Gustafsson, Bob Halley, Edward Lewis and Kazu Yamamoto where + instrumental in motivating and shaping this document. 4 - Security Considerations: @@ -188,10 +244,12 @@ INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 None - References: +[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities'' + STD 13, RFC 1034, November 1987. + [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification'', STD 13, RFC 1035, November 1987. @@ -209,8 +267,8 @@ References: 2845, May 2000. -[A6] M. Crawford, C. Huitema, S. Thompson, ``DNS Extensions to - Support IPv6 Address Aggregation and Renumbering'', RFCxxx, +[RFC2874] M. Crawford, C. Huitema, S. Thompson, ``DNS Extensions to + Support IPv6 Address Aggregation and Renumbering'', RFC2874, Sometime 2000. @@ -221,11 +279,9 @@ References: - - -Expires December 2000 [Page 4] +Expires March 2001 [Page 5] -INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000 +INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000 Author Address @@ -279,4 +335,4 @@ Full Copyright Statement -Expires December 2000 [Page 5] +Expires March 2001 [Page 6] diff --git a/doc/draft/draft-ietf-dnsext-signing-auth-01.txt b/doc/draft/draft-ietf-dnsext-signing-auth-02.txt similarity index 84% rename from doc/draft/draft-ietf-dnsext-signing-auth-01.txt rename to doc/draft/draft-ietf-dnsext-signing-auth-02.txt index 9fbe1497a33..e80c4fecb0c 100644 --- a/doc/draft/draft-ietf-dnsext-signing-auth-01.txt +++ b/doc/draft/draft-ietf-dnsext-signing-auth-02.txt @@ -1,8 +1,7 @@ +DNSEXT Working Group Brian Wellington (Nominum) +INTERNET-DRAFT October 2000 -DNSIND Working Group Brian Wellington (Nominum) -INTERNET-DRAFT May 2000 - - + Updates: RFC 2535 @@ -32,10 +31,10 @@ Status of this Memo 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 DNSIND WG mailing list - namedroppers@internic.net. + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org. - This draft expires on November 12, 2000. + This draft expires on April 2, 2000. Copyright Notice @@ -50,14 +49,18 @@ Abstract -Expires November 2000 [Page 1] +Expires April 2001 [Page 1] -INTERNET-DRAFT DNSSEC Signing Authority May 2000 +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 @@ -91,7 +94,7 @@ 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]. +[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 @@ -102,13 +105,9 @@ SIG, there are requirements that it MUST meet. - - - - -Expires November 2000 [Page 2] +Expires April 2001 [Page 2] -INTERNET-DRAFT DNSSEC Signing Authority May 2000 +INTERNET-DRAFT DNSSEC Signing Authority October 2000 2.1 - Type Covered @@ -153,18 +152,23 @@ that future algorithms will impose contraints. 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. This document defines a standard policy for -DNSSEC validation; local policy may override the standard policy. +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. -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. -Expires November 2000 [Page 3] +Expires April 2001 [Page 3] -INTERNET-DRAFT DNSSEC Signing Authority May 2000 +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 @@ -210,20 +214,20 @@ otherwise. The primary reason that RFC 2535 allows host and user keys to generate material DNSSEC signatures is to allow dynamic update without online -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 -Expires November 2000 [Page 4] +Expires April 2001 [Page 4] -INTERNET-DRAFT DNSSEC Signing Authority May 2000 +INTERNET-DRAFT DNSSEC Signing Authority October 2000 -signatures. in the DNS. +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 @@ -266,19 +270,20 @@ The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 MUST NOT trust any signature that it generates. -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. -Expires November 2000 [Page 5] +Expires April 2001 [Page 5] -INTERNET-DRAFT DNSSEC Signing Authority May 2000 +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. @@ -308,33 +313,31 @@ informative comments (in alphabetical order): [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 - 2065, IBM, March 1999. - -[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS) - Dynamic Update,'' draft-ietf-dnsext-simple-secure- - update-01.txt, Nominum, May 2000. - + 2535, IBM, March 1999. +[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures ( + SIG(0)s ),'' RFC 2931, Motorola, September 2000. - - - - - - -Expires November 2000 [Page 6] +Expires April 2001 [Page 6] -INTERNET-DRAFT DNSSEC Signing Authority May 2000 +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 @@ -382,9 +385,5 @@ FITNESS FOR A PARTICULAR PURPOSE." - - - - -Expires November 2000 [Page 7] +Expires April 2001 [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt b/doc/draft/draft-ietf-dnsext-simple-secure-update-02.txt similarity index 72% rename from doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt rename to doc/draft/draft-ietf-dnsext-simple-secure-update-02.txt index 1034426ab99..eba65663bb7 100644 --- a/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt +++ b/doc/draft/draft-ietf-dnsext-simple-secure-update-02.txt @@ -1,10 +1,10 @@ -DNSIND Working Group Brian Wellington (NAILabs) -INTERNET-DRAFT May 2000 +DNSEXT Working Group Brian Wellington (Nominum) +INTERNET-DRAFT October 2000 - + -Updates: RFC 2535, RFC 2136, -Replaces: RFC 2137, [update2] +Updates: RFC 2535, RFC 2136 +Replaces: RFC 2137 @@ -32,10 +32,10 @@ Status of this Memo 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 DNSIND WG mailing list - namedroppers@internic.net. + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org. - This draft expires on November 12, 2000. + This draft expires on April 2, 2000. Copyright Notice @@ -49,9 +49,9 @@ Abstract -Expires November 2000 [Page 1] +Expires April 2001 [Page 1] -INTERNET-DRAFT Secure Dynamic Update May 2000 +INTERNET-DRAFT Secure Dynamic Update October 2000 to be flexible and useful while requiring as few changes to the @@ -60,6 +60,10 @@ INTERNET-DRAFT Secure Dynamic Update May 2000 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 @@ -71,12 +75,12 @@ 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], and TSIG transaction security [TSIG] is recommended. - -This document updates portions of RFC 2535, in particular section 3.1.2. -This document obsoletes RFC 2137, an alternate proposal for secure -dynamic update, due to implementation experience. +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 @@ -89,27 +93,27 @@ 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 [TSIG] or SIG(0) [RFC2535] -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 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. - +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 November 2000 [Page 2] +Expires April 2001 [Page 2] -INTERNET-DRAFT Secure Dynamic Update May 2000 +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 @@ -139,7 +143,6 @@ 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 @@ -152,19 +155,19 @@ 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 [TKEY] process to generate TSIG shared +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. -Authentication of data, once it is present in DNS, only involves DNSSEC -zone keys and signatures generated by them. - -Expires November 2000 [Page 3] +Expires April 2001 [Page 3] -INTERNET-DRAFT Secure Dynamic Update May 2000 +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 @@ -199,6 +202,26 @@ 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 @@ -213,15 +236,6 @@ 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. - - - - -Expires November 2000 [Page 4] - -INTERNET-DRAFT Secure Dynamic Update May 2000 - - 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 @@ -230,7 +244,6 @@ 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 @@ -249,9 +262,24 @@ 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 -of DNS itself. + + + + + + + + + +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 @@ -269,15 +297,6 @@ update to RFC 2136. Issues concerning updates of KEY records are discussed in the Security Considerations section. - - - - -Expires November 2000 [Page 5] - -INTERNET-DRAFT Secure Dynamic Update May 2000 - - 3.2 - Additional policies Users are free to implement any policies. Policies may be as specific @@ -286,53 +305,55 @@ 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 the -updated zone is secured, the data affected by an update operation MUST -be secured by one or more SIG records. For each RRset, if the update -includes a valid signature by a zone key, this signature SHOULD be -reused. Otherwise, the server MUST generate SIG records with one or -more zone keys (of which the private components MUST be online). If -multiple zone keys are online and an RRset requires a signature, a SIG -MUST be generated by at least one of the zone keys. +authentication of the update message, they are not required. -If a principal is authorized to add SIG records and there are SIG -records in the request, the following rules are applied. If the SIG was -generated by a zone key for the relevant zone, verification is attempted -(the public key must be available if the determination that it is a zone -key was made). If successful, the SIG is retained; otherwise, the SIG -is dropped. Otherwise, the SIG is retained without verification, since -it is considered immaterial to the DNSSEC validation process. The -server MAY examine SIG records and drop SIGs with a temporal validity -period in the past. At the completion of the update process, each -updated RRset must be signed in accordance with the zone's signing -policy; the SIGs must either be included in the update or generated by -the server. - -The server MUST also, if necessary, generate a new SOA record and new -NXT records, and sign these with the appropriate zone keys. NXT records -are explicitly forbidden. SOA updates are allowed, since the -maintenance of SOA parameters is outside of the scope of the DNS -protocol. +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. -Expires November 2000 [Page 6] - -INTERNET-DRAFT Secure Dynamic Update May 2000 +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 @@ -352,6 +373,7 @@ private key, and possibly masquerade as the key owner. 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 @@ -360,6 +382,14 @@ informative comments (in alphabetical order): Ed Lewis + + + +Expires April 2001 [Page 7] + +INTERNET-DRAFT Secure Dynamic Update October 2000 + + 7 - References [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' @@ -376,27 +406,45 @@ informative comments (in alphabetical order): 2137, CyberCash, April 1997. [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC - 2065, IBM, March 1999. + 2535, IBM, March 1999. -[TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington - ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- - ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March - 2000. +[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 November 2000 [Page 7] - -INTERNET-DRAFT Secure Dynamic Update May 2000 -[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),'' - draft-ietf-dnsext-tkey-02.txt, IBM, April 2000. -[signing-auth] - B. Wellington ``Domain Name System Security (DNSSEC) Signing - Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum, - May 2000. + + + + + + + + + + + + + + + +Expires April 2001 [Page 8] + +INTERNET-DRAFT Secure Dynamic Update October 2000 + 8 - Author's Address @@ -441,5 +489,13 @@ FITNESS FOR A PARTICULAR PURPOSE." -Expires November 2000 [Page 8] + + + + + + + + +Expires April 2001 [Page 9]