How Reverse DNS Works: PTR Records and in-addr.arpa

Forward DNS resolves names to addresses: mail.example.com → 203.0.113.42. Reverse DNS runs in the opposite direction — given an IP address, return a hostname. The mechanism is a PTR (pointer) record looked up in a special DNS zone, and its correct operation matters for email deliverability, network troubleshooting, and a handful of legacy authentication schemes. Understanding how reverse DNS is delegated — and who controls it for which address ranges — requires understanding in-addr.arpa and its IPv6 equivalent.

PTR Records and the in-addr.arpa Zone

DNS is a hierarchical namespace. Reverse DNS fits into that namespace by treating IP addresses as names under the in-addr.arpa top-level domain. An IPv4 address is written in reverse octet order and appended with .in-addr.arpa. to form the query name.

For the address 203.0.113.42:

Query name: 42.113.0.203.in-addr.arpa.
Record type: PTR
Answer: mail.example.com.

The reversal is necessary to make the hierarchy match the way address space is allocated. In a normal domain name, the most specific part (the hostname) is on the left and the least specific (the TLD) is on the right. IP addresses, written left to right, have the most general part (the network) on the left. Reversing the octets aligns IP allocation hierarchy with DNS delegation hierarchy: a block like 203.0.113.0/24 maps neatly to the zone 113.0.203.in-addr.arpa, which can be delegated as a unit.

IPv6 Reverse DNS: ip6.arpa Nibble Format

IPv6 uses a similar mechanism under ip6.arpa, but instead of reversing octets, every individual hex digit (nibble) is separated by a dot and the full 128-bit address is expanded to 32 nibbles before reversal.

Working example for 2001:db8::1:

1. Expand to full form: 2001:0db8:0000:0000:0000:0000:0000:0001
2. Remove colons, list all 32 hex digits: 20010db8000000000000000000000001
3. Separate every digit with a dot: 2.0.0.1.0.d.b.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1
4. Reverse the sequence and append .ip6.arpa.:
   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.

This nibble format gives delegations that correspond to /4 through /128 prefix lengths, in multiples of 4 bits. A /48 allocation (the typical site prefix) corresponds to 12 nibble labels, making delegation clean and predictable.

How RIRs and ISPs Delegate Reverse Zones

The five Regional Internet Registries control the top-level reverse zones for their allocated address space. ARIN manages the reverse zones for addresses it has allocated to North American organizations; RIPE NCC manages those for European allocations, and so on. When an RIR allocates a block like 203.0.113.0/24 to an ISP, it creates NS records in its in-addr.arpa zone delegating 113.0.203.in-addr.arpa to the ISP's nameservers. The ISP can then create PTR records for every address in that /24, or further delegate sub-zones to its customers.

When an enterprise receives a block from its upstream ISP rather than directly from an RIR, the ISP controls the parent zone. The enterprise must ask the ISP to either configure PTR records on its behalf, or to delegate the reverse zone to the enterprise's own nameservers.

Classless Reverse Delegation (RFC 2317)

A problem arises when an allocation is smaller than a /24. Reverse DNS zones naturally align on octet boundaries — 113.0.203.in-addr.arpa covers all 256 addresses from 203.0.113.0 to 203.0.113.255. If an ISP gives a customer only 203.0.113.128/26 (64 addresses), there is no natural DNS zone boundary to delegate.

RFC 2317 defines a convention for classless delegation using CNAME records. The ISP creates a sub-zone named with the network/prefix notation (e.g., 128/26.113.0.203.in-addr.arpa), delegates it to the customer's nameservers, and then adds CNAMEs in the /24 parent zone pointing each address to the delegated sub-zone:

; In ISP zone: 113.0.203.in-addr.arpa
128  CNAME  128.128/26.113.0.203.in-addr.arpa.
129  CNAME  129.128/26.113.0.203.in-addr.arpa.
...
191  CNAME  191.128/26.113.0.203.in-addr.arpa.

; Customer nameservers serve: 128/26.113.0.203.in-addr.arpa
128.128/26.113.0.203.in-addr.arpa.  PTR  host1.customer.example.
129.128/26.113.0.203.in-addr.arpa.  PTR  mail.customer.example.

The convention is widely supported by DNS software, but the zone names with slashes can cause issues with some older implementations that do not expect non-standard characters in zone names.

Forward-Confirmed Reverse DNS (FCrDNS)

Many mail servers require that a connecting IP address have a PTR record, and that the name in the PTR record resolves forward (A/AAAA query) back to the same IP address. This is called forward-confirmed reverse DNS (FCrDNS) or sometimes "double-checked reverse DNS." The check is a basic anti-spam measure: it is harder to set up consistent forward and reverse DNS for IP addresses that a spammer is borrowing or hijacking.

The check works as follows:

1. A mail server at 203.0.113.42 connects to your SMTP listener
2. Your server performs a PTR lookup: 42.113.0.203.in-addr.arpa → mail.example.com
3. Your server then performs an A lookup: mail.example.com → 203.0.113.42
4. If both steps succeed and the addresses match, FCrDNS passes

Google, Microsoft, and most major mail providers require FCrDNS. A missing PTR record is a common misconfiguration that causes email to be rejected or heavily penalized by spam filters, especially for systems sending from cloud instances. Cloud providers like AWS and GCP assign PTR records automatically for elastic IP addresses, but the default PTR names (like ec2-203-0-113-42.compute-1.amazonaws.com) are recognized as generic cloud addresses by many spam classifiers, making a custom PTR record important for legitimate mail senders. See how SMTP works and DKIM, SPF, and DMARC for the full picture of email authentication.

Troubleshooting Uses

Reverse DNS is used in several network troubleshooting contexts:

Traceroute hop labeling. The traceroute tool (and its Windows counterpart tracert) performs PTR lookups on every hop's IP address and displays the hostname alongside the address. This makes it immediately clear when a path transits a specific ISP's backbone — hostnames like ae-3.r06.londen03.uk.bb.gin.ntt.net identify the NTT network and the London location. See how traceroute works for detail on interpreting these outputs.

Log analysis. Web server and firewall logs contain IP addresses. PTR lookups help analysts identify known scanning infrastructure, CDN nodes, or cloud provider egress without needing an external lookup service.

Security anomaly detection. An IP address claiming to belong to a major ISP but lacking a PTR record, or having one that doesn't match the claimed network, is a flag for further investigation — relevant when assessing whether an address is part of a botnet or a dynamic consumer range.

Reverse DNS and BGP

When you look up a prefix in a BGP looking glass, the origin AS and BGP next-hop IPs are visible. Performing PTR lookups on those IPs often reveals which operator's infrastructure is involved — router hostnames typically encode location, POP, and sometimes the router model. This is particularly useful for understanding peering relationships: a path transiting an IP with a PTR of et-0-0-4.core1.ams.nethub.net tells you the path goes through a specific router at a specific IXP in Amsterdam.

Automated BGP monitoring systems often use reverse DNS as a secondary source to label hops and correlate routing events with specific operator equipment, supplementing the AS path data that BGP itself provides.

Explore It Live

Look up IP addresses in the tool to see BGP routing data alongside reverse DNS context:

• 1.1.1.1 — Cloudflare's DNS resolver; PTR record is one.one.one.one
• 8.8.8.8 — Google's resolver; PTR record is dns.google
• AS20940 — Akamai's ASN; examine prefix origins alongside likely PTR patterns for CDN nodes

Enter any IP address in the lookup box to see BGP route, origin AS, and registration data — then run a separate dig -x or nslookup to verify the PTR record and check FCrDNS consistency for mail troubleshooting.