What is reverse DNS?

Reverse DNS (rDNS) maps an IP address back to a hostname, the opposite of ordinary DNS, which resolves a name to an IP address. It works through a PTR record placed in dedicated zones: in-addr.arpa for IPv4 and ip6.arpa for IPv6. When a mail server, diagnostic tool or logging system asks which name is assigned to a given IP address, the reverse DNS lookup returns the answer.

How a PTR record works

Reverse DNS relies on a special namespace defined in RFC 1035. An IPv4 address is written with its octets in reverse order followed by the in-addr.arpa suffix, because DNS delegates authority from the most general label to the most specific, while in an IP address the first octet is the most significant. For the address 192.0.2.10 the PTR query is sent to the name 10.2.0.192.in-addr.arpa. IPv6 follows the same idea, but the address is broken into individual hexadecimal digits in reverse order under the ip6.arpa domain, as defined in RFC 3596.

• A PTR record returns a single hostname, such as mail.example.com, for a given IP address.
• IPv4 reverse zones live under in-addr.arpa, IPv6 reverse zones under ip6.arpa.
• The address is written from the least significant to the most significant element, the reverse of normal ordering.
• A correct setup matches both ways: the PTR points to a name, and that name's A or AAAA record resolves back to the same IP (forward-confirmed reverse DNS).
• rDNS does not affect packet routing itself. It serves identification and verification, not traffic delivery.

Delegating reverse zones from the ISP

Address blocks are allocated by the Regional Internet Registries (RIRs), in Europe by the RIPE NCC, and the reverse zone is delegated down the same chain as the addresses themselves. An operator receiving a prefix is given a delegation of the matching in-addr.arpa or ip6.arpa zone to its DNS servers by the RIR. It can then sub-delegate smaller portions to customers who hold their own range of addresses. For IPv4 blocks smaller than a /24, delegation uses CNAME records as described in RFC 2317, because the zone boundary no longer aligns with an octet boundary. Without this delegation a customer cannot set PTR records for its own addresses.

Why rDNS matters

Reverse DNS is not required for routing to work, but in practice many systems expect it. Mail servers commonly reject or down-rank connections from addresses without a correct, consistent PTR, treating missing rDNS as a sign of spam or a misconfigured host. Tools such as traceroute and security logs only become readable when addresses carry descriptive hostnames. For an operator, deliberate PTR naming, for example reflecting a PoP location or router interface, makes troubleshooting and path analysis far easier.

rDNS on the AS202520 SkyPass network

As the operator AS202520 SkyPass, we delegate the in-addr.arpa and ip6.arpa reverse zones for prefixes assigned to customers, so they can manage their own PTR records on their DNS servers. For smaller IPv4 blocks below a /24 we use RFC 2317-style delegation. IP transit and peering customers at our Warsaw and Wrocław PoPs get full control over the rDNS of their addresses, which matters for mail hosting and clean diagnostics among other things. Consistent PTR naming across our backbone also makes it easier to read the paths shown in our looking glass and on our links to the Polish internet exchanges THINX, TPIX, WRIX and 1-IX.