Reverse DNS and PTR records

Forward and reverse lookups

A forward lookup asks for the address behind a name: given example.com, return an A or AAAA record. A reverse lookup asks the opposite question, and the DNS answers it with a PTR record, defined alongside the rest of the protocol in RFC 1035.

The mechanism is a little odd. IPv4 reverse entries live under in-addr.arpa with the address octets reversed, so 203.0.113.24 is queried as 24.113.0.203.in-addr.arpa. IPv6 uses ip6.arpa with each hexadecimal digit reversed and separated by dots, as set out in RFC 3596. Delegation follows address allocation, which means only the operator holding an address block can publish PTR records for it.

Why the two directions disagree

Forward and reverse DNS are separate databases maintained by different parties. The owner of a domain controls its forward records; the owner of the address block controls the reverse ones. Nothing forces them to agree, and frequently they do not.

RFC 1912 recommends that every address have a matching PTR record and that the name it returns resolve back to the same address. In practice that discipline is common on mail servers and infrastructure, and rare everywhere else.

Why some addresses have a hostname and others do not

Publishing PTR records for millions of dynamically assigned consumer addresses is optional work with limited benefit, so networks differ widely in how they handle it.

• Many residential ISPs auto-generate generic names that encode the address and region into a broadband domain.
• Some residential and many mobile networks publish nothing at all, and a lookup simply returns no result.
• Hosting and cloud providers usually publish a default machine name and let customers set their own, because mail delivery and audit logs depend on it.
• Corporate networks often publish descriptive names that inadvertently reveal site locations, device roles or naming conventions.

What it is good for

Reverse DNS is a useful classification hint. A hostname containing words like dsl, cable or dyn, or a carrier's mobile domain, suggests a consumer endpoint. A hostname on a cloud provider's domain suggests a server. Mail systems lean on it heavily, often refusing or downgrading mail from addresses with no PTR record at all.

Absence of a record means very little on its own. It is a configuration choice, not a sign of anything suspicious.

Why it is not proof

A PTR record is a claim made by whoever controls the address block. It can be inaccurate, stale, misleading, or set to almost any name — including one the operator has no real connection to. Checking that the returned hostname resolves forward to the same address (forward-confirmed reverse DNS) raises the bar, but still proves only that two records agree, not that a particular person or organisation is behind the connection.

Records also lag reality. Address blocks are reassigned between customers, machines are decommissioned, and the reverse zone is frequently the last thing anyone updates. A hostname naming a company that stopped using the address years ago will keep resolving until someone notices.

Treat reverse DNS as context. It tells you something about the network. It does not identify a user.