Summary

  • ARIN’s documented /23 example has two /24 reverse delegations; its /16 example has one /16 delegation. The registry creates the largest supported delegations for the CIDR components of a Direct Allocation, not one editing object for every subsequent customer range.
  • Shared authority excludes recipients of reassignments or reallocations from an ISP’s /16 or larger block. The condition concerns the upstream block, not merely the size received by the customer.
  • An ISP can arrange a subordinate DNS zone through its own DNS operation. That is a different handoff from granting the customer an ARIN parent-delegation permission, and it does not happen merely because a registration record was updated.

Two delegations, then one

Giving a network more addresses need not give it more separately editable reverse delegations at ARIN. The registry’s reverse-DNS guide illustrates a /23 with two /24 delegations, each able to point to its own set of nameservers. A /16, in the next example, has just one /16 delegation.

The larger holder is not less powerful overall. It controls a much larger address range. What changes is the grain at which ARIN exposes the parent-side operation. Counting addresses and counting independently managed delegation objects answer different questions.

The rule starts with a Direct Allocation. For each CIDR component in that allocation, ARIN creates the largest possible supported delegations. Its IPv4 boundaries are /8, /16 and /24, with support for CIDR-aligned blocks of /24 and larger. IPv6 uses four-bit boundaries; the IPv4 /16 exception discussed here should not be carried into that different tree.

Direct Allocation in ARIN’s examples Delegations at ARIN’s layer Nameserver choice at that layer
/23 Two /24s Separately for each /24
/16 One /16 For the /16 delegation

These are examples in current documentation checked on 3 September 2026, not a newly announced product change or measurements from customer accounts. Their practical value is that they make a hidden dependency visible before someone tries to act on it. A downstream inventory may contain many neat rows that have no matching delegation object at the registry’s layer.

The missing qualifier in “the customer can manage it”

Consider a hypothetical customer receiving a /24 from an ISP’s directly allocated /16. The customer knows its own range. It may have an organization record and a technical team ready to run nameservers. Those facts do not establish that ARIN presents a separate /24 delegation for that team to edit.

The reverse-DNS guide explicitly excludes shared authority when a reassignment or reallocation comes from the ISP’s /16 or larger block. “Larger” means more address space, not a longer numerical prefix length. Reading the condition as if it applied only to customers receiving a whole /16 would miss the hypothetical /24 inside it.

Elsewhere, the same guide describes eligible recipients jointly managing reverse DNS with their ISP through shared authority. An organization listed as authorized for a zone may manage the delegated addresses within its scope. This is a qualified operating relationship, not a universal consequence of appearing somewhere in the address hierarchy.

The distinction also has a lifecycle. ARIN tells ISPs to remove disconnected customers’ reassignment or reallocation records to remove their shared-authority rights. That is not evidence that a stale grant exists in any particular account. Nor does it turn a cleanup recommendation into permission to interrupt an active customer. It explains why an address relationship and an editing capability must be kept aligned where the capability applies.

ARIN’s broader resource-management guidance describes shared functions alongside the different management and reclaim roles of detailed reassignments and reallocations. The specific reverse-DNS qualification still matters. A general description of cooperation cannot create a separate zone at a boundary the delegation model does not expose.

An accurate registry record is only one part of the job

There is a second separation that an inventory-driven workflow can conceal. ARIN says a Network Modification changes such attributes as the network name, points of contact and public comments; it cannot change reverse-DNS delegation. Putting the correct customer in the record and directing DNS queries to the customer’s servers are different operations.

The Reg-RWS methods reinforce that distinction. Delegations appear and disappear with their associated networks rather than being independently created and deleted. They are identified by delegation names, not by NET handles. The service documents a way to obtain the delegations associated with a NET and recommends obtaining current delegation information before modifying it.

An operator therefore needs to resolve the editing object, not just locate the address record. The handle in an inventory can establish which network record is under discussion without establishing which DNS name the intended change should affect. A successful registration update does not demonstrate a completed DNS handoff.

None of these documents reproduces a particular account’s permissions for us. No ARIN account or provisioning operation was tested for this analysis. The supported claim concerns the model ARIN tells operators to use, not a finding that a named user would be denied a request today.

The next delegation can happen below ARIN

It would be equally misleading to conclude that a customer without this registry permission cannot administer its own reverse zone. DNS already provides a way to divide the work below an existing delegation.

RFC 1034 describes zone cuts and an operator’s ability to delegate subzones. The parent supplies the appropriate nameserver records and, where needed, glue; the two sides of the cut must remain consistent. The scheme does not require every subordinate zone to become a separate object in the regional registry’s account system.

For the hypothetical /24, an ISP—or the DNS service operator maintaining its /16 zone—can arrange an ordinary subordinate delegation. The customer can then maintain the child zone while the ISP retains responsibility for the parent. Giving the customer the ISP’s ARIN credentials, or control over the entire /16 delegation, is not necessary to express that arrangement in DNS.

This is a technical possibility, not evidence that a particular provider offers it. Someone must actually create the parent-side records, operate the child servers and preserve the arrangement through changes of staff or supplier. A protocol can support a division of labor without making it part of a purchased service.

The smaller-address case is another useful limit. RFC 2317 addresses ranges with fewer than 256 IPv4 addresses, using additional delegated names and CNAME links while retaining the established lookup mechanism. That flexibility does not mean ARIN accepts an arbitrary /25 delegation object. It also does not remove reliance on the parent’s records. An ordinary /24 below a /16 does not need the classless technique simply because a customer is involved.

The two errors are opposites: treating a missing registry-level control as a DNS prohibition, and treating a DNS technique as a completed provider commitment. Both skip the party that must maintain the actual parent zone.

The selected zone is part of the change

ARIN’s DNS management instructions tell users to examine the reverse zones they may modify, their nameservers, DS key tags and shared-authority organizations. A nameserver modification applies to all selected delegations and replaces the previous nameservers. Scope is therefore not an incidental detail beside the input; it determines what the input will change.

For a customer-sized request, a larger selected delegation should prompt a check of the hierarchy. It does not justify assuming that the same operation is safe because the customer’s addresses sit somewhere within it. The correct action depends on the existing zone arrangement, which these public pages do not establish for an individual network.

The guide also separates an immediate database update from visibility in DNS, which may take up to 24 hours; an unspecified TTL defaults to 86,400 seconds. Those are documented expectations, not a measured propagation result or a promise that every cache expires together. They are another reason to define the object and the observation being accepted.

The outcome to verify is modest: the intended party can maintain the intended reverse zone through an identified parent. A PTR record does not prove ownership, routing or a complete identity claim. Likewise, a customer registration is not proof of DNS independence. The documents establish no customer outage, delay distribution or financial loss. They do establish why an address handoff and a DNS handoff deserve separate answers.