A DNS RR Type for Lists of Address Prefixes (APL RR)
RFC 3123
|
Document |
Type |
|
RFC - Experimental
(June 2001; No errata)
|
|
Author |
|
Peter Koch
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 3123 (Experimental)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group P. Koch
Request for Comments: 3123 Universitaet Bielefeld
Category: Experimental June 2001
A DNS RR Type for Lists of Address Prefixes (APL RR)
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The Domain Name System (DNS) is primarily used to translate domain
names into IPv4 addresses using A 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
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 [RFC2874]
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.
Koch Experimental [Page 1]
RFC 3123 DNS APL RR June 2001
3. APL RR Type
An APL record has the DNS type of "APL" and a numeric value of 42
[IANA]. 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 items (<apitem>) 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 of the following address
family dependent part (7 bit unsigned).
AFDPART address family dependent part. See below.
This document 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 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 not bear any information (e.g., there is no
semantic difference between 10.0.0.0/16 and 10/16) in an address
prefix, so the shortest possible AFDLENGTH can be used to encode it.
However, for DNSSEC [RFC2535] a single wire encoding must be used by
Koch Experimental [Page 2]
RFC 3123 DNS APL RR June 2001
all. Therefore the sender MUST NOT include trailing zero octets in
the AFDPART regardless of 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 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) is encoded in network
byte order (high-order byte first).
Show full document text