DNS APL: A DNS RR Type for Lists of Address Prefixes (APL RR)
A DNS record type for publishing lists of IPv4 and IPv6 address prefixes.
Koch, P., "A DNS RR Type for Lists of Address Prefixes (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, <https://www.rfc-editor.org/info/rfc3123>.
@misc{rfc3123,
series = {Request for Comments},
number = 3123,
howpublished = {RFC 3123},
publisher = {RFC Editor},
doi = {10.17487/RFC3123},
url = {https://www.rfc-editor.org/info/rfc3123},
author = {P. Koch},
title = {{A DNS RR Type for Lists of Address Prefixes (APL RR)}},
pagetotal = 8,
year = 2001,
month = jun,
} RFC text
Contents
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.
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
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).
PREFIX specifies the number of bits of the IPv6 address starting at
the most significant bit. Legal values range from 0 to 128.
With the same reasoning as in 4.1 above, 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 IPv6 AFDPART has a variable length of 0 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 <apitem> is in dotted
quad notation, just as in an A RR. The <prefix> has values 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
<apitem> 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 <apitem> in a single APL RR are
allowed and MUST NOT be merged by a DNS server or resolver.
<apitems> MUST be kept in order and MUST NOT be rearranged or
aggregated.
A single APL RR may contain <apitems> belonging to different address
families. The maximum number of <apitems> is upper bounded by the
available RDATA space.
RRSets consisting of more than one APL RR are legal but the
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
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 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 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.
; RFC 1101-like announcement of address ranges for foo.example
foo.example. IN 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. IN 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. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
; List of address ranges for multicast
multicast.example. IN 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 <apitems> is three.
9. Security Considerations
Any information obtained from the DNS should be regarded as unsafe
unless techniques specified in [RFC2535] 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 the 16 bit
identifiers for address families maintained by IANA in
http://www.iana.org/numbers.html.
The IANA assigned numeric RR type value 42 for APL [IANA].
11. Acknowledgements
The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
and constructive comments.
12. References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
BCP 32, RFC 2606, June 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[IANA] http://www.iana.org/assignments/dns-parameters
13. Author's Address
Peter Koch
Universitaet Bielefeld
Technische Fakultaet
D-33594 Bielefeld
Germany
Phone: +49 521 106 2902
EMail: pk@TechFak.Uni-Bielefeld.DE
14. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1The APL Record Type
The APL (Address Prefix List) RR is a new DNS resource record type assigned the numeric value 42 by IANA. It allows DNS to store lists of IP address prefixes, where each prefix represents a range of addresses. Unlike the A record (which stores a single IPv4 address) or AAAA record (which stores a single IPv6 address), APL can hold multiple prefixes in one record.
APL records are defined only for the Internet class (IN) of DNS records. An APL record with empty content is valid and represents an empty list. Multiple APL records can exist for the same domain name, and their interpretation is left to the application using them.
APL is a new type of entry in the DNS phone book. Instead of writing down one phone number, you can write down a range of them, like "all numbers from 555-0100 to 555-0199 belong to the sales department."
§2The APL Data Format
Each APL record contains zero or more items. Each item specifies an address family (identified by a 16-bit number assigned by IANA; 1 for IPv4 and 2 for IPv6), a prefix length (the number of bits to match), a negation flag (to exclude a range instead of including it), and the actual address bytes. For IPv4, the address part is 0 to 4 octets; for IPv6, it is 0 to 16 octets. Trailing zero octets are omitted to save space.
The items in an APL record MUST be kept in order and MUST NOT be rearranged or merged by DNS servers. This preserves the semantics defined by the application using the record. For example, an access control list might rely on the order of rules.
Each item in the list tells you whether to include or exclude a range of addresses. You write the first bits of the address, and the prefix length tells you how many bits matter.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
FAMILY | Address Family | 2 bytes | IANA-assigned family number: 1 for IPv4, 2 for IPv6. | |
PREFIX | Prefix Length | 1 byte | Number of bits in the address part (0-32 for IPv4, 0-128 for IPv6). | |
NEGATION | Negation | 1 bits | 1 if this item is negated (excluded), 0 if included. | |
AFDLEN | AFD Length | 7 bits | Number of octets following (0 to 4 for IPv4, 0 to 16 for IPv6). |
§3Writing and Reading APL Records
In a DNS zone file, an APL record is written as example.com. IN APL 1:192.168.0.0/24 2:2001:db8::/32. The 1: prefix denotes an IPv4 address family, and 2: denotes IPv6. The address and slash-prefix syntax mirrors CIDR notation. A negation is written by preceding the item with an exclamation mark: !1:10.0.0.0/8 means exclude the 10.0.0.0/8 range.
The RFC provides example APL records for various uses: publishing an organization's address ranges (like RFC 1101 did with TXT records), describing zones covered by classless delegation, restricting DNS zone transfers to certain IP ranges, and grouping multicast addresses. Each application must define what the prefix list means in its context.
You write the addresses using a simple text format, with a number and slash to show how many bits matter. A `!` in front means "not this one."
§4How Applications Use APL
APL defines a framework but not specific meanings. The RFC states that any application using APL records MUST include documentation on how to interpret them. This includes what the prefix list means, how to handle negations, what to do with empty lists, which address families are expected, and how to treat address families not yet defined.
Security concerns arise because APL can disclose network topology information. Using APL to construct access control lists could expose internal network structure to potential attackers. Applications using APL should weigh this risk and apply appropriate DNS security measures like DNSSEC or TSIG (transaction signature).
Different applications can use APL for different purposes. Each one has to explain what the list means and how to use it safely.
§5Deployment and Status
RFC 3123 is experimental. APL records have seen limited adoption, as the specific application semantics have not been widely standardized. DNSSEC deployments in some regions have defined how to use APL for publishing delegation signer (DS) records in a machine-readable format, but broader adoption has remained limited.
The record type is registered and available in DNS implementations that support it, but applications must define their own interpretation and handling rules. The flexibility of the format—allowing any application to define its own semantics—is both a strength (general-purpose) and a weakness (no standard semantics, limiting interoperability).
APL exists and you can use it, but there is no widespread agreement on what the lists should mean in most applications, so it has not become common.