Summary

  • RFC 2317 let a parent IPv4 reverse zone redirect each address query with a CNAME into a separately administered child zone for a non-octet-aligned block.
  • The child could maintain PTR data, while the parent still controlled the aliases and delegation that made the child reachable.
  • A working reverse answer did not prove address allocation, parent-change authority, route origination, forward-DNS control, mail authentication, reputation, reachability or application success.

Ask for the PTR of 192.0.2.129. The ordinary reverse name is 129.2.0.192.in-addr.arpa. In RFC 2317’s example, the server for the parent zone does not answer with the final host name. It answers with a CNAME pointing at 129.128/26.2.0.192.in-addr.arpa. A resolver follows that target to the separately served 128/26 child zone and retrieves the PTR there.

The two answers record two different acts. The parent says where this address-shaped name should continue. The child says which PTR it publishes at the target. Neither record contains an IPv4 allocation instrument, a legal title, a route authorisation or a service receipt.

That separation solved a real 1998 problem. IPv4 reverse delegation naturally followed octet boundaries. A conventional 2.0.192.in-addr.arpa zone covered all 256 addresses in 192.0.2.0/24 and could be delegated only once. Classless allocation could divide that /24 into a /25 and two /26s, but DNS had no ordinary zone cut at bit 25 or 26. Without another mechanism, one organisation would administer PTRs for everyone inside the parent zone.

RFC 2317 introduced extra names below the parent. In its worked example the parent delegates synthetic zones called 0/25, 128/26 and 192/26. It then installs a CNAME for each address pointing into the relevant child. The child’s own authoritative servers hold the PTR records. The slash is not a prefix object interpreted by the resolver; it is part of a DNS label chosen by convention. The RFC even permits other labels and targets elsewhere in the DNS tree.

This was an interoperability bargain. Existing resolvers already knew how to follow CNAMEs, so the query algorithm did not need to change. The parent paid with a large generated record set—close to 256 CNAMEs for a split /24—and the parties paid with an extra dependency. The RFC recommended that parent-zone servers also serve as secondaries for the child zones because some older servers could return only the CNAME when they did not already know the target data.

The design also had a stopping rule. The same trick should not be applied again after the first classless split. Delegating a /25 this way and then repeating the method for smaller pieces could create a CNAME pointing to another CNAME and reduce robustness. Administrative granularity was gained, but not without a limit.

The RFC’s claim about operation was careful. Its authors said the technique had been used for several years in many installations, apparently without ill effects. That is contemporaneous evidence that the convention was not merely paper. It is not a deployment census, proof of every implementation, or a guarantee about a modern resolver, registry or hosted DNS platform.

Most overclaiming begins after a PTR appears. Reverse DNS maps an address to a name; forward DNS maps a name to an address. RFC 1912 recommended matching PTR and A records precisely because they are separate records that can drift. Agreement improves operational coherence. It does not authenticate a person, corporation or service.

Routing authority lives elsewhere. RFC 6480 describes resource certificates and Route Origin Authorisations: a ROA explicitly and verifiably states that an autonomous system is authorised to originate routes for prefixes. An RFC 2317 CNAME does not carry an AS number, prefix authorisation or certificate chain. Even a ROA remains an input to routing policy; the reverse answer says nothing about BGP acceptance, propagation or packet forwarding.

Mail adds further independent checks. A PTR can matter to an operator, and RFC 1912 warned that missing or mismatched records could cause services to refuse communication. But SPF evaluates sending-domain policy, DKIM validates a domain signature on message content, and DMARC evaluates alignment and policy using SPF or DKIM results. A clean PTR supplies none of those results and says nothing about historical reputation or a receiver’s final disposition.

The same boundary applies to service availability. A PTR may name a host that is powered off, filtered, unrouted, misconfigured or fictional. A resolver can return the exact configured answer while no packet reaches the address. DNS success is evidence about naming state at an observation time. It is not evidence that a socket opened or an application completed work.

RFC 2317 therefore matters as a compact lesson in layered authority. It let the operator of a small address range maintain reverse names without asking the parent to edit every PTR. Yet every lookup still depended on the parent retaining the correct CNAMEs and delegation. The child gained a naming surface, not the parent’s credentials or every other control plane attached to the address.