diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt similarity index 69% rename from doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt rename to doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt index b998876249..7c1d45e565 100644 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt @@ -1,7 +1,6 @@ - INTERNET-DRAFT Andreas Gustafsson -draft-ietf-dnsext-axfr-clarify-00.txt Nominum Inc. - March 2000 +draft-ietf-dnsext-axfr-clarify-01.txt Nominum Inc. + November 2000 DNS Zone Transfer Protocol Clarifications @@ -19,7 +18,7 @@ Status of this Memo 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 + 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 @@ -50,9 +49,9 @@ Abstract -Expires September 2000 [Page 1] +Expires May 2001 [Page 1] -draft-ietf-dnsext-axfr-clarify-00.txt March 2000 +draft-ietf-dnsext-axfr-clarify-01.txt November 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -66,6 +65,10 @@ draft-ietf-dnsext-axfr-clarify-00.txt March 2000 The form of this request is specified in sufficient detail in RFC1034 and needs no further clarification. + Implementers are advised that one server implementation in widespread + use sends AXFR requests where the TCP message envelope size exceeds + the DNS request message size by two octets. + 3. The zone transfer response If the master server is unable or unwilling to provide a zone @@ -99,18 +102,18 @@ draft-ietf-dnsext-axfr-clarify-00.txt March 2000 compatibility with old slaves, masters that support sending multiple answers per message SHOULD be configurable to revert to the historical mode of one answer per message, and the configuration + + + +Expires May 2001 [Page 2] + +draft-ietf-dnsext-axfr-clarify-01.txt November 2000 + + SHOULD be settable on a per-slave basis. 3.2. DNS message header contents - - - -Expires September 2000 [Page 2] - -draft-ietf-dnsext-axfr-clarify-00.txt March 2000 - - RFC1034 does not specify the contents of the DNS message header of the zone transfer response messages. The header of each message MUST be as follows: @@ -121,8 +124,9 @@ draft-ietf-dnsext-axfr-clarify-00.txt March 2000 AA 1 (but MAY be 0 when RCODE is nonzero) TC 0 RD Copy from request - RA Set according to availability of recursion - Z 000 + RA Set according to availability of recursion S Z 0 + AD 0 + CD 0 RCODE 0 or error code The slave MUST check the RCODE and abort the transfer if it is @@ -154,29 +158,47 @@ draft-ietf-dnsext-axfr-clarify-00.txt March 2000 section. Slaves MUST ignore any authority section contents they may receive from masters that do not comply with this requirement. + + + +Expires May 2001 [Page 3] + +draft-ietf-dnsext-axfr-clarify-01.txt November 2000 + + 3.6. The additional section The additional section MAY contain additional RRs such as transaction signatures. The slave MUST ignore any unexpected RRs in the additional section. - - -Expires September 2000 [Page 3] - -draft-ietf-dnsext-axfr-clarify-00.txt March 2000 - - 4. Glue - Zone transfers MAY contain glue RRs pertaining to NS records in the - zone. An RR is considered a glue RR when it is not within the zone - being transferred. A slave MUST recognize glue RRs as such; it MUST - NOT treat them as authoritative data. + A master transmitting a zone transfer MUST include the full set of + zone data it loaded from the zone's master file, from an incoming + zone transfer, or other similar means of configuring zone data. This + includes any nonauthoritative data ("glue") associated with the zone + by being present in the zone's master file or the incoming transfer + along with the authoritative data. This glue data includes any + configured zone data obscured by zone cuts or otherwise outside the + zone in case; it is not limited to RRs pointed to by NS records. - Note that classifying an RR as glue or non-glue may not be possible - until the entire zone has been received so that the zone cuts defined - by the zone's NS records can be determined. + The glue RRs are transmitted in the answer section along with the + authoritative data. This is unlike ordinary DNS responses where glue + is transmitted in the authority or additional section. + + Zone transfers MUST NOT contain RRs from the authoritative data of + zones other than the one being transferred or from the cache, even + when such RRs are pointed to by NS records in the zone being + transferred. + + A slave receiving a zone transfer MUST accept glue data and recognize + it as such; glue MUST NOT be treated as authoritative data nor + entered into the cache. Note that classifying an RR as glue or non- + glue may not be possible until the entire zone has been received so + that the zone cuts defined by the zone's NS records can be + determined. Glue data that is not below the zone origin ("cross-zone + glue") MAY be discarded by the slave. 5. Transmission order @@ -192,11 +214,36 @@ draft-ietf-dnsext-axfr-clarify-00.txt March 2000 The initial and final SOA record MUST be identical, with the possible exception of case and compression. In particular, they MUST have the + + + +Expires May 2001 [Page 4] + +draft-ietf-dnsext-axfr-clarify-01.txt November 2000 + + same serial number. The transmission order of all other RRs in the zone, including glue records, is undefined. +6. Security Considerations + + The zone transfer protocol as defined in [RFC1034] and clarified by + this memo does not have any built-in mechanisms for the slave to + securely verify the identity of the master server and the integrity + of the transferred zone data. The use of TSIG [RFC2845] for this + purpose is RECOMMENDED. + + The zone transfer protocol allows read-only public access to the + complete zone data. Since data in the DNS is public by definition, + this is generally acceptable. Sites that wish to avoid disclosing + their full zone data MAY restrict zone transfer access to authorized + slaves. + + These clarifications are not believed to themselves introduce any new + security problems, nor to solve any existing ones. + References [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, @@ -205,8 +252,11 @@ References [RFC1035] - Domain Names - Implementation and Specifications, P. Mockapetris, November 1987. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, + S. Bradner, BCP 14, March 1997. + + [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. + Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. Author's Address @@ -216,18 +266,18 @@ Author's Address Redwood City, CA 94063 USA - - -Expires September 2000 [Page 4] - -draft-ietf-dnsext-axfr-clarify-00.txt March 2000 - - Phone: +1 650 779 6004 Email: gson@nominum.com + + +Expires May 2001 [Page 5] + +draft-ietf-dnsext-axfr-clarify-01.txt November 2000 + + Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. @@ -274,5 +324,10 @@ Full Copyright Statement -Expires September 2000 [Page 5] + + + + + +Expires May 2001 [Page 6] diff --git a/doc/draft/draft-ietf-dnsext-edns0dot5-01.txt b/doc/draft/draft-ietf-dnsext-edns0dot5-02.txt similarity index 87% rename from doc/draft/draft-ietf-dnsext-edns0dot5-01.txt rename to doc/draft/draft-ietf-dnsext-edns0dot5-02.txt index cd9e98a1ad..098da810b6 100644 --- a/doc/draft/draft-ietf-dnsext-edns0dot5-01.txt +++ b/doc/draft/draft-ietf-dnsext-edns0dot5-02.txt @@ -5,10 +5,10 @@ Network Working Group R. Austein -draft-ietf-dnsext-edns0dot5-01.txt InterNetShare.com, Inc. +draft-ietf-dnsext-edns0dot5-02.txt InterNetShare.com, Inc. H. Alvestrand - EDB MaXware AS - July 2000 + Cisco Systems + November 2000 A Proposed Enhancement to the EDNS0 Version Mechanism @@ -55,12 +55,12 @@ Motivation and Scope -Austein & Alvestrand Expires 15 January 2001 [Page 1] +Austein & Alvestrand Expires 22 May 2001 [Page 1] -draft-ietf-dnsext-edns0dot5-01.txt July 2000 +draft-ietf-dnsext-edns0dot5-02.txt November 2000 - This note proposes to replace the monolithic version numbering + This note proposes to augument the monolithic version numbering mechanism with a mechanism for listing an explicit set of protocol features that a particular implementation supports. We retain version numbering as a way of abbreviating the feature sets that we @@ -68,8 +68,8 @@ draft-ietf-dnsext-edns0dot5-01.txt July 2000 Model - Our revised extension model for EDNS0 is designed with three goals in - mind: + Our revised extension model for the DNS is designed with three goals + in mind: - We want the protocol to be as simple as possible for the common case of a client or server that implements "mainstream standard @@ -111,9 +111,9 @@ Model -Austein & Alvestrand Expires 15 January 2001 [Page 2] +Austein & Alvestrand Expires 22 May 2001 [Page 2] -draft-ietf-dnsext-edns0dot5-01.txt July 2000 +draft-ietf-dnsext-edns0dot5-02.txt November 2000 process, any significantly changed Internet-Draft should have a new @@ -135,8 +135,8 @@ draft-ietf-dnsext-edns0dot5-01.txt July 2000 Mechanism - We propose to transport explicit feature sets as lists of integers - carried in the variable RDATA portion of the EDNS0 OPT pseudo-RR. + We transport explicit feature sets as lists of integers carried in + the variable RDATA portion of the EDNS0 OPT pseudo-RR. The OPTION-CODE for FEATURES is [TBD]. @@ -167,9 +167,9 @@ Usage -Austein & Alvestrand Expires 15 January 2001 [Page 3] +Austein & Alvestrand Expires 22 May 2001 [Page 3] -draft-ietf-dnsext-edns0dot5-01.txt July 2000 +draft-ietf-dnsext-edns0dot5-02.txt November 2000 In general, we expect that a client or server will include an OPT @@ -223,9 +223,9 @@ Risks -Austein & Alvestrand Expires 15 January 2001 [Page 4] +Austein & Alvestrand Expires 22 May 2001 [Page 4] -draft-ietf-dnsext-edns0dot5-01.txt July 2000 +draft-ietf-dnsext-edns0dot5-02.txt November 2000 A flexible extension mechanism of this type increases the risk that @@ -279,9 +279,9 @@ References -Austein & Alvestrand Expires 15 January 2001 [Page 5] +Austein & Alvestrand Expires 22 May 2001 [Page 5] -draft-ietf-dnsext-edns0dot5-01.txt July 2000 +draft-ietf-dnsext-edns0dot5-02.txt November 2000 Author's addresses: @@ -295,12 +295,12 @@ Author's addresses: sra@hactrn.net Harald Tveit Alvestrand - EDB MaXware AS - Pirsenteret - N-7486 Trondheim + Cisco Systems + Weidemanns vei 27 + N-7043 Trondheim NORWAY - +47 73 54 57 97 + +47 73 50 33 52 Harald@Alvestrand.no @@ -335,4 +335,4 @@ Author's addresses: -Austein & Alvestrand Expires 15 January 2001 [Page 6] +Austein & Alvestrand Expires 22 May 2001 [Page 6]