RFC 3123: A DNS Prefix List Was Not an Access Policy

Summary

RFC 3123 defined an ordered DNS representation for IPv4 and IPv6 prefixes, including a negation bit, but required each application to define what negation, an empty list, multiple records and unfamiliar address families meant.
A valid or authenticated APL record was evidence that particular bytes had been published under a DNS name. It did not prove prefix control, policy authority, installation in an access-control system, enforcement or a successful service result.

DNS received a list without receiving its purpose

By 2001, DNS had long ceased to be only a telephone directory for host names. Its resource-record machinery could publish mail routes, name-server delegations and other infrastructure facts. RFC 1101 had proposed ways to describe organisational networks. Older BIND installations had even used TXT records as a weak source of address ranges for limiting access to zone data. These practices shared a problem: an address range was useful data, but its representation and its operational meaning were often entangled.

RFC 3123 separated them. Published in June 2001 as Experimental, it assigned Resource Record type 42 to APL, the Address Prefix List. An item carried an address-family identifier, a prefix length, a negation flag, a length and an address-family-dependent byte string. Families 1 and 2 meant IPv4 and IPv6. The same record could contain both.

This was a small common language, not a policy constitution. The document said so with unusual clarity: APL defined a framework without defining any particular meaning for the list. Possible uses included publishing an organisation's ranges, describing classless reverse-DNS zones and supplying material for access control. None of those examples standardized an application. None implied that an implementation existed.

That restraint matters. A DNS owner name, type code and well-formed payload can establish where a representation was found. They cannot identify the principal entitled to bind an operator, the decision rule an application applies, or the action an enforcement point actually took.

The exclamation mark was syntax before it was judgment

APL's wire format included a one-bit field named N. In zone-file syntax it recorded whether an item began with !. It is tempting to read that mark immediately as “deny,” “exclude” or “not authorized.” RFC 3123 refused that shortcut. An application specification had to state the exact semantics of a negated item.

The same was true at the boundaries. Empty RDATA was legal and represented an empty list, but the application had to say what an empty list did. Did it mean nobody, everybody, no opinion, inherit another rule or fail closed? The record could not answer. An RRset could contain more than one APL record, but their combined interpretation was again an application decision.

Even address-family evolution was left explicit rather than guessed. An application had to name the families it expected and define how it treated other or unknown families. Ignoring one, rejecting the record and preserving it for a future implementation are different operational choices. A parser that merely understands the fields has not chosen among them.

RFC 3123 therefore protected an important boundary: shared syntax should carry only what interoperable readers can verify locally. It should not smuggle a future policy into a punctuation mark.

Order and repetition were evidence, not noise

DNS servers and resolvers were told not to tidy APL data. Duplicate items were permitted and must not be merged. Items had to stay in order and must not be rearranged or aggregated. Those requirements look inefficient only if the list is assumed to be a mathematical set. RFC 3123 did not make that assumption because a future application might attach meaning to sequence or repetition.

The rule preserved the publisher's statement without pretending to understand it. A server transported an ordered representation; an application interpreted that representation. If an intermediary collapsed two entries, sorted them or combined adjacent prefixes, it could change a policy whose semantics it had never been authorized to know.

At the byte level, however, RFC 3123 did require one kind of normalization. Trailing zero octets carried no prefix information and had to be omitted from the address part. That produced a single wire encoding for semantically equivalent IPv4 or IPv6 prefixes, important to the DNSSEC canonicalization model cited at the time. Canonical bytes solve a comparison and signing problem. They do not solve the meaning of the signed list.

This is the distinction between deterministic representation and discretionary consequence. Canonicalization lets two verifiers agree on what data was signed. It does not tell either verifier whether the item grants access, announces allocation, describes a reverse zone or has no effect at all.

Security could protect the statement, not complete it

RFC 3123 warned that DNS information should be considered unsafe unless protected through the DNSSEC or TSIG techniques it referenced. It also warned that publishing topology could disclose useful information and that constructing access-control lists from APL data could compromise security.

The two warnings point in different directions. Origin and integrity matter because an attacker who changes a prefix list can change what a relying application sees. Yet authenticity is not authorization. DNSSEC can help show that data came through a signed DNS chain and was not altered. TSIG can authenticate a DNS message or transaction between configured parties. Neither decides whether the zone operator had authority to set a firewall rule, whether the application used the current record, or whether a packet later passed.

An operational chain would require more receipts: the queried owner name and RRset, validation state and time, the application specification and version, the local configuration choosing that application, the compiled policy, the enforcement-point acknowledgment, and the observed traffic result. Skipping from the first record to the last outcome turns published data into imaginary control.

The historical temptation was understandable. DNS was already distributed, cached and administratively delegated. Reusing it to publish prefix material was economical. But distribution of a statement is not distribution of decision authority. A zone administrator can publish bytes; a different operator still decides whether those bytes govern its system.

Type 42 did not prove a deployment

The RFC's examples are vivid: an organisation's address ranges, classless reverse zones, a zone-transfer restriction and multicast ranges. They are explanatory records under example names. The document explicitly says they do not specify those applications and do not imply that any APL-based application existed or would exist.

Experimental status also carries no deployment receipt. It records the document's standards category in 2001. The later publication of RFC 3597, which described how DNS implementations handle unknown resource-record types, helps explain how new types could cross software that did not understand them. It does not show that APL was used, ignored or successful in a named network. RFC 4034's later DNSSEC rules likewise clarify signed-record handling without giving APL universal semantics.

A responsible history therefore stops at what the sources establish. RFC 3123 created an extensible container with carefully preserved order, duplicates, family identity and compact prefix bytes. It left application meaning outside the container. Any claim about adoption, operational value or failure needs separate implementation or deployment evidence.

The durable lesson was a narrow common layer

APL can be read as a miniature exercise in constitutional restraint. The common format specified only enough to exchange a list without corrupting it. Future applications remained free to define their own owner-name convention, empty-list behavior, RRset combination, family policy and negation semantics. Operators remained free to adopt those applications or not.

That design did not eliminate risk. It made the location of risk visible. A record could be authentic yet stale. An application could be specified yet locally misconfigured. A compiled ACL could be installed yet attached to the wrong interface. An enforcement point could accept it while traffic followed another path. Each transition needed its own observation.

The easiest historical error is to collapse the chain because every stage uses the same prefixes. The prefix in DNS, the prefix in an application model, the prefix in an ACL, the prefix matched by a packet and the prefix named in an incident report may be textually identical while belonging to different authorities and times.

RFC 3123's quiet achievement was not to make DNS rule the network. It gave DNS a precise way to carry address-prefix material while admitting that the record itself was not the ruler.

A Prefix List Was Not Yet an Access Policy: RFC 3123

Why it matters

Summary

DNS received a list without receiving its purpose

The exclamation mark was syntax before it was judgment

Order and repetition were evidence, not noise

Security could protect the statement, not complete it

Type 42 did not prove a deployment

The durable lesson was a narrow common layer

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing