What is reverse DNS and when does it matter?

Forward DNS is the easy part. You type google.com, DNS tells your computer to go to 142.250.190.46, and the connection happens. If you've read the how to find a website's IP guide, you've already seen this: names go in, IPs come out. It's the most familiar piece of internet plumbing there is.

Reverse DNS is the inverse operation. You have an IP, you want a name, and the way the internet handles this turns out to be one of those design choices that only makes sense once you understand the historical accident behind it. The lookup works — but the path it takes is genuinely weird.

The basic shape

When you do a reverse lookup on 8.8.8.8, you get back dns.google. Useful: that's Google's public DNS resolver. When you reverse-look up 1.1.1.1, you get one.one.one.one. Most servers run by serious operators have meaningful reverse records.

Most home connections are less informative but still have something. A Comcast customer's IP often reverses to a name like c-71-201-14-22.hsd1.il.comcast.net — encoding the IP itself, the type of service (high-speed data), and a state code, all generated automatically by the ISP. It's a name, but it's a name that exists for the convenience of the ISP rather than the customer.

Some IPs have no reverse record at all. Reverse DNS is best-effort and not every IP block is set up with one.

Why this is harder than it looks

Forward DNS works because domain names are hierarchical from right to left. com is the top of the tree, google.com is a branch underneath it, www.google.com is a leaf below that. The DNS system walks down this tree from the root to find any name. The hierarchy maps cleanly onto the lookup process.

IP addresses are also hierarchical, but the hierarchy runs in the opposite direction. In 192.168.1.42, the leftmost 192.168 identifies the broad network; the 1 identifies a subnet within it; the 42 picks out a specific device. The most-significant part is on the left, which is the wrong way around for DNS to walk.

The internet's solution to this mismatch is one of those moves that's either brilliant or unhinged depending on how you look at it. It works, has worked for forty years, and makes you raise an eyebrow the first time you see it.

The reverse-IP trick

To do a reverse lookup, you don't query the IP directly. You query a synthetic domain name that contains the IP, written backwards.

The domain is in-addr.arpa. To look up 8.8.8.8, you query the DNS for:

8.8.8.8.in-addr.arpa

The four octets are reversed so that the most-significant part comes last, matching how domain names work. 8.8.8.8.in-addr.arpa is structurally just like www.google.com from DNS's point of view: a hierarchical name with the broadest part on the right. The DNS system walks down from arpa to in-addr.arpa to 8.in-addr.arpa and so on, eventually arriving at the record that holds the hostname for 8.8.8.8.

The arpa top-level domain stands for "Address and Routing Parameter Area" — historically just a leftover from when the internet was the ARPAnet. It's reserved exclusively for internet infrastructure, and reverse DNS is by far its most-used purpose.

The reverse-IP trick was specified in 1983 by RFC 883 and refined into its current form by RFC 1035 in 1987. It's been quietly working ever since, sitting underneath everything from email delivery to network diagnostics, mostly invisible to the people benefiting from it.

IPv6 reverse DNS — even weirder

If in-addr.arpa seemed odd, IPv6 reverse DNS leans into the strangeness with full commitment. Each hex digit of the address becomes its own DNS label, separated by dots, in reverse order, ending in ip6.arpa.

Take the IPv6 address 2001:db8::1. Expanded to its full form, it's 2001:0db8:0000:0000:0000:0000:0000:0001. To reverse-look it up, you query:

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

Yes, really. Thirty-two single-digit labels, one for each hex digit of the address, reversed end-to-end, terminated by the ip6.arpa suffix. That's the actual DNS query that gets sent on the wire when you reverse-look up an IPv6 address. Fortunately, no human has to type that — your DNS resolver constructs it automatically. But it is, structurally, the query.

For more on the multiple IPv6 addresses your machine has at any given moment, the IPv6 explainer covers why this nested-zeros encoding shows up so often in real addresses.

Why reverse DNS exists at all

Three places reverse DNS does real work in production.

Email anti-spam. This is the single biggest reason commercial mail servers care about reverse DNS. When a sending mail server connects to a receiving one, the receiver checks whether the sender's IP has a valid reverse-DNS record. Many also do a stricter check: the name from the reverse lookup should forward-resolve back to the same IP, and ideally match the domain in the SMTP greeting. A mail server with no reverse DNS, or with a generic ISP-assigned reverse name, often gets its messages quietly demoted to spam. This is why anyone running their own mail server has to coordinate with their hosting provider to set up a sensible reverse DNS record before sending mail to anywhere serious.

Network diagnostics. When you run a traceroute, the hostnames you see for each hop come from reverse DNS. The descriptive router names from the traceroute post — ae-12-3.bear1.atlanta1.level3.net, be3006.ccr42.jfk02.atlas.cogentco.com — are reverse DNS records that network operators set up specifically to make their infrastructure self-documenting. Reading a traceroute is largely an exercise in reading other people's reverse DNS records. Without rDNS, those traces would be walls of raw IP addresses, much harder to interpret.

Server logs. Web servers, SSH daemons, and other services sometimes resolve client IPs to names automatically and write those names into their log files. Whether that's useful depends on the use case — it can give you a quick sense of where connections are coming from, or it can fill your logs with half-completed lookups that timed out. Most operators turn this off in production for performance reasons but leave it on in development.

Who controls a reverse DNS record

This is the part most people don't realise: reverse DNS for an IP is controlled by whoever owns the IP block, not whoever uses the IP.

Forward DNS for example.com is set by whoever owns the example.com domain — they run the authoritative DNS servers, they write the records. Reverse DNS for 203.0.113.42 is set by whoever owns the IP block 203.0.113.0/24 (or whatever subdivision of it contains that IP). For most people, that's their ISP. For server operators, it's their hosting provider.

If you want a custom reverse DNS for a server you're running, you have to ask your provider to set it up on your behalf. Reputable cloud hosts — AWS, Google Cloud, DigitalOcean, Linode, OVH — will all do this through a control-panel option or a support ticket. Residential ISPs typically won't, and the auto-generated reverse names they assign are what your home IP forever maps back to.

Limitations and the FCrDNS check

Two things to keep in mind about reverse DNS in practice.

Reverse records can be set to anything. There's no authoritative check that ties the name in a reverse-DNS record to the IP it's claiming to describe. If your provider lets you set the reverse record for your IP to www.google.com, you can — and the reverse lookup will return that name. This is harmless on its own; the name doesn't grant you any access. But it means that "the reverse DNS says X" isn't proof of identity by itself.

The rigorous version of the check is called Forward-Confirmed reverse DNS, or FCrDNS. The verifier does the reverse lookup to get a name, then does a forward lookup on that name and confirms it resolves back to the original IP. Only if both directions agree does the name "really" belong to the IP. This is what serious mail servers actually require for inbound mail, and what fraud-detection systems use when they want to trust a hostname claim.

Plenty of IPs have no reverse record at all. Particularly in dense IPv6 deployments where setting up rDNS for every assigned address would be enormous work, and on smaller or older IP blocks where the operator never bothered. An empty reverse-DNS result isn't necessarily a problem — it just means the operator chose not to publish anything.