ad placeholder image ad placeholder image

Reverse DNS Lookup: Complete Guide

Reverse DNS (rDNS) is the process of determining the domain name associated with an IP address. While regular DNS translates domain names to IP addresses, reverse DNS does the opposite. This guide explains how reverse DNS works, its uses, and how to configure it.

What is Reverse DNS?

Reverse DNS lookup queries DNS servers to find the hostname associated with an IP address. It's the reverse of the normal DNS process where you look up an IP address from a domain name.

Normal DNS vs Reverse DNS

Forward DNS (Normal):

example.com → DNS lookup → 93.184.216.34

Reverse DNS:

93.184.216.34 → rDNS lookup → example.com

PTR Records

Reverse DNS uses PTR (Pointer) records to map IP addresses to hostnames.

PTR record format:

IP: 93.184.216.34
PTR: 34.216.184.93.in-addr.arpa → example.com

Note: IP address is reversed in PTR record

How Reverse DNS Works

The Lookup Process

  1. IP address reversed - 93.184.216.34 becomes 34.216.184.93
  2. Domain appended - Becomes 34.216.184.93.in-addr.arpa
  3. DNS query sent - Query for PTR record
  4. PTR record returned - Contains hostname
  5. Hostname displayed - example.com

in-addr.arpa Domain

Purpose: Special domain for IPv4 reverse DNS

Structure:

[reversed-ip].in-addr.arpa

Examples:

8.8.8.8 → 8.8.8.8.in-addr.arpa
1.1.1.1 → 1.1.1.1.in-addr.arpa
192.168.1.1 → 1.1.168.192.in-addr.arpa

ip6.arpa Domain

Purpose: Special domain for IPv6 reverse DNS

Structure:

[reversed-nibbles].ip6.arpa

Example:

2001:db8::1 →
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

Performing Reverse DNS Lookups

Command Line Tools

Using host

# Reverse lookup
host 8.8.8.8

# Output:
# 8.8.8.8.in-addr.arpa domain name pointer dns.google.

Using nslookup

# Reverse lookup
nslookup 8.8.8.8

# Output:
# Server: 192.168.1.1
# Address: 192.168.1.1#53
#
# Non-authoritative answer:
# 8.8.8.8.in-addr.arpa name = dns.google.

Using dig

# Reverse lookup
dig -x 8.8.8.8

# Output shows PTR record:
# ;; ANSWER SECTION:
# 8.8.8.8.in-addr.arpa. 21599 IN PTR dns.google.

Using dig with full query

# Manual PTR query
dig PTR 8.8.8.8.in-addr.arpa

# Same result as dig -x

Online Tools

Popular reverse DNS lookup sites: - mxtoolbox.com/ReverseLookup.aspx - whatismyipaddress.com - dnschecker.org/reverse-dns.php - iplocation.net

How to use: 1. Visit reverse DNS lookup tool 2. Enter IP address 3. Click lookup/search 4. View hostname result

Programming Examples

Python

import socket

def reverse_dns(ip):
    try:
        hostname = socket.gethostbyaddr(ip)
        return hostname[0]
    except socket.herror:
        return "No PTR record found"

# Example
print(reverse_dns('8.8.8.8'))  # dns.google

JavaScript (Node.js)

const dns = require('dns');

dns.reverse('8.8.8.8', (err, hostnames) => {
    if (err) {
        console.log('No PTR record found');
    } else {
        console.log(hostnames[0]);  // dns.google
    }
});

PHP

<?php
$ip = '8.8.8.8';
$hostname = gethostbyaddr($ip);
echo $hostname;  // dns.google
?>

Bash

#!/bin/bash
IP="8.8.8.8"
HOSTNAME=$(dig -x $IP +short)
echo "Hostname: $HOSTNAME"

Use Cases for Reverse DNS

Email Delivery

Critical for email servers:

Most email servers check reverse DNS to verify sender legitimacy.

Email server checks: 1. Receives email from IP 203.0.113.5 2. Performs reverse DNS lookup 3. Checks if PTR matches sending domain 4. Rejects if no match or no PTR

Example:

Email from: mail.example.com (203.0.113.5)
PTR record: 203.0.113.5 → mail.example.com ✓
Result: Email accepted

Without proper rDNS:

Email from: mail.example.com (203.0.113.5)
PTR record: None or mismatch ✗
Result: Email rejected or marked as spam

Best practices: - PTR must match HELO/EHLO hostname - PTR must match sending domain - Forward and reverse DNS must match - Essential for email deliverability

Network Troubleshooting

Identify unknown IPs:

# See what's connecting to your server
netstat -an | grep ESTABLISHED

# Reverse lookup each IP
dig -x 203.0.113.45

Trace network paths:

# Traceroute with hostnames
traceroute -n example.com

# Then reverse lookup each hop
for ip in $(traceroute -n example.com | awk '{print $2}'); do
    dig -x $ip +short
done

Log analysis:

# Web server logs with IPs
# 203.0.113.45 - - [01/Jan/2024:12:00:00] "GET / HTTP/1.1"

# Identify visitors
dig -x 203.0.113.45
# crawler.googlebot.com

Security and Forensics

Identify attackers:

# Failed login attempts
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort -u

# Reverse lookup each IP
while read ip; do
    echo "$ip: $(dig -x $ip +short)"
done < suspicious_ips.txt

Verify legitimate services:

Connection from: 66.249.64.1
Reverse DNS: crawl-66-249-64-1.googlebot.com
Forward DNS: crawl-66-249-64-1.googlebot.com → 66.249.64.1
Verified: Legitimate Googlebot ✓

Detect spoofing:

Claimed: googlebot.com
IP: 203.0.113.99
Reverse DNS: malicious.example.com
Result: Spoofed, not real Googlebot ✗

Server Identification

Identify server types:

# Web server
dig -x 93.184.216.34
# example.com

# Mail server
dig -x 198.51.100.1
# mail.example.com

# DNS server
dig -x 8.8.8.8
# dns.google

Cloud provider identification:

# AWS
dig -x 54.239.28.85
# ec2-54-239-28-85.compute-1.amazonaws.com

# Google Cloud
dig -x 35.186.224.25
# 25.224.186.35.bc.googleusercontent.com

# Azure
dig -x 13.64.151.161
# msnbot-13-64-151-161.search.msn.com

Compliance and Logging

Regulatory requirements: - Some regulations require hostname logging - Audit trails need identifiable sources - Compliance reports need readable data

Enhanced logging:

Instead of: 203.0.113.45 accessed resource
Better: mail.example.com (203.0.113.45) accessed resource

Setting Up Reverse DNS

Prerequisites

You need: 1. Static IP address 2. Control over IP block (or ISP cooperation) 3. DNS hosting capability 4. Forward DNS already configured

You cannot set rDNS for: - Dynamic IP addresses - IP addresses you don't control - Shared hosting IPs - Most residential connections

For Your Own Server

Step 1: Configure Forward DNS

# A record
mail.example.com → 203.0.113.5

Step 2: Request PTR Record

If you own the IP block: - Configure PTR in your DNS - Update reverse zone file

If ISP owns the IP: - Contact ISP support - Request PTR record creation - Provide hostname - Wait for propagation

Step 3: Verify Configuration

# Check forward DNS
dig mail.example.com

# Check reverse DNS
dig -x 203.0.113.5

# Verify match
host mail.example.com
host 203.0.113.5

DNS Zone File Configuration

Reverse zone file example:

; Reverse zone for 203.0.113.0/24
$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
        2024010101  ; Serial
        3600        ; Refresh
        1800        ; Retry
        604800      ; Expire
        86400 )     ; Minimum TTL

; Name servers
    IN  NS  ns1.example.com.
    IN  NS  ns2.example.com.

; PTR records
5   IN  PTR mail.example.com.
10  IN  PTR web.example.com.
15  IN  PTR ftp.example.com.

File location (BIND):

/var/named/113.0.203.in-addr.arpa.zone

Named.conf entry:

zone "113.0.203.in-addr.arpa" {
    type master;
    file "/var/named/113.0.203.in-addr.arpa.zone";
};

Cloud Providers

AWS

# Set PTR via CLI
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --source-dest-check "{\"Value\":false}"

# Or via console:
# EC2 → Elastic IPs → Actions → Modify reverse DNS

Google Cloud

# Set PTR via gcloud
gcloud compute instances set-reverse-dns \
    --instance=instance-name \
    --zone=us-central1-a \
    --reverse-dns=mail.example.com

Azure

# Set PTR via Azure CLI
az network public-ip update \
    --resource-group myResourceGroup \
    --name myPublicIP \
    --reverse-fqdn mail.example.com

DigitalOcean

# Via control panel:
# Networking → Droplet → Edit reverse DNS
# Enter hostname

Verifying Reverse DNS

Basic Verification

# Method 1: host command
host 8.8.8.8

# Method 2: dig
dig -x 8.8.8.8 +short

# Method 3: nslookup
nslookup 8.8.8.8

Forward-Confirmed Reverse DNS (FCrDNS)

Complete verification:

#!/bin/bash
IP="203.0.113.5"

# Step 1: Reverse lookup
HOSTNAME=$(dig -x $IP +short)
echo "PTR: $IP → $HOSTNAME"

# Step 2: Forward lookup
FORWARD_IP=$(dig $HOSTNAME +short)
echo "A: $HOSTNAME → $FORWARD_IP"

# Step 3: Compare
if [ "$IP" == "$FORWARD_IP" ]; then
    echo "✓ FCrDNS verified"
else
    echo "✗ FCrDNS mismatch"
fi

Why FCrDNS matters: - Prevents spoofing - Verifies authenticity - Required by many email servers - Best practice for security

Testing Email Configuration

# Check mail server rDNS
dig -x $(dig mail.example.com +short) +short

# Should return mail.example.com

# Test with MXToolbox
# Visit: mxtoolbox.com/SuperTool.aspx
# Enter: mail.example.com
# Check: SMTP Test, Reverse DNS

Common Issues and Solutions

No PTR Record

Symptoms:

dig -x 203.0.113.5
# No answer section

Causes: - PTR not configured - Wrong DNS server - Propagation delay

Solutions: 1. Configure PTR record 2. Contact ISP if needed 3. Wait for DNS propagation (24-48 hours) 4. Verify zone delegation

PTR Mismatch

Symptoms:

dig mail.example.com → 203.0.113.5
dig -x 203.0.113.5 → other.example.com

Causes: - Incorrect PTR configuration - Multiple hostnames on IP - Outdated records

Solutions: 1. Update PTR to match A record 2. Ensure consistency 3. Wait for propagation

Multiple PTR Records

Problem:

203.0.113.5 has multiple PTR records:
- mail.example.com
- web.example.com

Impact: - Unpredictable results - Email delivery issues - Verification failures

Solution: - Use only one PTR per IP - Choose primary hostname - Remove extra PTRs

ISP Restrictions

Problem: - ISP won't set PTR - Residential connection - Dynamic IP

Solutions: 1. Upgrade to business plan 2. Get static IP 3. Use VPS/cloud server 4. Use email service provider

Best Practices

For Email Servers

  1. Match PTR to hostname - PTR should match HELO/EHLO
  2. Verify FCrDNS - Forward and reverse must match
  3. Use descriptive names - mail.example.com, not server1
  4. Monitor regularly - Check PTR hasn't changed
  5. Document configuration - Keep records of settings

For Web Servers

  1. Set meaningful PTR - web.example.com or www.example.com
  2. Match primary domain - Use main domain name
  3. Consistency - Same across all servers
  4. Update when changing - Keep PTR current
  5. Test after changes - Verify immediately

For Security

  1. Verify connections - Check PTR of connecting IPs
  2. Implement FCrDNS - Require forward-confirmed reverse
  3. Log hostnames - Include PTR in logs
  4. Monitor changes - Alert on PTR modifications
  5. Whitelist by hostname - More flexible than IP

For Network Administration

  1. Document all PTRs - Maintain inventory
  2. Use naming convention - Consistent scheme
  3. Regular audits - Verify accuracy
  4. Automate checks - Monitor PTR records
  5. Plan for changes - Update process documented

Conclusion

Reverse DNS is a critical component of internet infrastructure, particularly for email delivery and network identification. While often overlooked, proper rDNS configuration prevents email delivery issues, aids in troubleshooting, and enhances security.

Related Articles

DNS and Lookup Tools

Network Tools

Email and Security

Explore More

Key takeaways: - Reverse DNS maps IP addresses to hostnames using PTR records - Essential for email server reputation and deliverability - Requires control over IP address or ISP cooperation - Forward-confirmed reverse DNS (FCrDNS) provides verification - Used for security, logging, and network troubleshooting - One PTR record per IP address (best practice) - Must match forward DNS for email servers - Cloud providers offer easy PTR configuration - Regular verification prevents issues

Understanding and properly configuring reverse DNS ensures reliable email delivery, aids in network management, and contributes to overall internet infrastructure health.

ad placeholder image ad placeholder image
Three funny piglies - an illustration ippigly.com