Reverse DNS and Pointer (PTR) Records Explained

Reverse DNS looks up a name associated with an IP address, such as dns.google for 8.8.8.8. A name identifying a host or service is called a hostname. The Domain Name System (DNS) stores this reverse mapping in a Pointer (PTR) record. Whoever manages reverse DNS for the address range controls that record. The name is useful context, not proof of ownership, identity, purpose, or physical location.

How can I look up reverse DNS?

Enter an IPv4 or IPv6 address in the IP Lens reverse DNS lookup to search previously collected PTR observations. Opening an IP Lens result does not perform a new DNS query or connect to the queried address.

To query DNS live, use the terminal commands below. These commands do perform a live DNS query. The DNS server you ask (the resolver) and the operator responsible for that range's reverse DNS records (the reverse-zone operator) may observe it. A different resolver may return a different answer while records and caches update.

Linux with dig

The -x option builds the reverse-zone name and requests its PTR record. It works for both IPv4 and IPv6, so you do not need to reverse the address by hand. +short prints only the answer.

$ dig -x 8.8.8.8 +short
dns.google.

$ dig -x 2001:4860:4860::8888 +short
dns.google.

On Debian and Ubuntu, dig is provided by the dnsutils package. On Fedora and Red Hat Enterprise Linux, install bind-utils.

Windows Command Prompt with nslookup

Pass the IP address directly to nslookup. The Name line is the PTR result; the first Server and Address lines, when present, identify the DNS resolver that answered.

C:\> nslookup 8.8.8.8
Name:    dns.google
Address: 8.8.8.8

Windows PowerShell

Resolve-DnsName can request the PTR record explicitly. -DnsOnly prevents fallback to Link-Local Multicast Name Resolution (LLMNR) or NetBIOS. This example selects the hostname from the answer:

PS C:\> (Resolve-DnsName -Name 8.8.8.8 -Type PTR -DnsOnly |
>>     Where-Object Section -eq 'Answer').NameHost
dns.google

What the tools query

For IPv4, the resolver reverses the octets and adds .in-addr.arpa. For example, 8.8.4.4 becomes 4.4.8.8.in-addr.arpa. This explicit query is equivalent to dig -x 8.8.4.4:

$ dig 4.4.8.8.in-addr.arpa PTR +short
dns.google.

IPv6 reverses every hexadecimal digit and adds .ip6.arpa. Use dig -x, nslookup, or Resolve-DnsName to construct that longer name safely.

Why do reverse DNS tools sometimes show different hostnames for the same IP address?

Tools can ask different recursive resolvers, and each resolver may retain an older cached answer until its DNS time to live (TTL) expires. They can also format several PTR answers in a different order or handle timeouts and server failures differently from authoritative NXDOMAIN or NODATA responses. When results conflict, compare the resolver, query type, response status, and time of each lookup.

How does a reverse DNS lookup work?

Reverse DNS names come from PTR records that map an IP address back to a name, for example dns.google. The lookup happens in special reverse zones — .in-addr.arpa for IPv4 and .ip6.arpa for IPv6 — which can be delegated separately from forward DNS.

A lookup can return no PTR record, one name, or several names in one PTR record set. Forward DNS does the opposite job: it uses A or AAAA records to map a hostname to IPv4 or IPv6 addresses. The forward and reverse answers are configured separately and do not have to match automatically.

The record is set by whoever controls reverse DNS for the address block. Possible operators include the registered holder, an Internet Service Provider (ISP) supplying Internet access, a hosting provider running customers' servers, a customer, or another delegated operator.

IP Lens distinguishes the latest observed PTR names from names seen only on earlier lookups. "Latest" means the newest check available in IP Lens that returned PTR records or confirmed there were none (a conclusive observation), not necessarily the address's current DNS state. NXDOMAIN means the reverse DNS name did not exist when checked. NODATA means the name existed, but the response contained no PTR record. Timeout and server-failure responses do not replace the latest conclusive observation.

Why does this IP have no PTR record?

Many addresses have no PTR record. The reverse-zone operator may never have created one, may remove it when an address is reassigned, or may not delegate reverse-DNS control to a customer. Forward A or AAAA records do not create PTR records automatically. Missing reverse DNS is therefore not evidence that an address is malicious.

Who can change reverse DNS?

Only the operator responsible for the address's reverse zone can publish or delegate its PTR record. That is often an ISP, cloud provider, or hosting provider rather than the person who controls the forward hostname. If you use a provider-assigned address, change reverse DNS in its control panel or ask its support team; adding an A or AAAA record at your domain registrar is not enough.

What can a reverse DNS name tell me?

Reverse DNS names identify services, cities, routers, customer pools, and internal conventions. Common states include missing records, generic names, outdated names, and intentionally descriptive labels rather than authoritative ones.

Pattern	Example	How to read it
Service name	dns1.example.net	Identifies a public service, resolver, mail server, VPN endpoint, or content delivery network (CDN) server that serves content as part of a distributed network.
Location code	ae-1-3502.ear2.Paris1.example.net	Describes a network point of presence, not the user's physical location.
Customer pool	203-0-113-24.dyn.example-isp.net	Appears on residential, business, or mobile ISP address ranges.
No record	—	Absence of reverse DNS is common and does not make an address suspicious by itself.

Can I trust a PTR record?

For large providers, reverse DNS is a useful hint about an IP address, but it has limits. Hostnames can lag behind routing changes, remain after reassignment, or describe a provider's naming system rather than the current user, service, or physical location.

Some hosting providers allow customers to set reverse DNS themselves. In those cases the hostname is practically any string the customer wants; for example, a customer sets google.com as the reverse DNS name for their server.

Forward-confirmed reverse DNS (FCrDNS) checks consistency: resolve the IP address to a hostname through its PTR record, then resolve that hostname's A or AAAA records and confirm that the original IP address appears in the result. A match is stronger supporting evidence than an unchecked PTR label, but it is not authentication. Someone who controls or can coordinate both DNS sides can create a matching result for a domain they control.

Check forward-confirmed reverse DNS

On Linux, run the reverse lookup and then look up the returned hostname. The original address, 8.8.8.8, appears among the forward results:

These commands perform live reverse and forward DNS queries. The selected resolver and relevant DNS zone operators may observe them.

$ dig -x 8.8.8.8 +short
dns.google.

$ dig dns.google A +short
8.8.4.4
8.8.8.8

In Windows Command Prompt, use nslookup 8.8.8.8, followed by nslookup dns.google. In PowerShell:

PS C:\> $name = (Resolve-DnsName 8.8.8.8 -Type PTR -DnsOnly |
>>     Where-Object Section -eq 'Answer').NameHost
PS C:\> Resolve-DnsName $name -Type A -DnsOnly |
>>     Where-Object Section -eq 'Answer' |
>>     Select-Object -ExpandProperty IPAddress
8.8.4.4
8.8.8.8

A hostname can legitimately resolve to several addresses. FCrDNS passes when the original address is one of them; the lists do not need to contain only one address.

How do PTR records and FCrDNS affect email delivery?

Receiving mail systems can use PTR and forward-confirmation checks as infrastructure signals. Gmail's sender requirements say that a sending IP must have a PTR hostname and that the hostname's A or AAAA record must resolve back to that IP. This check does not replace SPF, DKIM, or DMARC authentication, and passing it does not guarantee delivery or a good reputation. See Google's email sender guidelines.

How should I verify a search-engine crawler?

FCrDNS can be one part of crawler verification, but a generic forward match is not enough. Confirm that the PTR hostname ends in the operator's approved suffix at a DNS label boundary, then resolve that exact name forward and check that it includes the original address. Some operators instead publish crawler IP ranges or provide a verification tool. See Search bot verification for the documented methods used by common search crawlers.

Even when reverse DNS looks credible, treat it as one signal alongside the registered-holder record, observed origin Autonomous System Number (ASN), location, and IP address tags. The hostname also describes the address you observed, which may be a proxy or CDN rather than the visitor; see Finding the real client IP.