upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-05-28 04:34:54 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

updated drafts

Browse source
This commit is contained in:
Andreas Gustafsson 2000-11-22 17:31:53 +00:00
parent f03de4e1bf
commit ca41de74d2
2 changed files with 118 additions and 63 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

135
doc/draft/draft-ietf-dnsext-axfr-clarify-00.txt → doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt
View file

@ -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]

46
doc/draft/draft-ietf-dnsext-edns0dot5-01.txt → doc/draft/draft-ietf-dnsext-edns0dot5-02.txt
View file

@ -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]