RFC 3123

A DNS RR Type for Lists of Address Prefixes (APL RR)

📅 published June 2001, from ietf

RFC 3123: A DNS RR Type for Lists of Address Prefixes (APL RR) 🦋

okay bestie, this one is from June 2001 and it's by Peter Koch at Universitaet Bielefeld 💖 It's filed under Network Working Group, in the Experimental category, so it's basically "we're trying something new, tell us what you think" energy 🧪 The title block has no Obsoletes or Updates line, so this doc doesn't replace or change any other RFC 🌸 It defines a DNS record type called APL for lists of address prefixes, and it covers both IPv4 and IPv6 🔥

Status of this Memo 💅

this memo defines an Experimental Protocol for the Internet community 🧪 it does not specify an Internet standard of any kind. they're literally asking for discussion and suggestions for improvement, and distribution of the memo is unlimited ✨

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

Abstract 🫶

the Domain Name System (DNS) is mostly used to turn domain names into IPv4 addresses, using A RRs (Resource Records) 📇 there are already a few ways to describe networks or address ranges, but this doc introduces a brand new DNS RR type called "APL" for address prefix lists 🎀

1. Conventions used in this document ✨

okay so here's the bestie-approved list of requirement words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" all mean exactly what [RFC2119] says they mean 🤓 no cap, these matter.

domain names in here are just for explanation 🙈 they should not be expected to lead anywhere useful in real life [RFC2606].

2. Background 📚

the Domain Name System [RFC1034], [RFC1035] links addresses and other internet infrastructure stuff to hierarchically built domain names 🌳 lots of resource record types exist, especially for IPv4 and IPv6 [RFC2874] addresses. [RFC1101] describes a way to publish info about the address space given to an organisation 📣 and in older BIND versions, a weak way to control access to zone data was done with TXT RRs describing address ranges 💀

this doc specifies a new RR type for address prefix lists, and it's giving main character energy 👑

3. APL RR Type 🎀

an APL record has the DNS type "APL" and a numeric value of 42 [IANA] 🔢 the APL RR is only defined in the IN class, and APL RRs cause no additional section processing. literally nothing extra to chase 💅

4. APL RDATA format 💜

the RDATA section is zero or more items (<apitem>) that look like this 🧩

      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |                          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 doc defines AFDPARTs for address families 1 (IPv4) and 2 (IPv6) ✨ future revisions might cover more address families 🔮

4.1. AFDPART for IPv4 🌸

an IPv4 address (address family 1) is encoded the same way the A RR encodes it, following [RFC1035], section 3.4.1 🫧

PREFIX counts how many bits of the IPv4 address are used, starting from the most significant bit. legal values run from 0 to 32.

trailing zero octets carry no info. like, there's zero semantic difference between 10.0.0.0/16 and 10/16 🤯 so you could use the shortest possible AFDLENGTH. BUT for DNSSEC [RFC2535], everyone has to use one single wire encoding. so the sender MUST NOT include trailing zero octets in the AFDPART, no matter what PREFIX is 🚫 this still applies when AFDLENGTH times 8 comes out smaller than PREFIX. the AFDPART gets padded with zero bits to hit 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, which means high-order byte first 🧠

PREFIX counts the bits of the IPv6 address starting from the most significant bit. legal values run from 0 to 128.

same logic as 4.1 above 🫶 the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value of PREFIX. this includes cases where AFDLENGTH times 8 comes out less than PREFIX. the AFDPART gets 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 🧚

this is what an APL RR looks like in a DNS zone file 📝

<owner>   IN   <TTL>   APL   {[!]afi:address/prefix}*

the data is zero or more strings. each one starts with the address family indicator <afi>, then a colon ":", then an address, then the "/" character, then a decimal prefix length. any string can have a "!" in front of it. the strings are separated by whitespace. and the <afi> is just the decimal value of that address family 💖

5.1. Textual Representation of IPv4 Addresses 🍓

an IPv4 address in the <address> part of an <apitem> uses dotted quad notation, same as an A RR 🔢 the <prefix> runs from 0 to 32 in decimal.

5.2. Textual Representation of IPv6 Addresses 💜

the way an IPv6 address shows up in the <address> part of an <apitem> follows [RFC2373], section 2.2 ✨ legal <prefix> values are from 0 to 128 in decimal, so the range is 0..128 (decimal) 🌈

Okay bestie, the legal bit. 📜 Copyright (C) The Internet Society (2001). All Rights Reserved. 💖

So you can copy this doc and share it with people, and you can make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work. 🦋

What you can't do is modify this document itself. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can change it when you're developing Internet standards (and then the Internet Standards process copyright procedures must be followed 🧚), or when you need to translate it into a language other than English. 🌈

The permissions above are perpetual. The Internet Society and its successors or assigns will never revoke them. Iconic, honestly. 👑

Now the disclaimer, which is not as fun but is important 💀:

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

Shoutout to the people funding the RFC Editor function! 🫶 Right now that funding comes from the Internet Society. ⭐

📦 where this page comes from