How rDNS Delegation Works: RIPE, ARIN, and APNIC Explained

An ISP doesn't own its in-addr.arpa zones outright - it holds them on delegation from whichever Regional Internet Registry allocated its address space. Getting that delegation right, and knowing what to do when an allocation doesn't line up with a DNS zone boundary, is a prerequisite most PTR guides skip. This one covers it directly: how delegation works mechanically, how RIPE NCC, ARIN, and APNIC each hand it off, and what to do when your allocation is smaller than a /24.

The Mechanics of Reverse Delegation

Every IPv4 block traces back to a reverse zone in in-addr.arpa. The RIR that allocated your block is authoritative for the parent of that zone. To delegate it to you, the RIR publishes NS records pointing at your nameservers - the same mechanism used for forward DNS delegation, just applied to the reverse tree.

Before the RIR will do this, your nameservers need to already be authoritative for the zone and answering correctly. If they aren't - wrong SOA, missing NS records on your side, or nameservers that don't respond - the RIR will either reject the delegation request or create a "lame delegation": a zone cut that points at servers unable to answer for it. Lame delegations are a common, quiet cause of PTR lookups failing for reasons that have nothing to do with the PTR record itself.

Delegation Through RIPE NCC, ARIN, and APNIC

The underlying DNS mechanism is identical across registries. What differs is the administrative interface:

RIPE NCC (Europe, Middle East, parts of Central Asia)

LIRs manage reverse delegation through the RIPE Database by maintaining a domain object tied to the allocation, with nserver attributes listing the authoritative nameservers. The delegation activates once the object is saved and your nameservers answer correctly - no separate approval step.

ARIN (North America)

ARIN handles reverse delegation through ARIN Online, where an org account holder creates a reverse DNS record tied to the specific CIDR block and lists the nameservers. ARIN validates the servers are reachable and authoritative before publishing.

APNIC (Asia-Pacific)

APNIC members manage the equivalent object through the MyAPNIC portal. Same rule applies: the delegation only takes effect once your side is verifiably ready to answer for the zone.

The /24 Boundary Problem

Classic in-addr.arpa delegation was designed around octet boundaries, because each label in a reverse DNS name corresponds to one octet of the address. That means a clean zone cut - one you can delegate with a plain NS record - only exists at /8, /16, and /24. An ISP that receives a full /24 or larger can be delegated its zone directly, no complications.

The problem shows up when an allocation is smaller than a /24 - a /27, /28, or /29, common for smaller ISPs, downstream customers of a larger provider, or hosting blocks handed out in small chunks. There's no natural zone boundary at /27, so you can't cleanly delegate "the last 32 addresses of a /24" with a plain NS record - the parent zone still owns the full /24 as a single label set.

RFC 2317: Classless in-addr.arpa Delegation

RFC 2317, Classless IN-ADDR.ARPA delegation, solves this with an indirection trick rather than a new DNS mechanism. Say an upstream provider owns 203.0.113.0/24 and needs to delegate 203.0.113.32/27 (addresses .32-.63) to a downstream ISP. In the parent zone, the upstream adds a CNAME for every address in that range, pointing to a differently-named subdomain:

32.113.0.203.in-addr.arpa.   IN  CNAME  32.32-27.113.0.203.in-addr.arpa.
33.113.0.203.in-addr.arpa.   IN  CNAME  33.32-27.113.0.203.in-addr.arpa.
...
63.113.0.203.in-addr.arpa.   IN  CNAME  63.32-27.113.0.203.in-addr.arpa.

The upstream then delegates that subdomain with a standard NS record:

32-27.113.0.203.in-addr.arpa.   IN  NS  ns1.downstream-isp.net.
32-27.113.0.203.in-addr.arpa.   IN  NS  ns2.downstream-isp.net.

The downstream ISP hosts 32-27.113.0.203.in-addr.arpa and puts ordinary PTR records inside it. A reverse lookup for 203.0.113.45 follows the CNAME first, then resolves the PTR in the delegated zone - transparent to the lookup, but dependent on the parent zone holder adding those CNAME and NS records correctly.

Delegation Checklist

1. Stand up authoritative nameservers first - correct SOA and NS records, answering before you request delegation
2. Match records on both sides - NS records at the RIR (or upstream) must match what your own zone declares
3. Use RFC 2317 for sub-/24 blocks - confirm your upstream is delegating via the CNAME/NS pattern, not leaving records in their own zone
4. Verify after every change - dig NS <zone>.in-addr.arpa against the RIR's resolvers, not just your own, to catch lame delegations early
5. Recheck after renumbering - block transfers are a frequent, easy-to-miss source of delegation drift

A handful of allocations can be tracked by memory. An ISP holding blocks across multiple RIRs, some direct and some sub-delegated under RFC 2317, needs a system that records which zones are delegated where and flags lame delegations - rather than discovering a broken one from a customer's support ticket.

Related reading: Why rDNS Matters, IPv6 Reverse DNS, PTR Records and Deliverability, and Bulk PTR Management.