Loading...

VONDS ©

Lab 76: DNS Lookup Validation

Back to Lab Index

Validate forward and reverse DNS resolution using nslookup and dig from the terminal. Capture clean evidence for A and PTR behavior and interpret common “non-authoritative” output 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 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 issue, firewall rule, 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 a reverse DNS lookup (PTR) for an IP using dig -x.
  • Confirm reverse DNS results using nslookup as a second source of evidence.
  • Produce “ticket-ready” evidence using dig +short.

Concepts

  • Forward versus reverse DNS resolution: A/AAAA records versus PTR records.
  • Resolver versus authoritative server: why “non-authoritative answer” is often normal.
  • Reading dig output: QUESTION and ANSWER sections as the core evidence.
  • Reverse lookup naming: PTR records under in-addr.arpa.
  • Evidence quality: when to use full output versus +short.

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 baseline check. Capture the resolved address and note whether the response is flagged as authoritative or non-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 suitable for tickets. Confirm the QUESTION matches the name you queried and the ANSWER contains the expected A record. 

;; 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. A valid answer proves the IP maps back to a name and provides evidence for vendor allowlisting and compliance 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

Confirming with a second tool reduces the risk of misreading output and strengthens your evidence when writing a ticket or escalation note. 

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 : Produce “ticket-ready” evidence with minimal output.
Commands 
dig +short www.example.com
dig +short -x 93.184.216.34

+short produces compact output that pastes cleanly into tickets. Use full output when you need TTLs, flags, or authoritative details. 

93.184.216.34
www.example.com.

Common breakpoints

nslookup returns NXDOMAIN

The name does not exist in DNS from the perspective of the resolver you queried. Confirm you have the correct hostname, then query a known resolver explicitly or verify the zone is published.

dig shows no ANSWER section

The query may have been refused, timed out, or answered with an empty response. Check for SERVFAIL, REFUSED, or timeouts, then verify connectivity to the resolver or authoritative server.

dig -x returns no PTR

Reverse DNS may not be configured for the IP block. This is common for consumer networks and some cloud environments unless explicitly set. Capture the output and escalate to the IP owner if reverse mapping is required.

“Non-authoritative answer” causes confusion

This usually means the resolver is responding from cache or via recursion rather than being the authoritative source for the zone. It does not automatically indicate a problem.

Cleanup checklist

This lab is read-only. Your cleanup is saving the output you captured and confirming you can reproduce the same results when troubleshooting the issue again.

Commands 
nslookup www.example.com
dig www.example.com
dig -x 93.184.216.34
dig +short www.example.com
dig +short -x 93.184.216.34
Success signal

You have consistent forward and reverse results, and you can paste concise evidence into a ticket without reformatting.

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 SECTION : Shows the exact name and record type requested.
    • ANSWER SECTION : Shows returned records, including TTL and value.
  • dig -x <ip> : Performs a reverse lookup by querying the PTR record under in-addr.arpa.
    • -x : Converts the IP into the corresponding reverse lookup name automatically.
  • dig +short : Returns minimal output suitable for quick validation and ticket evidence.
    • +short : Suppresses most sections and prints only result values.