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.


   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",
   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

      |                          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

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 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