Commit 984d0b25 authored by Andreas Gustafsson's avatar Andreas Gustafsson
Browse files

removed Internet-Drafts that have expired but not been replaced

by an expiration notice in the IETF I-D repository
parent 87d4aeaf
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]
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsind-dhcp-rr-00.txt Internet Engines, Inc.
October 1999
A DNS RR for encoding DHCP information
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.
Abstract
This document describes a DNS RR for use by DHCP servers that need to
store state information in the DNS.
Introduction
A set of procedures to allow DHCP servers [RFC2131] to automatically
update the DNS [RFC1034, RFC1035] is proposed in [DHCPDNS].
A situation can arise where multiple DHCP clients request the same
DNS name from their (possibly distinct) DHCP servers. To resolve
such conflicts, [DHCPDNS] proposes storing client identifiers in the
DNS to unambiguously associate domain names with the DHCP clients
"owning" them. Early versions of [DHCPDNS] proposed using TXT
records for encoding this information; the current version specifies
the use of KEY records.
In the interest of clarity, it would be preferable for this DHCP
Expires April 2000 [Page 1]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
information to use a distinct RR type rather than the existing KEY
type. A separate RR type can also improve efficiency by avoiding the
unnecessary transmission of unrelated KEY records.
This memo defines a distinct RR type for use by DHCP servers, the
"DHCP" RR.
The DHCP RR
The DHCP RR is defined with mnemonic DHCP and type code <TBD>.
DHCP RDATA format
The RDATA section of a DHCP RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its interpretation
by DHCP servers and clients, including the interpretation of multiple
DHCP RRs at the same domain name, are TBD. [This part of the
specification should be driven by the needs of, and written in
cooperation with, the DHCP Working Group and the authors of
[DHCPDNS]].
DNS software should consider the RDATA section to be opaque. In DNS
master files, the RDATA is represented as a hexadecimal string with
an optional "0x" or "0X" prefix. Periods (".") may be inserted
anywhere after the "0x" for readability. This format is identical to
that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST
be even.
Example
A DHCP server allocating the IPv4 address 10.0.0.1 to a client
"client.org.nil" might associate eight bytes of housekeeping
information with the client as follows:
client.org.nil. A 10.0.0.1
client.org.nil. DHCP 01.23.45.67.89.ab.cd.ef
Security Considerations
The DHCP record as such does not introduce any new security problems
into the DNS. However, care should be taken not to store sensitive
information in DHCP records, since they are published along with
other DNS data. Note that even the hardware addresses of DHCP
clients may be considered sensitive information.
IANA Considerations
The IANA is requested to allocate an RR type number for the DHCP
Expires April 2000 [Page 2]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
record type from the regular RR type number range.
References
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987.
[RFC1706] - DNS NSAP Resource Records, B. Manning, R. Colella,
October 1994.
[RFC2131] - Dynamic Host Configuration Protocol, R. Droms, March
1997.
[DHCPDNS] - draft-ietf-dhc-dhcp-dns-*.txt
Author's Address
Andreas Gustafsson
Internet Engines, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1 650 779 6004
Email: gson@iengines.net
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 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.
Expires April 2000 [Page 3]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
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 2000 [Page 4]
This diff is collapsed.
This diff is collapsed.
Network Working Group R. Austein
draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical
P. Vixie
Internet Software Consortium
October 1999
DNS SIGALGOPT
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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>
Distribution of this document is unlimited. Please send comments to
the namedroppers@internic.net mailing list.
Abstract
This document describes a mechanism for conserving packet space in a
DNS response message in the presence of multiple DNSSEC signature
algorithms.
Motivation and Scope
DNSSEC [DNSSEC] specifies a general framework for attaching
cryptographic signatures to DNS resource records. The framework
includes provisions for multiple signature protocols, possibly even
on a per-name basis. While this open-ended framework is good and
useful, it poses a problem when multiple signature protocols are in
use and DNS message sizes are limited by the underlying UDP transport
packet size. EDNS0 [EDNS0] provides a way to specify a larger
Austein & Vixie Expires 18 April 2000 [Page 1]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
payload size, but this still does not entirely solve the problem for
large RRsets. Worse, in cases where multiple signature algorithms
generate a response packet so large that it must be truncated, the
signatures that fit into the truncated response will be useless if
the resolver doesn't know how to verify signatures generated with
that algorithm.
This note proposes a way for a resolver to indicate which signature
algorithms it understands to a name server in the form of an ordered
list. When this mechanism is in use, the name server can conserve
packet space by (a) not sending signatures with algorithms that the
resolver will not understand, and (b) not sending multiple signatures
for the same resource records.
Mechanism
[DNSSEC] SIG RRs include a one-octet code indicating the algorithm
associated with a particular signature. The SIGALGOPT option defined
below allows the resolver to specify an ordered list of signature
algorithms using the same one-octet codes that DNSSEC uses.
SIGALGOPT is encoded n the variable RDATA part of the OPT pseudo-RR
in the DNS request (see [EDNS0]).
The OPTION-CODE for SIGALGOPT is [TBD].
The OPTION-DATA for SIGALGOPT is an ordered list of the one-octet
codes used by DNSSEC.
If the SIGALGOPT option in a query specifies multiple signature
algorithms and signatures using more than one of those algorithms are
available in the zone, the server must respond with the signatures
corresponding to the first algorithm on the SIGALGOPT list that
matches, omitting any signatures corresponding to the remaining
algorithms.
We have deliberately not provided a mechanism to return all the
matching signatures, because the purpose of the SIGALGOPT mechanism
is to minimize packet size. If the resolver wants to see all
available signatures, it should just leave off the SIGALGOPT option
entirely.
Security Considerations
Good question. What horrible things could a bad guy do by
creating/altering/deleting SIGALGOPT? Are any of the possible
attacks more interesting than denial of service?
Austein & Vixie Expires 18 April 2000 [Page 2]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
IANA Considerations
SIGALGOPT will need an option code.
The signature algorithm codes themselves are borrowed from DNSSEC and
do not create any new issues for IANA.
References
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and