Reverse DNS and PTR Records

How a reverse name is built

DNS names are read from right to left, from the most general label to the most specific. IP addresses work the other way: the network part is on the left. To make addresses fit the DNS tree, the octets are reversed. The address 192.0.2.25 becomes the name 25.2.0.192.in-addr.arpa. That reversal lets the owner of 192.0.2.0/24 run one zone, 2.0.192.in-addr.arpa, and publish a PTR record for each host in it.

IPv6 uses the same idea with a finer grain. Each hexadecimal digit, called a nibble, becomes its own label, again in reverse order, under ip6.arpa. The full address is expanded first, so 2001:db8::25 turns into a name 32 labels long. Nobody types those by hand; tools generate them.

Looking up reverse DNS

The -x option tells dig to build the reverse name for you. A typical result looks like this:

$ dig -x 192.0.2.25 +noall +answer
25.2.0.192.in-addr.arpa. 3600 IN  PTR  mail.example.com.

$ dig mail.example.com A +short
192.0.2.25

$ dig -x 2001:db8::25 +noall +answer
5.2.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. 3600 IN PTR mail.example.com.

$ host 198.51.100.7
Host 7.100.51.198.in-addr.arpa. not found: 3(NXDOMAIN)

The first two commands show a healthy setup: the address points to a name, and the name points back to the same address. The last one shows an address with no reverse DNS at all. An NXDOMAIN there is common for consumer and cloud addresses that have never been configured. If you want to understand what that response code means compared with an empty answer, see NXDOMAIN vs NODATA vs REFUSED.

Who controls a reverse zone

Reverse zones are delegated along the path that addresses are handed out. IANA allocates large blocks to the Regional Internet Registries. A registry delegates the matching reverse zones to the network operators it allocates to, and those operators either run the zones themselves or delegate them further to customers. That is a normal NS delegation, the same mechanism described in DNS Delegation and Glue Records.

Delegation is simple when a customer receives a whole /24, because that lines up with one octet and one zone. Smaller assignments, such as a /28 of 16 addresses, do not line up with a label boundary. RFC 2317 describes the usual workaround: the provider publishes a CNAME for each address that points into a small zone the customer runs. In IPv6, nibble boundaries make delegation of a /48 or /56 straightforward.

In practice, most people set reverse DNS through a field in their hosting or cloud console. The provider writes the PTR record into its own reverse zone. Many providers only accept a name that already resolves forward to the same address, which enforces the matching check described below. If the setting does not exist, open a ticket with whoever assigned the address.

Why reverse DNS matters

Email delivery

Receiving mail servers commonly check the connecting server’s address. They look up its PTR record, then look up the resulting name and confirm it resolves back to the same address. This is called forward-confirmed reverse DNS, or FCrDNS. A missing or generic PTR record, such as one that encodes the address in a dial-up style name, is a strong spam signal, and large mailbox providers publish sender guidelines that ask for valid forward and reverse DNS. The name in the PTR record should normally match, or at least belong to the same organization as, the name the server announces in its SMTP greeting. For more delivery checks, see Why is email not being delivered? (DNS perspective).

Logs, traceroutes and investigations

Web servers, firewalls and SSH logs often record PTR names. Traceroute prints them for each hop, and router names frequently hint at a city or link type. Treat those names as hints rather than facts. Anyone who controls a reverse zone can publish any name in it, including a name in a domain they do not own. Only the forward-confirmed check makes a PTR name trustworthy, and even then it only proves that both zones agree. How to Read a Traceroute shows how to use hop names with care.

Access controls

Some older systems grant access based on a client’s reverse DNS name. That is weak, for the reason above, and slow, because every connection triggers a lookup. Prefer address-based rules or proper authentication.

Good practice for PTR records

• Publish exactly one PTR record per address, pointing to the host’s main name.
• Make sure that name has an A or AAAA record back to the same address, so forward and reverse agree.
• Use meaningful names for mail servers, such as mail.example.com, rather than generic provider names.
• Remember IPv6. A mail server that sends over IPv6 needs a PTR record in ip6.arpa too, and a missing one is a common reason mail fails over IPv6 but not IPv4.
• Update reverse DNS when you move a service to new addresses, and remove old PTR records when you give addresses back.

How DNS Panopticon helps

Website Recon looks up each resolved IP address in RDAP to find the network and AS number it belongs to. That tells you which organization holds the address block, which is the organization that controls its reverse DNS and the one to contact if a PTR record needs changing.

If you run your own reverse zones, export them and load the file into Zone Analyzer. Its PTR quick pill isolates reverse records in one click, and the CSV export lets you hand a clean list to whoever maintains the matching forward zone. Domain Visualizer focuses on forward records for a domain, so use it alongside dig -x to confirm the forward half of the match.