Commit d8eee1b9 authored by Andreas Gustafsson's avatar Andreas Gustafsson
Browse files

added and updated some drafts

parent f3d4453c
INTERNET-DRAFT Peter Koch
Expires: December 1999 Universitaet Bielefeld
Updates: RFC 1035 June 1999
Expires: April 2000 Universitaet Bielefeld
Updates: RFC 1035 October 1999
A DNS RR Type for Lists of Address Prefixes (APL RR)
draft-ietf-dnsind-apl-rr-02.txt
draft-ietf-dnsind-apl-rr-03.txt
Status of this Memo
......@@ -45,20 +45,20 @@ Abstract
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [RFC2606].
Koch Expires December 1999 [Page 1]
Koch Expires April 2000 [Page 1]
INTERNET-DRAFT DNS APL RR June 1999
INTERNET-DRAFT DNS APL RR October 1999
2. Background
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
assign addresses and other internet infrastructure elements to
hierarchically built domain names. Various types of resource records
have been defined, especially those for IPv4 and IPv6 [RFC1886],
[A6DNSRR] addresses. In [RFC1101] a method is described to publish
information about the address space allocated to an organisation. In
older BIND versions, a weak form of controlling access to zone data
was implemented using TXT RRs describing address ranges.
have been defined, especially those for IPv4 and IPv6 [RFC1886]
addresses. In [RFC1101] a method is described to publish information
about the address space allocated to an organisation. In older BIND
versions, a weak form of controlling access to zone data was
implemented using TXT RRs describing address ranges.
This document specifies a new RR type for address prefix lists.
......@@ -96,9 +96,9 @@ INTERNET-DRAFT DNS APL RR June 1999
This document defines the AFDPARTs for address families 1 (IPv4) and
Koch Expires December 1999 [Page 2]
Koch Expires April 2000 [Page 2]
INTERNET-DRAFT DNS APL RR June 1999
INTERNET-DRAFT DNS APL RR October 1999
2 (IPv6). Future revisions may deal with additional address
families.
......@@ -131,12 +131,15 @@ INTERNET-DRAFT DNS APL RR June 1999
The textual representation of an APL RR in a DNS zone file is as
follows:
<owner> IN <TTL> APL {[!]address/prefix}*
<owner> IN <TTL> APL {[!]afi:address/prefix}*
The data consists of zero or more strings of an address, immediately
followed by the "/" character, immediately followed by a decimal
numeric value for the prefix length. Any such string may be preceeded
by a "!" character. The strings are separated by whitespace.
The data consists of zero or more strings of the address family
indicator <afi>, immediately followed by a colon ":", an address,
immediately followed by the "/" character, immediately followed by a
decimal numeric value for the prefix length. Any such string may be
preceeded by a "!" character. The strings are separated by
whitespace. The <afi> is the decimal numeric value of that
particular address family.
5.1. Textual Representation of IPv4 Addresses
......@@ -146,13 +149,12 @@ INTERNET-DRAFT DNS APL RR June 1999
5.2. Textual Representation of IPv6 Addresses
The representation of an IPv6 address in the <address> part of an
<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
Koch Expires December 1999 [Page 3]
Koch Expires April 2000 [Page 3]
INTERNET-DRAFT DNS APL RR June 1999
INTERNET-DRAFT DNS APL RR October 1999
The representation of an IPv6 address in the <address> part of an
<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
are from the interval 0..128 (decimal).
6. APL RR usage
......@@ -168,63 +170,92 @@ INTERNET-DRAFT DNS APL RR June 1999
by the available RDATA space.
RRSets consisting of more than one APL RR are legal but the
interpretation is left to the particular application. It may choose
to join the lists or treat them as alternatives.
interpretation is left to the particular application.
7. Applicability Statement
The APL RR defines a framework without specifying any particular
meaning for the list of prefixes. It is expected that APL RRs will
be used in different application scenarios which have to be
documented separately. Those scenarios may be distinguished by
characteristic prefixes placed in front of the DNS owner name.
An APL application specification MUST include information on
o the characteristic prefix, if any
o how to interpret APL RRSets consisting of more than one RR
o how to interpret an empty APL RR
o which address families are expected to appear in the APL RRs for
that application
o how to deal with APL RR list elements which belong to other
address families, including those not yet defined
Possible applications include the publication of address ranges
similar to [RFC1101], description of zones built following [RFC2317]
and in-band access control to limit general access or zone transfer
(AXFR) availability for zone data held in DNS servers.
7. Examples
The specification of particular application scenarios is out of the
Koch Expires April 2000 [Page 4]
INTERNET-DRAFT DNS APL RR October 1999
Example usages otlined in the prevois section are shown here. The
line continuation symbol in the second APL RR appears for editorial
purposes only, it is not valid in zone files.
scope of this document.
foo.example APL 192.168.32.0/21 !192.168.38.0/28
8. Examples
42.168.192.IN-ADDR.ARPA APL 192.168.42.0/26 192.168.42.64/26 \
192.168.42.128/25
The following examples only illustrate some of the possible usages
outlined in the previous section. None of those applications are
hereby specified nor is it implied that any particular APL RR based
application does exist now or will exist in the future.
_axfr.sbo.example APL 127.0.0.1/32 172.16.64.0/22
; RFC 1101-like announcement of address ranges for foo.example
foo.example APL 1:192.168.32.0/21 !1:192.168.38.0/28
multicast.example APL 224.0.0.0/4 FF00:0:0:0:0:0:0:0/8
; CIDR blocks covered by classless delegation
42.168.192.IN-ADDR.ARPA APL ( 1:192.168.42.0/26 1:192.168.42.64/26
1:192.168.42.128/25 )
; Zone transfer restriction
_axfr.sbo.example APL 1:127.0.0.1/32 1:172.16.64.0/22
; List of address ranges for multicast
multicast.example APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
Note that since trailing zeroes are ignored in the first APL RR the
AFDLENGTH of both <apstrings> is three.
8. Security Considerations
9. Security Considerations
Any information obtained from the DNS should be regarded as unsafe
unless techniques specified in [RFC2535] or [TSIGRR] were used. The
definition of a new RR type does not introduce security problems into
the DNS, but usage of information made available by APL RRs may
compromise security. This includes disclosure of network topology
Koch Expires December 1999 [Page 4]
INTERNET-DRAFT DNS APL RR June 1999
information and in particular the use of APL RRs to construct access
control lists.
9. IANA Considerations
10. IANA Considerations
This document does not define any new namespaces. It uses the 16 bit
identifiers for address families maintained by IANA in
ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
10. Acknowledgements
11. Acknowledgements
The author would like to thank Mark Andrews for his review and
constructive comments.
11. References
12. References
Koch Expires April 2000 [Page 5]
[A6DNSRR] Crawford,M., Huitema,C., Thomson,S., "DNS Extensions to
Support IPv6 Address Aggregation and Renumbering",
<draft-ietf-ipngwg-dns-lookups-XX.txt>, work in progress
INTERNET-DRAFT DNS APL RR October 1999
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
......@@ -244,6 +275,9 @@ INTERNET-DRAFT DNS APL RR June 1999
[RFC2181] Elz,R., Bush,R., "Clarifications to the DNS
Specification", RFC 2181, July 1997
[RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA
delegation", RFC 2317, March 1998
[RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998
......@@ -253,15 +287,11 @@ INTERNET-DRAFT DNS APL RR June 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
Koch Expires December 1999 [Page 5]
INTERNET-DRAFT DNS APL RR June 1999
[TSIGRR] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,
"Secret Key Transaction Signatures for DNS (TSIG)",
<draft-ietf-dnsind-tsig-XX.txt>, work in progress
12. Author's Address
13. Author's Address
Peter Koch
Universitaet Bielefeld
......@@ -272,4 +302,4 @@ INTERNET-DRAFT DNS APL RR June 1999
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires December 1999 [Page 6]
Koch Expires April 2000 [Page 6]
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
facilities", RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
Author's addresses:
Rob Austein
On Sabbatical
sra@hactrn.net
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
vixie@isc.org
Austein & Vixie Expires 18 April 2000 [Page 3]
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment