Reverse DNS: in-addr.arpa and ip6.arpa

$ dig @1.1.1.1 -x 198.51.100.53

The in-addr.arpa tree (IPv4)#

The IPv4 address 198.51.100.53 becomes the DNS name:

53.100.51.198.in-addr.arpa
 |   |   |   |  +--------- the reverse-DNS root for IPv4
 |   |   |   +------------ most-significant octet
 |   |   +---------------- next octet
 |   +-------------------- next octet
 +------------------------ least-significant octet (the host)

Reversing the octets lets the DNS hierarchy walk the same way it does for forward names: most-general on the right, most-specific on the left. The root delegates arpa, which delegates in-addr.arpa, which delegates 198.in-addr.arpa, and so on. For RFC 1918 private space (10/8, 172.16/12, 192.168/16) the public tree dead-ends on purpose: IANA delegates those reverse zones to the AS112 blackhole servers, which serve them as empty zones: SOA and NS at the zone name itself, NXDOMAIN for every address inside it. RFC 6303 tells recursive resolvers to serve the same empty zones out of their own data, so NXDOMAIN for a name inside the block arrives without anyone being asked. On a private network, stand up your own reverse zone.

The shorthand form, letting dig handle the name reversal:

dig @1.1.1.1 -x 198.51.100.53

What it actually sends on the wire:

dig @1.1.1.1 53.100.51.198.in-addr.arpa PTR

198.51.100.x is one of the three RFC 5737 documentation prefixes (TEST-NET-2). Nobody publishes PTRs in it, and RFC 6303 section 4.2 lists 100.51.198.in-addr.arpa as a locally served zone, so a resolver returns NXDOMAIN for these names out of its own empty zone instead of walking the tree. They are shown here only to illustrate the name format. For a live working example, see Quick check below.

The query sends a PTR query and returns a PTR record. Every reverse zone also requires an SOA at the apex and NS records, the same as any other zone. For classless sub-range delegations (RFC 2317), the parent /24 zone also uses CNAME records to redirect individual host queries to the delegated sub-zone.

The ip6.arpa tree (IPv6)#

Same idea, with twice as much pain. Each IPv6 address is 128 bits = 32 hex nibbles, and reverse DNS encodes one nibble per label, in reverse order. The address 2001:db8::1 becomes:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Yes really. Thirty-two single-character labels, plus ip6.arpa. dig -x builds this for you; nobody types it by hand.

The shorthand form (using the RFC 3849 documentation prefix to illustrate the format):

dig @1.1.1.1 -x 2001:db8::1

What hits the wire:

dig @1.1.1.1 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa PTR

2001:db8:: is the RFC 3849 documentation prefix. It has no reverse zone, so both commands return NXDOMAIN. These are shown to illustrate the nibble format, not as live lookups. For a working IPv6 PTR example, see the ptr page.

Two rules:

1. One nibble per label. Not one hex-byte (two nibbles) per label. One nibble.
2. Reversed nibble order. Most-significant nibble of the original address ends up on the right.

Delegation: who's authoritative for what#

For IPv4:

For IPv6 the analogous split applies. ULA space (fc00::/7) is yours to host; public allocations are usually delegated by your RIR.

The categorization of public, private, and documentation addresses is summarized at the addresses you'll meet.

RFC 2317: classless reverse delegation#

If your ISP delegates a /26 to you, the classful reverse zone (x.y.z.in-addr.arpa: a /24) doesn't line up. RFC 2317 defines a CNAME-based trick to delegate a sub-range. You don't need this for RFC 1918 space; you do need it for a small public allocation.

Quick check that reverse is working#

Pick an IP with a known PTR record. Cloudflare's 1.1.1.2 works reliably, and unlike 1.1.1.1 its reversal is visible (1.1.1.2 becomes 2.1.1.1.in-addr.arpa):

dig @1.1.1.1 -x 1.1.1.2 +short

security.cloudflare-dns.com.

See ptr for the same lookup with nslookup and DNS-over-HTTPS.

Failure modes to distinguish:

• NXDOMAIN: no PTR is provisioned for that IP, or no reverse zone is delegated for its range (RFC 1035 section 4.1.1, RCODE 3). (Also what you get for RFC 1918 and documentation addresses, per the delegation table above.)
• SERVFAIL: the reverse zone delegation is broken (missing or misconfigured NS/glue), DNSSEC validation failed, or the resolver gave up trying to reach the authoritative servers.
• Timeout: your query never got any answer at all, which points at the path between you and the resolver, not the authoritative side. Start at the L3 path to the resolver.

See also#

• All record types: the cheat sheet
• Anatomy of a DNS query: including reverse lookups