INTERNET-DRAFT Peter Koch
Expires: December 2000 Universitaet Bielefeld
Updates:A new Request for Comments is now available in online RFC 1035 June 2000 libraries.
RFC 3123
Title: A DNS RR Type for Lists of Address Prefixes
(APL RR)
draft-ietf-dnsext-apl-rr-01.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.
Comments should be sent to the author or the DNSEXT WG mailing list
<namedroppers@internic.net>.
Abstract
Author(s): P. Koch
Status: Experimental
Date: June 2001
Mailbox: pk@TechFak.Uni-Bielefeld.DE
Pages: 8
Characters: 14648
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-dnsext-apl-rr-02.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3123.txt
The Domain Name System (DNS) is primarily used to translate domain
names into IPv4 addresses using A RRs. RRs (Resource Records). Several
approaches exist to describe networks or address ranges.
This document specifies a new DNS RR type "APL" for address prefix
lists.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
This document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [RFC2606].
2. Background
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
associate addresses and other Internet infrastructure elements with
hierarchically built domain names. Various types of resource records
have been defined, especially those for IPv4 and IPv6 [RFCxxxx]
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 product 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.
3. APL RR Type
An APL record has the DNS type of "APL" [draft, IANA: not yet applied
for] and a numeric value of [draft, IANA:to be assigned]. The APL RR
is defined in the IN class only. APL RRs cause no additional section
processing.
4. APL RDATA format
The RDATA section consists of zero or more strings (<apstring>) of
the form
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
(see IANA Considerations)
PREFIX 8 bit unsigned binary coded prefix length.
Upper and lower bounds and interpretation of
this value are address family specific.
N negation flag, indicates the presence of the
"!" character in the textual format. It has
the value "1" if the "!" was given, "0" else.
AFDLENGTH length in octets Extensions Working Group of the following address
family dependent part (7 bit unsigned).
AFDPART address family dependent part. See below.
IETF.
This document memo defines the AFDPARTs for address families 1 (IPv4) and
2 (IPv6). Future revisions may deal with additional address
families.
4.1. AFDPART for IPv4
The encoding of an IPv4 address (address family 1) follows the
encoding specified Experimental Protocol for the A RR by [RFC1035], section 3.4.1.
PREFIX specifies the number of bits of the IPv4 address starting at
the most significant bit. Legal values range from 0 to 32.
Trailing zero octets do Internet community.
It does not bear specify an Internet standard of any information (e.g. there is no
semantic difference between 10.0.0.0/16 kind. Discussion and 10/16) in an address
prefix, so the shortest possible AFDLENGTH can be used to encode it.
However,
suggestions for DNSSEC [RFC2535] a single wire encoding must be used by
all. Therefore the sender MUST NOT include trailing zero octets in
the AFDPART regardless of the value improvement are requested. Distribution of PREFIX. This includes cases in
which AFDLENGTH times 8 results in a value less than PREFIX. The
AFDPART this memo
is padded with zero bits to match a full octet boundary.
An IPv4 AFDPART has a variable length of 0 to 4 octets.
4.2. AFDPART for IPv6
The 128 bit IPv6 address (address family 2) unlimited.
This announcement is encoded in network
byte order (high-order byte first).
PREFIX specifies the number of bits of the IPv6 address starting at
the most significant bit. Legal values range from 0 sent to 128.
With the same reasoning as in 4.1 above, the sender MUST NOT include
trailing zero octets in the AFDPART regardless of IETF list and the value of
PREFIX. This includes cases in which AFDLENGTH times 8 results in a
value less than PREFIX. The AFDPART is padded with zero bits RFC-DIST list.
Requests to
match a full octet boundary.
An IPv6 AFDPART has a variable length of 0 be added to 16 octets.
5. Zone File Syntax
The textual representation of an APL RR in a DNS zone file is as
follows:
<owner> IN <TTL> APL {[!]afi:address/prefix}*
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
preceded 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
An IPv4 address in the <address> part of an <apstring> is in dotted
quad notation, just as in an A RR. The <prefix> has values deleted from the
interval 0..32 (decimal).
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>
are from the interval 0..128 (decimal).
6. APL RR usage
An APL RR with empty RDATA is valid and implements an empty list.
Multiple occurrences of the same <apstring> in a single APL RR are
allowed and MUST NOT be merged by a DNS server or resolver.
<apstrings> MUST be kept in order and MUST NOT IETF distribution list
should be rearranged or
aggregated.
A single APL RR may contain <apstrings> belonging sent to different
address families. The maximum number of <apstrings> is upper bounded
by the available RDATA space.
RRSets consisting of more than one APL RR are legal but the
interpretation is left IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the particular application.
7. Applicability Statement
The APL RR defines a framework without specifying any particular
meaning for the RFC-DIST distribution list of prefixes. It is expected that APL RRs will should
be used in different application scenarios which have sent to be
documented separately. Those scenarios RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be distinguished obtained 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 sending
an empty APL RR
o which address families are expected EMAIL message to appear in the APL RRs for
that application
o how to deal rfc-info@RFC-EDITOR.ORG with APL RR list elements which belong to other
address families, including those not yet defined
o the exact semantics of list elements negated by the "!" character
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 message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for zone data held in DNS servers.
The specification of particular application scenarios is out of the
scope of this document.
8. Examples
The following examples only illustrate some of the possible usages
outlined in special distribution should be addressed to either the previous section. None
author 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.
; 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
; 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.
9. Security Considerations
Any information obtained from the DNS should be regarded as unsafe
unless techniques specified in [RFC2535] question, or [RFC2845] 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
information and in particular the use of APL RRs to construct access
control lists.
10. IANA Considerations
This section is to be interpreted as following [RFC2434].
This document does not define any new namespaces. It uses RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the 16 bit
identifiers RFC itself, all RFCs are for address families maintained by IANA in
ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
IANA is asked to assign a numeric RR type value
unlimited distribution.echo
Submissions for APL.
11. Acknowledgements
The author would like to thank Mark Andrews Requests for his review and
constructive comments.
12. References
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989
[RFCxxxx] Crawford,M., Huitema,C., Thomson,S., "DNS Extensions to
Support IPv6 Address Aggregation and Renumbering", work in
progress
[RFC2119] Bradner,S., "Key words for use in RFCs Comments should be sent to Indicate
Requirement Levels",
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2119, BCP 14, March 1997
[RFC2181] Elz,R., Bush,R., "Clarifications 2223, Instructions 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
[RFC2434] Narten,T., Alvestrand,H., "Guidelines
Authors, for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October
1998
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
[RFC2845] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000
13. Author's Address
Peter Koch
Universitaet Bielefeld
Technische Fakultaet
D-33594 Bielefeld
Germany
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE> further information.