July 31, 2026
Mastering the Dig Tool: A Beginner-Friendly Guide to DNS Lookup and Reconnaissance (Part 2)
In Part 1, we covered what DNS actually does, why Dig became my go-to tool early in my testing career, and how to get it installed and…
By Yamini Yadav_369
7 min read
In Part 1, we covered what DNS actually does, why Dig became my go-to tool early in my testing career, and how to get it installed and running. That part was about building the foundation. This part is where things get interesting.
Once you know the basics of Dig, the real skill is knowing which flags and record types to pull out during an actual engagement. I still remember one of my early recon sessions where I kept running plain dig domain.com over and over and wondering why I wasn't finding anything useful. The problem wasn't the tool. The problem was that I didn't know what else Dig could show me. This part fixes that gap.
Advanced Dig Commands
ANY Lookup
Command
dig accuknox.com ANYdig accuknox.com ANYPurpose Attempts to pull every record type a name server is willing to hand back in one shot.
Example
dig example.com ANYdig example.com ANYExpected Output Many modern resolvers now restrict or ignore ANY queries because of abuse in DNS amplification attacks, so you may get a partial response or nothing at all.
Why It Matters When ANY does work, it gives you a fast first impression of a domain's DNS footprint. When it doesn't, that tells you something too, since it hints the resolver has hardened its configuration.
CNAME Lookup
Command
dig cname www.example.comdig cname www.example.comPurpose Shows whether a subdomain is actually an alias pointing to another hostname.
Example
dig cname cdn.example.comdig cname cdn.example.comExpected Output A CNAME record pointing to something like d111111abcdef8.cloudfront.net.
Why It Matters CNAME chains are one of the first places I look for subdomain takeover opportunities. If a CNAME points to a service the target no longer owns, that's a red flag worth investigating further.
PTR Lookup
Command
dig -x 8.8.8.8dig -x 8.8.8.8Purpose Performs reverse DNS, turning an IP address back into a hostname.
Example
dig -x 104.26.10.229dig -x 104.26.10.229Expected Output A PTR record showing the hostname tied to that IP, if one has been configured.
Why It Matters Reverse lookups help you map out infrastructure and sometimes reveal internal naming conventions or hosting providers that the target never intended to expose.
SOA Lookup
Command
dig soa example.comdig soa example.comPurpose Retrieves the Start of Authority record, which holds administrative details about the zone.
Example
dig soa accuknoxxx.comdig soa accuknoxxx.comExpected Output Primary name server, admin contact (in a mangled email format), serial number, and refresh timers.
Why It Matters The serial number tells you when the zone was last updated. I use this to spot stale DNS configurations, which sometimes point to abandoned services still sitting on old records.
MX Lookup
Command
dig mx example.comdig mx example.comPurpose Lists the mail servers responsible for handling email for the domain.
Example
dig mx accuknoxxx.comdig mx accuknoxxx.comExpected Output A prioritized list of mail exchange servers, usually something like Google Workspace or a self-hosted mail server.
Why It Matters Knowing the mail provider tells you a lot about the organization's email security posture and helps when testing phishing-related attack surfaces during authorized engagements.
TXT Lookup
Command
dig txt example.comdig txt example.comPurpose Pulls text records, which often hold SPF, DKIM, domain verification strings, and sometimes leftover debug notes.
Example
dig txt accuknoxxx.comdig txt accuknoxxx.comExpected Output A list of quoted strings, each serving a different purpose.
Why It Matters I have found forgotten verification tokens, internal tool references, and weak SPF policies just by reading through TXT records carefully. This is one record type beginners tend to skim past too quickly.
NS Lookup
Command
dig ns example.comdig ns example.comPurpose Shows which name servers are authoritative for the domain.
Example
dig ns accuknox.comdig ns accuknox.comExpected Output A list of name servers, often revealing the DNS hosting provider.
Why It Matters This is usually the very first command I run on a new target because it tells me who controls the zone and whether the organization is using a major DNS provider or something self-managed.
CAA Lookup
Command
dig caa example.comdig caa example.comPurpose Reveals which certificate authorities are allowed to issue SSL certificates for the domain.
Example
dig caa accuknox.comdig caa accuknox.comExpected Output One or more CAA records naming approved certificate authorities.
Why It Matters If no CAA record exists, any public certificate authority can issue a certificate for that domain, which is worth flagging in a report as a hardening opportunity.
SRV Lookup
Command
dig srv _sip._tcp.example.comdig srv _sip._tcp.example.comPurpose Locates services like SIP, XMPP, or Active Directory that advertise themselves through service records.
Example
dig srv _ldap._tcp.example.comdig srv _ldap._tcp.example.comExpected Output Priority, weight, port, and target hostname for the service.
Why It Matters SRV records can quietly expose internal services and infrastructure that were never meant to be discoverable from outside.
DNSKEY Lookup
Command
dig dnskey example.comdig dnskey example.comPurpose Retrieves the public keys used for DNSSEC validation.
Example
dig dnskey accuknox.comdig dnskey accuknox.comExpected Output One or more cryptographic keys if DNSSEC is enabled, or nothing if it isn't.
Why It Matters This tells you immediately whether the domain has DNSSEC protection against cache poisoning and spoofing attacks.
Reverse Lookup Shortcut
Command
dig -x 192.168.1.1 +shortdig -x 192.168.1.1 +shortPurpose Same as the PTR lookup but trimmed down for quick reading.
Why It Matters When you are reverse resolving dozens of IPs during recon, the short output saves a lot of scrolling.
Trace
Command
dig +trace example.comdig +trace example.comPurpose Walks the entire DNS resolution path starting from the root servers down to the authoritative name server.
Expected Output A step-by-step chain showing every server involved in resolving the domain.
Why It Matters Trace is how I debug weird DNS behavior. If something looks broken along the chain, this command usually shows exactly where.
+short
Command
dig example.com +shortdig example.com +shortPurpose Strips away the header and additional sections, leaving just the answer.
Why It Matters When you are scripting recon or checking dozens of domains, +short keeps your output clean enough to pipe into other tools.
+stats
Command
dig example.com +statsdig example.com +statsPurpose Displays query timing and packet size statistics.
Why It Matters Useful for spotting unusually slow resolvers or oversized responses that might indicate misconfiguration.
+tcp
Command
dig example.com +tcpdig example.com +tcpPurpose Forces the query over TCP instead of the default UDP.
Why It Matters: Some responses, especially DNSSEC-heavy ones, are too large for UDP and get truncated. Forcing TCP avoids that truncation.
+dnssec
Command
dig example.com +dnssecdig example.com +dnssecPurpose: Requests DNSSEC-related records alongside the normal answer.
Why It Matters: This is how you confirm whether a zone is actually signed, rather than just assuming it based on a DNSKEY record existing somewhere.
+ identify
Command
dig example.com +identifydig example.com +identifyPurpose: Shows which server actually answered the query.
Why It Matters: Handy when you are querying multiple resolvers and need to confirm which one gave you which answer.
+multiline
Command
dig dnskey example.com +multilinedig dnskey example.com +multilinePurpose: Formats long or complex records across multiple lines for readability.
Why It Matters: DNSKEY and RRSIG records get messy in a single line. This flag makes note-taking during reporting much easier.
Custom DNS Server
Command
dig example.com @1.1.1.1dig example.com @1.1.1.1Purpose: Sends the query directly to a specific resolver instead of your system default.
Why It Matters Different resolvers can return different results due to caching or regional differences, so querying several gives you a fuller picture.
Google DNS
Command
dig example.com @8.8.8.8dig example.com @8.8.8.8Purpose: Queries Google's public resolver directly.
Why It Matters Good as a neutral reference point when you suspect your local resolver is returning cached or manipulated results.
Cloudflare DNS
Command
dig example.com @1.1.1.1dig example.com @1.1.1.1Purpose: Queries Cloudflare's public resolver.
Why It Matters Cloudflare's resolver is fast and widely used as a second opinion alongside Google's.
Authoritative Server Lookup
Command
dig example.com @ns1.example.comdig example.com @ns1.example.comPurpose: Queries the domain's own authoritative server directly, bypassing caching layers entirely.
Why It Matters: This gives you the freshest possible answer, useful when you suspect propagation delays are hiding recent changes.
Root Server Lookup
Command
dig . NSdig . NSPurpose: Lists the thirteen root server clusters that anchor the entire DNS system.
Why It Matters Mostly educational, but understanding the root layer helps when you're troubleshooting a broken trace chain.
Retry
Command
dig example.com +tries=5dig example.com +tries=5Purpose: Sets how many times Dig retries a query before giving up.
Why It Matters: Useful on unstable networks or when testing against rate-limited resolvers.
Timeout
Command
dig example.com +time=2dig example.com +time=2Purpose: Controls how long Dig waits for a response before timing out.
Why It Matters: Speeds up bulk recon scripts by not letting a single unresponsive server stall the whole process.
Real-World Reconnaissance Example
Picture this. You are handed a single domain for an authorized security assessment, nothing else. No subdomain list, no architecture diagram, nothing.
The first thing I do is run an NS lookup to see who controls the zone. That immediately tells me whether I'm dealing with a major cloud DNS provider or something more custom.
Next comes MX, which tells me the mail provider. This matters because email security posture often reflects the broader security culture of the organization.
Then I check TXT records carefully, looking for SPF policies, domain verification strings, or leftover debug entries that shouldn't be public.
After that, DNSKEY and a DNSSEC-specific query tell me whether the zone is signed, which affects how confident I can be that DNS responses haven't been tampered with along the way.
Finally, I reverse resolve any IPs I've gathered so far using PTR lookups, which sometimes reveals hosting provider naming conventions or internal server labels.
By the time I'm done, I haven't touched a single login page or sent a single exploit. I've simply built a map of the target's DNS footprint, and that map shapes everything that comes next in the engagement.
- Use 'short' whenever you can. It keeps your terminal clean, especially when checking many domains in a row.
- Cross-check Google and Cloudflare resolvers. If the answers differ, that's worth digging into further.
- Watch out for DNS propagation delays. A record change can take hours to reflect everywhere.
- Save your output to a file. Use it
dig example.com >> recon-notes.txtso you have a paper trail for your report. - Always confirm the authoritative server. Querying it directly avoids stale cached answers.
- Pay attention to TTL values. Low TTLs sometimes hint at active infrastructure changes.
- Don't skip TXT records. They're boring until they're not.
- Reverse lookups during recon are underrated. They can reveal more about hosting setups than you'd expect.
- Query from more than one resolver. Different networks sometimes see different answers due to caching or geo-routing.
- Keep organized notes. When you're writing up findings later, you'll thank yourself for logging commands and outputs as you went.
That covers the advanced side of Dig, from record types you might not have touched before to flags that make your queries faster, cleaner, and more reliable. At this point you should be comfortable pulling apart a domain's entire DNS footprint using nothing but a terminal.
In Part 3, we'll go further into how Dig fits into real penetration testing workflows, common DNS misconfigurations testers run into, how DNS ties into broader infrastructure discovery, mistakes beginners tend to make, and some frequently asked questions I've gotten from readers of this series so far.
See you in Part 3.