Reverse DNS Lookup

What a reverse DNS lookup does

Ordinary DNS answers “where does this name live?”. Reverse DNS answers the opposite question: given an address, what name does it claim to be? The answer comes from a PTR record, and it is published by whoever holds the address block — your hosting provider, your cloud platform or your ISP — not by whoever owns the domain the name belongs to.

The lookup works by rewriting the address into a name. 93.184.216.34 becomes 34.216.184.93.in-addr.arpa — the octets reversed, because DNS names get more specific towards the left while an address gets more specific towards the right. IPv6 does the same thing one nibble at a time under ip6.arpa, which is why an IPv6 reverse name is 32 labels long. That name is then looked up like any other, and its PTR records are the result.

Forward and reverse are separate systems

They are not two views of one database. Each direction is published independently, by different people, and nothing forces them to agree — which is exactly what makes agreement between them worth testing.

Why mail servers insist on it

Email is the one place where a missing PTR record has real consequences. When a server connects to deliver a message, the receiving side sees only an IP address, and the very first thing it can do about that is a reverse lookup. A legitimate mail server is almost always named — mail.example.com — while a compromised home router sending spam almost never is. That single check is cheap, happens before any content is examined, and filters an enormous amount of junk.

Large receivers commonly apply some or all of the following:

• Reject or defer connections from an address with no PTR record at all.
• Penalise generic provider-assigned names — anything that looks like 203-0-113-45.dsl.example.net reads as a residential connection, not a mail server.
• Require the PTR name to match the name the server gives in its SMTP HELO/EHLO greeting.
• Require forward-confirmed reverse DNS, described below.

None of this replaces SPF, DKIM and DMARC, which authenticate the message rather than the connection. Reverse DNS establishes that the host is a real, named, accountable mail server; the TXT-record trio establishes that it was authorised to send for the domain in question.

Forward-confirmed reverse DNS

FCrDNS is the test that makes reverse DNS trustworthy. On its own a PTR record proves little, because the address holder can point it at any name at all, including one they do not own. Confirming it forward closes that gap:

1. Look up the PTR record for the address — say 203.0.113.10 gives mail.example.com.
2. Look up the A and AAAA records for mail.example.com.
3. The check passes only if 203.0.113.10 is among them.

Because step one is controlled by the address holder and step two by the domain owner, a match means both parties agree — and an attacker would need control of both to fake it. You can run the second step here with the DNS Checker.

Why most addresses have no PTR record

This is the single most common outcome of a reverse lookup, and it worries people far more than it should. Reverse DNS is optional. Nothing about browsing, streaming, gaming or downloading depends on it, and the address you are reading this from very probably has no PTR record — or has one that names your ISP rather than you.

The usual reasons an address comes back empty:

• It is a consumer connection. Home broadband and mobile addresses are pooled and reassigned constantly. Many providers publish no PTR records for them; the ones that do publish generic names derived from the address itself.
• Nobody asked for one. On a cloud instance the PTR record is usually blank until you set it in the provider’s console. Creating an A record for your server does not create the matching PTR — the two are published in different places by different parties.
• The delegation is incomplete. Reverse zones are delegated down the address hierarchy. If the block holder has not delegated your slice, or has delegated it to nameservers that do not answer for it, the lookup returns nothing however carefully your own zone is configured.

How to get one set

You cannot add a PTR record in your own domain’s DNS — it does not live there. Ask whoever gave you the address: most hosting and cloud providers expose a “reverse DNS” or “PTR” field on the instance or IP, and it usually takes effect within minutes. If you hold a block smaller than a /24, the provider delegates it using the CNAME technique from RFC 2317 rather than handing you a whole zone.

Whatever name you choose, publish the matching forward record too, so the address passes forward-confirmed reverse DNS. A PTR record pointing at a name that does not resolve back is worse than no PTR record at all: it looks like a misconfiguration or an impersonation attempt.

How this lookup works

The query runs on IPGet’s own server using Node’s native DNS resolver against a fixed pair of public resolvers. You supply one thing — an IP address. You cannot choose a resolver, a port, a protocol or a record type, so this is a fixed-purpose lookup rather than a general network proxy.

Only globally routable addresses are queried. Private, loopback, link-local, carrier-NAT and cloud-metadata addresses are refused before any query is issued: they can never have a meaningful public PTR record, and querying them would risk disclosing internal host names. Requests are rate limited per address, every query has a hard timeout, and answers are cached for a few minutes — including empty ones, since those are both the most common result and the least likely to change. Looked-up addresses are not logged or stored; see the privacy policy.