How to Do a Reverse DNS Lookup: Step-by-Step Guide with OpDeck Tool

If you've ever needed to find out what domain name is associated with an IP address, you already know why learning how to do a reverse DNS lookup matters. Whether you're investigating suspicious traffic, verifying email server configurations, troubleshooting network issues, or auditing your own infrastructure, reverse DNS is one of the most practical diagnostic tools in any developer or sysadmin's toolkit. This guide walks you through exactly how it works, how to perform one using multiple methods — including OpDeck's dedicated tool — and how to make sense of what you find.

---

What Is a Reverse DNS Lookup and Why Does It Matter?

Before jumping into the how-to, it's worth understanding what's actually happening under the hood.

A standard (forward) DNS lookup translates a domain name into an IP address — for example, example.com → 93.184.216.34. A reverse DNS lookup does the opposite: it takes an IP address and returns the associated hostname or domain name, if one has been configured.

This mapping is stored in a special DNS zone called the PTR record (Pointer Record). PTR records live under the in-addr.arpa domain for IPv4 addresses and ip6.arpa for IPv6 addresses. When you perform a reverse lookup on 93.184.216.34, the DNS system actually queries 34.216.184.93.in-addr.arpa — the IP octets are reversed, then appended to in-addr.arpa.

Common Use Cases for Reverse DNS

• Email deliverability: Mail servers frequently check whether the sending IP has a valid PTR record that matches the forward DNS. Missing or mismatched PTR records are a major cause of email landing in spam folders.
• Security investigations: When you spot an unfamiliar IP in your logs, a reverse lookup can reveal whether it belongs to a known cloud provider, CDN, bot network, or suspicious host.
• Network troubleshooting: Reverse DNS helps you identify which servers are communicating with your infrastructure without manually cross-referencing IP ranges.
• Compliance and auditing: Some regulatory frameworks require documented records of which IP addresses correspond to which systems in your environment.
• Log readability: Tools like Apache or Nginx can perform reverse lookups on client IPs so your access logs show hostnames instead of raw numbers.

---

How to Do a Reverse DNS Lookup Using OpDeck

The fastest and most beginner-friendly way to perform a reverse DNS lookup is with the Reverse DNS Lookup tool on OpDeck. No command-line knowledge required, no software to install — just an IP address and a browser.

Step 1: Navigate to the Tool

Go to https://www.opdeck.co/tools/reverse-dns. The interface is clean and straightforward — you'll see a single input field waiting for an IP address.

Step 2: Enter the IP Address

Type or paste the IP address you want to investigate. This can be:

• An IPv4 address (e.g., 8.8.8.8)
• An IPv6 address (e.g., 2001:4860:4860::8888)

You can find IP addresses to investigate in several places:

• Your web server access logs
• Email headers (look for Received: lines)
• Firewall or security alerts
• Network monitoring dashboards
• The output of ping, traceroute, or netstat commands

Step 3: Run the Lookup

Click the lookup button and wait a moment. OpDeck queries the DNS infrastructure on your behalf and returns the PTR record associated with the IP.

Step 4: Interpret the Results

For 8.8.8.8 (Google's public DNS server), you'd expect to see something like:

Hostname: dns.google

For 1.1.1.1 (Cloudflare's DNS), the result would return:

Hostname: one.one.one.one

If no PTR record exists, the tool will indicate that no reverse DNS entry was found — which is itself useful information, as we'll discuss shortly.

---

How to Do a Reverse DNS Lookup from the Command Line

If you prefer working in a terminal, or need to automate reverse DNS lookups as part of a script or workflow, you have several solid options.

Using nslookup

nslookup is available on Windows, macOS, and Linux. It's the most universally accessible command-line tool for DNS queries.

nslookup 8.8.8.8

Output:

Server:  your-local-dns
Address: 192.168.1.1

Non-authoritative answer:
8.8.8.8.in-addr.arpa  name = dns.google.

You can also query a specific DNS server to see how the lookup resolves from a different resolver:

nslookup 8.8.8.8 1.1.1.1

Using dig with the -x Flag

dig is the go-to tool for DNS professionals on Linux and macOS. The -x flag is specifically designed for reverse lookups:

dig -x 8.8.8.8

Output (abbreviated):

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  21599  IN  PTR  dns.google.

To get a cleaner output with just the answer:

dig -x 8.8.8.8 +short

Result:

dns.google.

For IPv6 addresses:

dig -x 2001:4860:4860::8888 +short

Using host

The host command provides a simpler, more readable output:

host 8.8.8.8

Output:

8.8.8.8.in-addr.arpa domain name pointer dns.google.

Using curl to Query DNS-over-HTTPS APIs

If you're building an application or want to script reverse lookups without installing DNS tools, you can use DNS-over-HTTPS (DoH) APIs:

curl "https://dns.google/resolve?name=8.8.8.8.in-addr.arpa&type=PTR"

This returns a JSON response:

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "8.8.8.8.in-addr.arpa.",
      "type": 12
    }
  ],
  "Answer": [
    {
      "name": "8.8.8.8.in-addr.arpa.",
      "type": 12,
      "TTL": 21599,
      "data": "dns.google."
    }
  ]
}

This approach works great in shell scripts, CI/CD pipelines, or any environment where you want to programmatically extract PTR records.

Using Python for Bulk Reverse DNS Lookups

If you need to look up many IP addresses at once, Python's socket module makes this easy:

import socket

ip_addresses = ["8.8.8.8", "1.1.1.1", "208.67.222.222"]

for ip in ip_addresses:
    try:
        hostname = socket.gethostbyaddr(ip)[0]
        print(f"{ip} -> {hostname}")
    except socket.herror:
        print(f"{ip} -> No PTR record found")

Output:

8.8.8.8 -> dns.google
1.1.1.1 -> one.one.one.one
208.67.222.222 -> resolver1.opendns.com

For larger-scale lookups, consider using asyncio with aiodns to run concurrent queries and avoid long wait times.

---

Understanding PTR Records: What the Results Actually Mean

Knowing how to do a reverse DNS lookup is only half the battle. Understanding what the results tell you is where the real value lies.

When You Get a Hostname Back

If a PTR record exists, the returned hostname tells you something about who owns and manages that IP. Pay attention to patterns:

• Cloud provider hostnames: Results like ec2-54-123-45-67.compute-1.amazonaws.com indicate an AWS EC2 instance. Similarly, 34-123-45-67.bc.googleusercontent.com points to Google Cloud.
• ISP-assigned names: Hostnames like pool-72-75-255-37.bstnma.fios.verizon.net suggest a residential or business ISP connection.
• Dedicated server names: Clean, descriptive hostnames like mail.company.com or webserver1.datacenter.net usually indicate professionally managed infrastructure.
• Bot or crawler hostnames: Googlebot IPs resolve to names ending in googlebot.com. Bingbot resolves to search.msn.com. Seeing these in your logs is normal and expected.

When No PTR Record Exists

A missing PTR record isn't always a red flag, but context matters:

• For email servers, a missing PTR record is a serious problem. Most spam filters will reject or heavily penalize email from IPs without reverse DNS configured.
• For web traffic, missing PTR records are common, especially for residential IPs and smaller hosting providers that don't bother configuring them.
• For API clients or automated services, missing PTR records may indicate poorly configured infrastructure or, in some cases, malicious actors who deliberately avoid setting them up to stay anonymous.

Checking for Forward-Confirmed Reverse DNS (FCrDNS)

A best practice — especially for mail servers — is to verify that the PTR record's hostname also resolves forward back to the original IP. This is called Forward-Confirmed Reverse DNS (FCrDNS) or Full-Circle DNS.

Here's how to manually check:

1. Do a reverse lookup on the IP: 8.8.8.8 → dns.google
2. Do a forward lookup on the returned hostname: dns.google → 8.8.8.8
3. If both match, the FCrDNS check passes.

In bash:

IP="8.8.8.8"
HOSTNAME=$(dig -x $IP +short | sed 's/\.$//')
FORWARD=$(dig $HOSTNAME +short)
echo "IP: $IP | PTR: $HOSTNAME | Forward: $FORWARD"

---

How to Set Up a PTR Record for Your Own IP

If you're running a mail server, VPN endpoint, or any publicly accessible service and you want reverse DNS to work correctly for your IP, here's what you need to do.

Who Controls PTR Records?

Unlike A records and CNAME records, which you control through your domain registrar or DNS hosting provider, PTR records are controlled by whoever owns the IP address block — typically your hosting provider or ISP, not you directly.

This means:

• If you're on a VPS or dedicated server, you usually set PTR records through your hosting provider's control panel (e.g., DigitalOcean, Linode/Akamai, Vultr, Hetzner all allow this).
• If you're on a corporate network with your own IP block, your network team manages PTR records through your Regional Internet Registry (RIR) or ISP.
• If you're on residential internet, your ISP controls PTR records and may or may not let you change them.

Setting a PTR Record on Common Providers

DigitalOcean: Go to your Droplet settings, find the hostname field, and set it to your desired FQDN. DigitalOcean automatically creates the PTR record.

AWS EC2: Use Elastic IPs and contact AWS Support to set a custom PTR record, or configure it through the EC2 console's reverse DNS request form.

Vultr: In your server settings, look for the "Reverse DNS" section and enter your desired hostname.

Hetzner: Available directly in the server management panel under "Reverse DNS."

After setting the PTR record, allow up to 24-48 hours for propagation, then verify using OpDeck's Reverse DNS Lookup tool or the command-line methods above.

---

Troubleshooting Common Reverse DNS Issues

PTR Record Set But Not Resolving

• Check propagation time — PTR records can take 24-48 hours to propagate fully.
• Confirm the record was saved correctly in your hosting panel.
• Try querying multiple DNS resolvers to rule out caching issues.

PTR Record Resolves But Doesn't Match Forward DNS

This breaks FCrDNS checks and can cause email delivery problems. Make sure the hostname in your PTR record has an A record pointing back to the same IP.

Getting Different Results from Different Resolvers

DNS caching means different resolvers may return different (or cached) results. Use dig @8.8.8.8 -x [IP] to query Google's resolver directly, or dig @1.1.1.1 -x [IP] for Cloudflare's resolver, to get fresh results.

IPv6 Reverse DNS Not Working

IPv6 PTR records use the ip6.arpa zone and require the full expanded address in reverse nibble format. Most DNS tools handle this automatically with the -x flag, but some hosting providers have limited IPv6 PTR record support — check with your provider.

---

Conclusion

Understanding how to do a reverse DNS lookup — and what to do with the results — is a genuinely useful skill for developers, sysadmins, and security professionals. Whether you're investigating a suspicious IP in your logs, verifying your mail server's PTR record, or auditing your infrastructure, reverse DNS gives you a fast, reliable way to add context to raw IP addresses.

For the quickest possible lookup without any setup, the Reverse DNS Lookup tool on OpDeck gets the job done in seconds. And if you want to go deeper into your infrastructure's DNS health, network configuration, and security posture, OpDeck offers a full suite of complementary tools — from DNS lookups and SSL certificate checks to vulnerability scanning and tech stack detection. Head over to opdeck.co and start exploring what your IP addresses are actually telling the world.