Summary

  • RFC 5855 gave the IPv4 and IPv6 reverse zones dedicated nameserver namespaces and parent-zone glue, so the two services could be operated on separate server sets.
  • The RFC does not require that separation: it assigns operator choice to an IANA function. Different names alone do not prove different routes, sites, or failure exposure.

A reverse lookup starts with an address, but it cannot reach the name attached to that address until a resolver finds the authoritative servers for the relevant reverse zone. That discovery step has its own dependencies. If a resolver cannot find the address of a zone’s nameserver, it can fail before it ever asks for the PTR record.

That was the practical problem behind RFC 5855, Nameservers for IPv4 and IPv6 Reverse Zones. Published as a Best Current Practice in May 2010, it was jointly authored by Joe Abley and Terry Manderson. The RFC records the arrangement that existed when it was written: a subset of the root servers served IN-ADDR.ARPA, while IP6.ARPA was served by systems operated by APNIC, ARIN, ICANN, LACNIC, and the RIPE NCC.

The proposal gave each reverse zone its own stable nameserver namespace. IPv4 servers would be named beneath IN-ADDR-SERVERS.ARPA; IPv6 servers beneath IP6-SERVERS.ARPA. The parent ARPA zone would carry the IPv4 and IPv6 glue records needed to reach those names. That moves the resolver’s first step into a zone that already supplies the parent referral, rather than making it discover the address of an IPv6 reverse server through another round of recursive resolution.

This matters because a nameserver referral is useful only if the resolver can continue along it. The RFC’s query examples show that the earlier IP6.ARPA delegation could arrive without additional-section glue. A resolver then had to look up one of the listed nameservers before querying the reverse zone. RFC 5855’s dedicated names and ARPA glue make that dependency explicit and easier to operate. The change is modest on paper; it affects the path that every reverse lookup must traverse.

The RFC also treated encoding cost as an operational detail. Its appendix compares the historical IPv6 reverse-zone server names with the proposed names: the encoded NS-name labels occupy 74 bytes in the former example and 39 in the latter. That is a wire-format comparison, not a measured reduction in latency or failed lookups. The design lets DNS compress repeated suffixes in a frequently queried referral, while making the server-address path clearer.

The names were also intended to permit a stronger separation. RFC 5855 says the IPv4 and IPv6 reverse zones may be delegated to two different nameserver sets, helping prevent a failure in one family from damaging lookups in the other. But it does not require the sets to use different operators, sites, transit providers, or upstream routes. The RFC even says the nameserver namespace and its corresponding reverse zone may share fate within each family. A separate label is a choice the system can use, not a guarantee that two physical or routing failures will remain independent.

The document is unusually direct about who owns the remaining choice. Its IANA section records the new delegations and glue. The choice of operators, it says, is outside the RFC’s scope and is an IANA function under the IETF–ICANN Memorandum of Understanding. RFC 5855 therefore specifies a technical surface and a handoff; it does not turn the standard’s design into a claim about who ran each server or how independent those servers were in practice.

Manderson’s role is documented on both sides of that seam. He coauthored the RFC, and the IETF Datatracker lists it among his RFCs. A later RSSAC history records that he took over management of ICANN’s DNS Operations Department in 2013; in 2014, the team moved into ICANN IT and became DNS Engineering. An ICANN interview identifies him as its director. These records establish operational experience, not that Manderson alone designed, selected, or deployed the RFC’s operators.

That limit makes the RFC more useful as evidence. It separates what the protocol can name from what the operator arrangement must decide. To know whether IPv4 and IPv6 reverse DNS actually fail separately, an engineer needs the live NS sets, glue, hosting, routes, and response behavior—not just two suffixes in a standard.

Sources