Commit 599c6d44 authored by Michael Graff's avatar Michael Graff
Browse files

resurrect dead files for Andreas

parent 19d1b166
This diff is collapsed.
DNSIND Working Group K. Dunlap
INTERNET-DRAFT Check Point Software
<draft-dunlap-dns-duxfr-00.txt> P. Vixie
ISC
September 1999
Dynamic Update Zone Transfer
Copyright (C) The Internet Society (1999). All Rights Reserved.
Status of This Memo
This draft, file name draft-dunlap-dns-duxfr-00.txt, is intended to
become a Proposed Standard RFC. Distribution of this document is unlim-
ited. Comments should be sent to <namedroppers@internic.net> or to the
authors.
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
ments 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 not appropriate 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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document proposes an alternative extension to the DNS protocol for
Incremental zone transfer (IXFR) [RFC1995]. This extension uses the
mechanisms for adding and deleting Resource Records specified in
[RFC2136] to transmit the changes between authoritative servers of a
zone.
Expires March 2000 [Page 1]
INTERNET-DRAFT DNS DUXFR September 1999
1 - Introduction
For rapid propagation of changes to a DNS database [STD13], it is neces-
sary to reduce latency by actively notifying servers of the change.
This is accomplished by the DNS NOTIFY Mechanism [RFC1996].
The simple method described for Incremental transfer (IXFR), in
[RFC1995], does not adequately address the complexity of the problem.
Dynamic Update Zone Transfer (DUXFR), as proposed, is a mechanism to
transmit the complexity of changes in the zone and still have the effi-
ciency of IXFR means to propagate changed portions of a zone.
In this document, a slave name server which requests DUXFR is called a
DUXFR client and a master or slave name server which responds to the
request is called a DUXFR server.
2 - Brief Description of the Protocol
If a DUXFR client, which likely has an older version of a zone, thinks
it needs a newer version of the zone (typically through SOA refresh
timeout or the NOTIFY mechanism), it sends a DUXFR message containing
the SOA serial number of its (presumably outdated) copy of the zone.
A DUXFR server should keep record of the newest version of the zone and
the differences between that copy and several older versions. When a
DUXFR request with an older version number is received, the DUXFR server
needs to send only the differences required to make that version
current. These differences are sent using the DNS UPDATE format packets
for deletes and add specified in [RFC2136 2.5].
When a zone has been updated, it should be saved in stable storage
before the new version is used to respond to DUXFR (or AXFR) queries.
Otherwise, if the server crashes, data which is no longer available may
have been distributed to slave servers, which can cause persistent data-
base inconsistencies.
If a DUXFR query with the same or newer version number than that of the
server is received, it is replied to with a single SOA record of the
server's current version, just as in IXFR.
The Transport protocol for DUXFR queries is TCP/IP.
Expires March 2000 [Page 2]
INTERNET-DRAFT DNS DUXFR September 1999
3 - Query Format
The DUXFR Query format is based on the standard DNS UPDATE Message For-
mat. In the DNS Packet Header the Opcode is set to UPDATE and the Zone
Type (ZTYPE) being set to AXFR. The Additional section containing the
SOA record of the client's version of the zone.
4 - Response Format
The response packets to the DUXFR query are in the standard DNS UPDATE
Message Format. The records in the Update Section are formatted using
the four sets of semantics for adding and deleting Resource Records
specified in the ``Update Section'' in [RFC2136 2.5]. The client will
process these changes using the prerequisite for the transaction as the
existence of the SOA serial number specified in the Additional section
of the DUXFR query.
The response to a DUXFR query, when the server no longer has all the
previous history from the version the client requests, will be a
Response code (RCODE) of "Refused". It is recommended that the client
retry with an AXFR query described in [RFC1034 4.3.5].
It is recommended that the Prerequisite sections of the DNS message be
empty on transmission and ignored on reception. The Additional section
may contain necessary data such as signatures as specified by other
extensions to [RFC 2136].
5 - Version Overhead
A DUXFR server can not be required to hold all previous versions forever
and may delete them anytime. In general, there is a trade-off between
the size of storage space and the possibility of using DUXFR.
Information about older versions should be purged if the total length of
a DUXFR response would be longer than that of an AXFR response. Given
that the purpose of DUXFR is to reduce AXFR overhead, this strategy is
quite reasonable. The strategy assures that the amount of storage
required is at most twice that of the current zone information.
Information older than the SOA expire period may also be purged.
6 - IANA Considerations
No IANA services are required by this document.
Expires March 2000 [Page 3]
INTERNET-DRAFT DNS DUXFR September 1999
7 - Security Considerations
DNS is related to several security problems, no attempt is made to fix
them in this document.
The authors believe that this document does not introduce any additional
security problems to the current DNS protocol.
8 - Examples
Given the following three generations of data with the current serial
number of 3.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com.
(
1 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Vangogh.Example.Com. IN A 192.168.1.21
Vangogh.Example.Com. is removed and Monet.Example.Com. is added.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com. (
2 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Monet.Example.Com. IN A 192.168.6.27
IN A 192.168.3.128
One of the IP address of Monet.Example.Com. is changed.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com. (
3 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Monet.Example.Com. IN A 192.168.6.42
IN A 192.168.3.128
Expires March 2000 [Page 4]
INTERNET-DRAFT DNS DUXFR September 1999
The following DUXFR query:
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Request |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | <empty> |
+--------------------------------------------------+
Update | <empty> |
+--------------------------------------------------+
Additional | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
The reply could be with the following DUXFR response with Update packets
in the Answer Section:
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Response |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 |
| Monet.Example.Com. IN A 192.168.6.42 |
| Monet.Example.Com. IN A 192.168.3.128 |
| Example.Com. 0 IN SOA serial=1 |
| Example.Com. IN SOA serial=2 |
| Monet.Example.Com. 0 ANY A 192.168.6.42 |
| Example.Com. 0 ANY SOA serial=2 |
| Example.Com. IN SOA serial=3 |
+--------------------------------------------------+
Additional | <empty> |
+--------------------------------------------------+
or with the following Compressed DUXFR response with Update packets in
the Answer Section:
Expires March 2000 [Page 5]
INTERNET-DRAFT DNS DUXFR September 1999
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Response |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 |
| Monet.Example.Com. IN A 192.168.6.42 |
| Monet.Example.Com. IN A 192.168.3.128 |
| Example.Com. 0 ANY SOA serial=1 |
| Example.Com. IN SOA serial=3 |
+--------------------------------------------------+
Additional | <empty> |
+--------------------------------------------------+
References
[RFC1034]]
P. Mockapetris, ``Domain Names - Concepts and Facilities'' STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specifica-
tion'' RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1996]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes
(DNS Notify)'' RFC 1996, August 1996
[RFC1995]
M. Ohta, ``Incremental Zone Transfer in DNS'' RFC 1995, August
1996.
[RFC2026]
S. Bradner, ``the Internet Standards Process -- Revision 3'' RFC
2026, Harvard University, October 1996.
[RFC2136]
P. Vixie, S. Thomson, Y. Rekhter and J. Bound, ``Dynamic
Updates in the Domain Name System (DNS UPDATE)'' RFC 2136,
April 1997
Expires March 2000 [Page 6]
INTERNET-DRAFT DNS DUXFR September 1999
Author's Address
Kevin J. Dunlap
Check Point Software Technologies, Inc.
The Meta IP Group
119 South Main Street, Suite 200
Seattle, WA 98033
+1 206 674 3700
<kevind@MetaIP.CheckPoint.Com>
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<vixie@isc.org>
Expires March 2000 [Page 7]
INTERNET-DRAFT DNS DUXFR September 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 implementation 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 March 2000 [Page 8]
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
May 5, 1999
Binary Labels in the Domain Name System
<draft-ietf-dnsind-binary-labels-05.txt>
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.
1. Introduction and Terminology
This document defines a ``Bit-String Label'' which may appear within
domain names. This new label type compactly represents a sequence
of ``One-Bit Labels'' and enables resource records to be stored at
any bit-boundary in a binary-named section of the domain name tree.
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 [KWORD].
2. Motivation
Binary labels are intended to efficiently solve the problem of
storing data and delegating authority on arbitrary boundaries when
the structure of underlying name space is most naturally represented
in binary.
Expires November 10, 1999 Crawford [Page 1]
Internet Draft Binary DNS Labels May 5, 1999
3. Label Format
Up to 256 One-Bit Labels can be grouped into a single Bit-String
Label. Within a Bit-String Label the most significant or "highest
level" bit appears first. This is unlike the ordering of DNS labels
themselves, which has the least significant or "lowest level" label
first. Nonetheless, this ordering seems to be the most natural and
efficient for representing binary labels.
Among consecutive Bit-String Labels, the bits in the first-appearing
label are less significant or "at a lower level" than the bits in
subsequent Bit-String Labels, just as ASCII labels are ordered.
3.1. Encoding
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Count | Label ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
(Each tic mark represents one bit.)
ELT 000001 binary, the six-bit extended label type [EDNS0]
assigned to the Bit-String Label.
Count The number of significant bits in the Label field. A
Count value of zero indicates that 256 bits are
significant. (Thus the null label representing the DNS
root cannot be represented as a Bit String Label.)
Label The bit string representing a sequence of One-Bit Labels,
with the most significant bit first. That is, the One-Bit
Label in position 17 in the diagram above represents a
subdomain of the domain represented by the One-Bit Label
in position 16, and so on.
The Label field is padded on the right with zero to seven
pad bits to make the entire field occupy an integral
number of octets. These pad bits MUST be zero on
transmission and ignored on reception.
A sequence of bits may be split into two or more Bit-String Labels,
but the division points have no significance and need not be
preserved. An excessively clever server implementation might split
Expires November 10, 1999 Crawford [Page 2]
Internet Draft Binary DNS Labels May 5, 1999
Bit-String Labels so as to maximize the effectiveness of message
compression [DNSIS]. A simpler server might divide Bit-String
Labels at zone boundaries, if any zone boundaries happen to fall
between One-Bit Labels.
3.2. Textual Representation
A Bit-String Label is represented in text -- in a zone file, for
example -- as a <bit-spec> surrounded by the delimiters "\[" and
"]". The <bit-spec> is either a dotted quad or a base indicator and
a sequence of digits appropriate to that base, optionally followed
by a slash and a length. The base indicators are "b", "o" and "x",
denoting base 2, 8 and 16 respectively. The length counts the
significant bits and MUST be between 1 and 32, inclusive, after a
dotted quad, or between 1 and 256, inclusive, after one of the other
forms. If the length is omitted, the implicit length is 32 for a
dotted quad or 1, 3 or 4 times the number of binary, octal or
hexadecimal digits supplied, respectively, for the other forms.
In augmented Backus-Naur form [ABNF],
bit-string-label = "\[" bit-spec "]"
bit-spec = bit-data [ "/" length ]
/ dotted-quad [ "/" slength ]
bit-data = "x" 1*64HEXDIG
/ "o" 1*86OCTDIG
/ "b" 1*256BIT
dotted-quad = decbyte "." decbyte "." decbyte "." decbyte
decbyte = 1*3DIGIT
length = NZDIGIT *2DIGIT
slength = NZDIGIT [ DIGIT ]
OCTDIG = %x30-37
NZDIGIT = %x31-39
If a <length> is present, the number of digits in the <bit-data>
MUST be just sufficient to contain the number of bits specified by
the <length>. If there are insignificant bits in a final
hexadecimal or octal digit, they MUST be zero. A <dotted-quad>
always has all four parts even if the associated <slength> is less
Expires November 10, 1999 Crawford [Page 3]
Internet Draft Binary DNS Labels May 5, 1999
than 24, but, like the other forms, insignificant bits MUST be zero.
Each number represented by a <decbyte> must be between 0 and 255,
inclusive.
The number represented by <length> must be between 1 and 256
inclusive.
The number represented by <slength> must be between 1 and 32
inclusive.
When the textual form of a Bit-String Label is generated by machine,
the length SHOULD be explicit, not implicit.
3.2.1. Examples
The following four textual forms represent the same Bit-String
Label.
\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]
The following represents two consecutive Bit-String Labels which
denote the same relative point in the DNS tree as any of the above
single Bit-String Labels.
\[b11101].\[o640]
3.3. Canonical Representation and Sort Order
Both the wire form and the text form of binary labels have a degree
of flexibility in their grouping into multiple consecutive Bit-
String Labels. For generating and checking DNS signature records
[DNSSEC] binary labels must be in a predictable form. This
canonical form is defined as the form which has the fewest possible
Bit-String Labels and in which all except possibly the first (least
significant) label in any sequence of consecutive Bit-String Labels
is of maximum length.
For example, the canonical form of any sequence of up to 256 One-Bit
Labels has a single Bit-String Label, and the canonical form of a
sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
which the second and third contain 256 label bits.
Expires November 10, 1999 Crawford [Page 4]
Internet Draft Binary DNS Labels May 5, 1999
The canonical sort order of domain names [DNSSEC] is extended to
encompass binary labels as follows. Sorting is still label-by-
label, from most to least significant, where a label may now be a
One-Bit Label or a standard (code 00) label. Any One-Bit Label
sorts before any standard label, and a 0 bit sorts before a 1 bit.
The absence of a label sorts before any label, as specified in
[DNSSEC].
For example, the following domain names are correctly sorted.
foo.example
\[b1].foo.example
\[b100].foo.example
\[b101].foo.example
bravo.\[b10].foo.example
alpha.foo.example
4. Processing Rules
A One-Bit Label never matches any other kind of label. In
particular, the DNS labels represented by the single ASCII
characters "0" and "1" do not match One-Bit Labels represented by
the bit values 0 and 1.
5. Discussion
A Count of zero in the wire-form represents a 256-bit sequence, not
to optimize that particular case, but to make it completely
impossible to have a zero-bit label.
6. IANA Considerations
This document defines one Extended Label Type, termed the Bit-String
Label, and requests registration of the code point 000001 binary in
the space defined by [EDNS0].
7. Security Considerations
All security considerations which apply to traditional ASCII DNS
labels apply equally to binary labels. he canonicalization and
sorting rules of section 3.3 allow these to be addressed by DNS
Security [DNSSEC].
Expires November 10, 1999 Crawford [Page 5]
Internet Draft Binary DNS Labels May 5, 1999
8. References
[ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234.