Loading...

VONDS ©

Lab 76: Hostname or IP Lookup (nslookup and dig)

Lab Index

Validate forward and reverse DNS resolution using nslookup and dig without relying on a browser or GUI tooling. Confirm A and PTR record behavior and understand how to interpret “non-authoritative” responses during routine troubleshooting.

networking dns troubleshooting

Scenario

A user reports that a hostname resolves inconsistently, and a vendor is asking you to confirm whether reverse DNS is set up correctly for the IP address in use. Your job is to validate both forward and reverse lookups using standard CLI tools and capture enough evidence to support escalation if needed.

Operator context

DNS validation is a baseline check before assuming an application bug, firewall issue, or routing problem. Confirm forward (A/AAAA) and reverse (PTR) resolution early, then move on to packet-level or service-level debugging if DNS checks out.

Objective

  • Resolve a hostname to an IPv4 address using nslookup.
  • Query an A record using dig and identify the answer section.
  • Perform reverse DNS lookups (PTR) for an IP using dig -x.
  • Confirm reverse DNS results using nslookup for a second source of evidence.

What You’ll Practice

  • Forward DNS resolution (A record) using nslookup and dig.
  • Reverse DNS resolution (PTR record) using dig -x and nslookup.
  • Reading dig output: QUESTION vs ANSWER sections.
  • Interpreting “non-authoritative answer” during normal DNS queries.

Walkthrough

Targets

Forward lookup: www.example.com
Reverse lookup: 93.184.216.34

Step 1 : Resolve www.example.com using nslookup.
Command 
nslookup www.example.com

nslookup is a quick, widely available tool for verifying name resolution. The output typically shows which resolver you queried and whether the response is authoritative. 

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   www.example.com
Address: 93.184.216.34
Step 2 : Query the A record using dig.
Command 
dig www.example.com

dig provides structured output and is ideal when you need clean evidence for troubleshooting. Focus on the QUESTION and ANSWER sections to confirm what you asked for and what you received. 

;; QUESTION SECTION:
;www.example.com.        IN      A

;; ANSWER SECTION:
www.example.com.  3600    IN      A       93.184.216.34
Step 3 : Perform a reverse lookup using dig -x.
Command 
dig -x 93.184.216.34

Reverse DNS uses PTR records under in-addr.arpa. This is commonly required for email systems, some security tooling, and vendor allowlisting workflows. 

;; QUESTION SECTION:
;34.216.184.93.in-addr.arpa. IN PTR

;; ANSWER SECTION:
34.216.184.93.in-addr.arpa. 86400 IN PTR   www.example.com.
Step 4 : Confirm the reverse lookup using nslookup.
Command 
nslookup 93.184.216.34

Using a second tool helps confirm you are not misreading output and can be useful when documenting evidence for a ticket or vendor escalation. 

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
34.216.184.93.in-addr.arpa name = www.example.com.
Step 5 : Tighten output for “ticket-ready” evidence.
Command 
dig +short www.example.com
dig +short -x 93.184.216.34

+short produces minimal output that is easy to paste into tickets. Use full output when you need TTL, flags, or authoritative details. 

93.184.216.34
www.example.com.

Reference

  • nslookup <name> : Performs a DNS lookup for the given hostname.
  • nslookup <ip> : Performs a reverse DNS lookup for the given IP address (PTR).
  • dig <name> : Queries DNS and prints structured output (QUESTION/ANSWER sections).
  • dig -x <ip> : Performs a reverse lookup by querying the PTR record under in-addr.arpa.
  • dig +short : Returns minimal output suitable for quick validation and ticket evidence.