Forward and Reverse DNS Lookup Explained

2. Forward DNS Lookup — Name to IP

A forward DNS lookup starts with a hostname (domain name) and returns the corresponding IP address. This is the most common DNS operation — it underpins every website visit, email delivery, API call, and cloud service connection.

The A Record (IPv4)

The A record (Address record) is the core record type for forward lookups in IPv4 networks. It maps a fully qualified domain name (FQDN) to a 32-bit IPv4 address.

; Zone file entry — A record syntax:
; <name>    <TTL>  <class>  <type>  <IP address>
example.com.  3600   IN       A       93.184.216.34
www.example.com.  300  IN     A       93.184.216.34

; A domain can have multiple A records (round-robin load balancing):
google.com.   60    IN       A       142.250.183.14
google.com.   60    IN       A       142.250.183.46
google.com.   60    IN       A       142.250.183.78

The AAAA Record (IPv6)

The AAAA record (Quad-A record) maps a hostname to a 128-bit IPv6 address. When a client supports both IPv4 and IPv6, modern operating systems query for both A and AAAA simultaneously (using Happy Eyeballs) and use whichever responds first. See IPv6 Addressing for IPv6 address format details.

example.com.   3600   IN   AAAA   2606:2800:220:1:248:1893:25c8:1946

; Verify with dig:
$ dig example.com AAAA
;; ANSWER SECTION:
example.com. 3598 IN AAAA 2606:2800:220:1:248:1893:25c8:1946

3. The Forward Lookup Resolution Process — Step by Step

When your browser needs to connect to www.example.com, the OS goes through a precisely ordered resolution sequence before a single TCP byte is sent.

  You type: www.example.com in browser

  Step 1: Local hosts file check
  ┌─────────────────────────────────────────────┐
  │ OS checks /etc/hosts (Linux) or             │
  │ C:\Windows\System32\drivers\etc\hosts       │
  │ If match found → use it immediately (done)  │
  └─────────────────────────────────────────────┘
          │ No match
          ▼
  Step 2: Local DNS cache check
  ┌─────────────────────────────────────────────┐
  │ OS checks its DNS resolver cache            │
  │ If valid TTL still active → use cached IP   │
  └─────────────────────────────────────────────┘
          │ Cache miss / expired
          ▼
  Step 3: Recursive resolver query
  ┌─────────────────────────────────────────────┐
  │ OS sends DNS query to configured resolver   │
  │ (e.g., 8.8.8.8 or ISP's DNS)               │
  │ Resolver checks its own cache first         │
  └─────────────────────────────────────────────┘
          │ Cache miss
          ▼
  Step 4: Root server query
  ┌─────────────────────────────────────────────┐
  │ Resolver queries a root server (.)          │
  │ 13 root server clusters worldwide           │
  │ Root returns: "Ask .com TLD servers"        │
  └─────────────────────────────────────────────┘
          │
          ▼
  Step 5: TLD server query
  ┌─────────────────────────────────────────────┐
  │ Resolver queries .com TLD server            │
  │ TLD returns: "Ask ns1.example.com"          │
  └─────────────────────────────────────────────┘
          │
          ▼
  Step 6: Authoritative server query
  ┌─────────────────────────────────────────────┐
  │ Resolver queries ns1.example.com            │
  │ Authoritative server returns A record:      │
  │ www.example.com → 93.184.216.34             │
  │ (with TTL, e.g., 300 seconds)               │
  └─────────────────────────────────────────────┘
          │
          ▼
  Step 7: Answer returned and cached
  ┌─────────────────────────────────────────────┐
  │ Resolver caches answer for TTL seconds      │
  │ Returns 93.184.216.34 to client             │
  │ Client caches it locally                    │
  │ Browser connects to 93.184.216.34:443       │
  └─────────────────────────────────────────────┘
            

DNS Server Roles

4. CNAME Records and Resolution Chains

A CNAME (Canonical Name) record is an alias — it maps one hostname to another hostname rather than directly to an IP address. The resolver follows the chain until it reaches a record with an actual IP address.

; DNS zone entries:
www.example.com.     300  IN  CNAME  example.com.
example.com.        3600  IN  A      93.184.216.34

; Resolution chain for www.example.com:
Step 1: Query www.example.com → returns CNAME → example.com
Step 2: Query example.com → returns A → 93.184.216.34
Final: www.example.com = 93.184.216.34

; Website owner's DNS:
www.mysite.com.    CNAME    mysite.cdn.example.net.

; CDN's DNS (returns different IPs based on user location):
mysite.cdn.example.net.    A    104.16.249.249   (US user)
mysite.cdn.example.net.    A    198.41.215.162   (EU user)

5. TTL — Time To Live and Its Impact

Every DNS record carries a TTL (Time To Live) value in seconds. When a recursive resolver caches a DNS answer, it keeps it for exactly TTL seconds, then must re-query for a fresh answer. TTL is a critical operational parameter with real-world consequences.

; dig shows TTL in the ANSWER section:
$ dig example.com

;; ANSWER SECTION:
example.com.   299    IN    A    93.184.216.34
               ↑
               TTL = 299 seconds remaining until cache expires
               (was 300 seconds when first cached; counts down)

6. Reverse DNS Lookup — IP to Name

A reverse DNS lookup starts with an IP address and returns the corresponding hostname. This is the inverse of the normal forward lookup. Where forward lookups use A records in regular forward zones, reverse lookups use PTR (Pointer) records in special reverse zones under the .arpa top-level domain.

Why Reverse DNS Exists

• Email deliverability: Receiving mail servers check that the sending IP has a PTR record matching the mail server's HELO hostname — a missing or mismatched PTR is one of the most common causes of email being rejected as spam.
• Security logging: Syslog, firewall logs, and network monitoring tools automatically perform reverse lookups to show hostnames instead of raw IPs — making logs far more readable and actionable.
• Network troubleshooting: Tools like traceroute display hostnames for each hop IP, making path analysis much easier.
• Identity verification: Some services verify that a connecting IP's PTR record matches its claimed hostname (forward-confirmed reverse DNS / FCrDNS).

7. The PTR Record and in-addr.arpa Zone

Reverse DNS uses a special trick to fit into the normal DNS hierarchy: the IP address is written backwards and appended with .in-addr.arpa. This reversed format means the DNS hierarchy still works left-to-right from least specific to most specific — just like forward DNS.

How in-addr.arpa Is Constructed

  Forward zone:   example.com  →  93.184.216.34
  ┌─────────────────────────────────────────────────┐
  │ IP address:  93  . 184 . 216 .  34              │
  │              ↓      ↓     ↓     ↓               │
  │ Reversed:    34  . 216 . 184 .  93              │
  │              ↓                                  │
  │ + .in-addr.arpa:                                │
  │              34.216.184.93.in-addr.arpa.        │
  └─────────────────────────────────────────────────┘

  PTR record entry in reverse zone:
  34.216.184.93.in-addr.arpa.   3600   IN   PTR   example.com.

  Why reversed? The DNS hierarchy reads left-to-right from
  least-specific to most-specific. In an IP address:
  93 = most specific (host) — put it at the front so DNS
  can delegate by the left portion (93.in-addr.arpa,
  184.93.in-addr.arpa, etc.)

Reverse Zone Examples

8. IPv6 Reverse DNS — ip6.arpa

IPv6 uses the same conceptual approach as IPv4 for reverse DNS, but with the .ip6.arpa. zone instead of .in-addr.arpa.. The full 128-bit IPv6 address is expanded to its full form, all colons removed, each hex digit becomes a separate label, and the entire string is reversed.

  IPv6 address: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

  Step 1: Expand to full form (no abbreviations):
  2001:0db8:85a3:0000:0000:8a2e:0370:7334

  Step 2: Remove colons, write as flat hex string:
  20010db885a3000000008a2e03707334

  Step 3: Insert dots between each hex digit:
  2.0.0.1.0.d.b.8.8.5.a.3.0.0.0.0.0.0.0.0.8.a.2.e.0.3.7.0.7.3.3.4

  Step 4: Reverse the order:
  4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2

  Step 5: Append .ip6.arpa.:
  4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.

  PTR record:
  4.3.3.7...2.ip6.arpa.  IN  PTR  myserver.example.com.

  ! dig handles this automatically:
  $ dig -x 2001:db8:85a3::8a2e:370:7334

9. Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS (also called forward-confirmed rDNS or matching PTR) is a security verification technique that checks both the PTR record of an IP and the A record of the resulting hostname — confirming they point to each other. This prevents PTR records being set to arbitrary hostnames.

  FCrDNS Verification (used by email servers):

  Step 1: Connecting mail server IP = 198.51.100.25
  Step 2: PTR lookup → dig -x 198.51.100.25
          Returns: mail.example.com.
  Step 3: Forward lookup → dig mail.example.com A
          Returns: 198.51.100.25

  ✅ PASS: IP → PTR hostname → back to same IP
  (Forward-confirmed: the PTR is authentic)

  ✗ FAIL example:
  Step 2: PTR lookup → Returns: mail.spoofed-name.com.
  Step 3: Forward lookup → Returns: 10.0.0.1 (different IP!)
  ❌ FAIL: PTR not confirmed by forward lookup — suspicious

10. Forward vs Reverse Lookup — Full Comparison

11. Practical dig and nslookup Examples

Forward Lookups

! Basic A record lookup
$ dig google.com
;; ANSWER SECTION:
google.com.   60   IN   A   142.250.190.46

! IPv6 address lookup
$ dig google.com AAAA
;; ANSWER SECTION:
google.com.   60   IN   AAAA   2a00:1450:4009:80c::200e

! Follow CNAME chain
$ dig www.example.com
;; ANSWER SECTION:
www.example.com.   300   IN   CNAME   example.com.
example.com.      3600   IN   A       93.184.216.34

! Query a specific DNS server (bypass your resolver)
$ dig @1.1.1.1 google.com

! Short output (just the IP) — great for scripts
$ dig google.com +short
142.250.190.46

! Windows nslookup
C:\> nslookup google.com
Server:  192.168.1.1
Address: 192.168.1.1

Name:    google.com
Addresses:  142.250.190.46

Reverse Lookups

! dig reverse lookup (automatic in-addr.arpa construction)
$ dig -x 8.8.8.8
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.    IN   PTR

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

! Another example — Google's other DNS server
$ dig -x 8.8.4.4
;; ANSWER SECTION:
4.4.8.8.in-addr.arpa.  21599  IN  PTR  dns.google.

! Reverse lookup using nslookup (Windows/Linux)
$ nslookup 142.250.190.46
46.190.250.142.in-addr.arpa   name = lhr25s29-in-f14.1e100.net.

! Manual in-addr.arpa query (equivalent to dig -x)
$ dig 34.216.184.93.in-addr.arpa PTR

12. Common Issues and Troubleshooting

For a broader network connectivity diagnostic workflow, see Troubleshooting Connectivity.

13. Common Misconceptions

• "A record and PTR record always exist in pairs."
  Not necessarily. A PTR record is optional (though important for mail). Many IPs have no PTR record at all. And critically, A records and PTR records are managed independently — the A record is in your domain zone (which you control), while the PTR record is in the reverse zone managed by the IP address owner (your ISP). You can have an A record pointing to an IP with no PTR record.
• "Changing the A record immediately updates everyone."
  DNS changes propagate only as fast as the TTL allows. If your TTL is 86400 seconds (24 hours), every resolver that cached the old record will continue returning the old IP for up to 24 hours. Pre-reduce TTL before any DNS change, and wait for the old TTL to expire before making the cutover.
• "Reverse DNS is the same as just looking up the PTR record manually."
  The dig -x command and nslookup <IP> both automatically construct the reversed .in-addr.arpa query — you don't need to do the reversal yourself. But internally, that is exactly what happens: the tool reverses the IP octets and appends .in-addr.arpa. before sending the query.
• "A missing PTR record only affects email."
  Missing PTR records can affect: email deliverability, security tool fingerprinting, syslog hostname resolution, access control on some SSH/FTP servers (which check for matching PTR), and network monitoring readability. Email is the most visible impact but not the only one.

14. Key Points & Exam Tips

• Forward lookup: name → IP. Uses A record (IPv4) or AAAA record (IPv6).
• Reverse lookup: IP → name. Uses PTR record in .in-addr.arpa (IPv4) or .ip6.arpa (IPv6).
• PTR zone construction: reverse the IP octets and append .in-addr.arpa. — e.g., 93.184.216.34 becomes 34.216.184.93.in-addr.arpa.
• PTR records are owned by the IP block owner (ISP/hosting), not the domain owner — contact your ISP to create or update PTR records.
• TTL controls how long resolvers cache a DNS answer. Low TTL = fast propagation but more queries. High TTL = less load but slow updates.
• CNAME aliases one hostname to another — resolvers follow the chain until reaching an A/AAAA record. Cannot coexist with other record types at the same name.
• Resolution order on most OS: hosts file → local DNS cache → recursive resolver → root → TLD → authoritative.
• Authoritative server holds official records (aa flag in dig). Recursive resolver caches and queries on clients' behalf.
• FCrDNS: IP → PTR hostname → forward lookup back to same IP — confirms PTR authenticity. Critical for email deliverability.
• Tools: dig example.com (forward), dig -x 8.8.8.8 (reverse), nslookup example.com (forward), nslookup 8.8.8.8 (reverse).

Related pages: How DNS Works | DNS Record Types | dig Command | nslookup Command | DNS Overview

15. Forward and Reverse DNS Lookup Quiz