Mastering the dig Command: Red & Blue Team Perspectives

The dig (Domain Information Groper) command is one of the most powerful tools for interacting with the Domain Name System (DNS). It’s often used by system administrators, network engineers, penetration testers, and defenders to troubleshoot DNS issues, gather intelligence, or detect suspicious activities.

This article will walk you through dig fundamentals, provide code samples, explore red team vs. blue team use cases, and share pro tips for advanced usage.

What is dig?

dig is a DNS lookup utility that queries DNS servers directly. Unlike simple commands like nslookup, dig provides detailed output about DNS responses, including query times, authoritative servers, and record types.

Typical syntax:

dig [@server] domain [type]
  • @server → optional DNS server to query
  • domain → the target domain name
  • type → record type (A, AAAA, MX, TXT, NS, etc.)

Common Examples of using dig command

Lookup an A record

dig example.com A

Identify critical records

Find mail servers, lookup MX records

dig example.com MX

Check if all name servers are expected and correct. Get authoritative name servers

dig example.com NS

Query a specific DNS server

Avoid depending solely on your default DNS resolver. For authoritative and unaltered results, query a domain's authoritative name servers directly. You can discover these servers with a standard dig lookup, then run dig @<ns-server> <domain> to query them specifically.

dig @8.8.8.8 example.com

Perform a reverse DNS lookup

If a firewall or proxy log flags a suspicious IP address, this command can resolve it to its corresponding hostname. This may uncover the domain linked to a potential command-and-control (C2) server.

dig -x 93.184.216.34

Short output (IP only)

dig +short example.com

Red Team Usage

For attackers and penetration testers, dig is a reconnaissance tool to map out DNS infrastructure.

Zone Transfer Attempt

If misconfigured, DNS servers may allow AXFR (zone transfer) queries:

dig @ns1.example.com example.com AXFR

Many organizations disable this, but if it works, you gain the entire DNS zone file, exposing internal hosts and services.

Subdomain Enumeration

By querying authoritative name servers or brute forcing:

for sub in www mail vpn dev; do
  dig +short $sub.example.com
done

Gathering Mail Infrastructure

Mail servers can reveal third-party services or attack vectors:

dig example.com MX +short

TXT Records for Recon

Attackers look for SPF/DKIM/DMARC or internal notes:

dig example.com TXT

Blue Team Usage

Defenders use dig for monitoring, validation, and incident response.

Check DNS Resolution Consistency

dig example.com @1.1.1.1
dig example.com @8.8.8.8

If results differ, it may indicate DNS poisoning or manipulation.

Detect Unauthorized Zone Transfers

Regularly test your own DNS servers:

dig @ns1.yourdomain.com yourdomain.com AXFR

If it responds, fix immediately by restricting transfers.

Validate Email Security Policies

dig example.com TXT

Ensure SPF, DKIM, and DMARC are properly set.

Investigate Suspicious Traffic

If an alert flags a suspicious domain:

dig bad-domain.xyz ANY

Helps defenders see if attackers are using dynamic DNS or fast-flux.

Pro Tips for dig

  • Use +trace to follow resolution from root servers:

    dig example.com +trace

  • Use +nocmd +noquestion +noauthority +noadditional +nostats for clean outputs:

    dig example.com A +short

  • Batch query multiple records:

    dig example.com A example.com MX example.com TXT

  • Combine with grep/awk for automation:

    dig example.com MX +short | awk '{print $2}'

Detect potential DNS tunneling by checking unusual TXT records:

Because attackers often use them to exfiltrate data. DNS tunneling works by encoding data from an internal host into DNS queries and responses, which can bypass firewalls that are configured to allow DNS traffic. While A and MX records are also used, TXT records are particularly well-suited for tunneling because they can hold arbitrary string data up to 255 characters per string. This makes them an ideal container for small chunks of data. To check for unusual TXT records, you'll need to use dig with the TXT option.

dig suspicious.com TXT

A normal response for a legitimate domain might contain things like SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) records, which are used to prevent email spoofing.

Normal TXT Record Example:

example.com.      86400 IN TXT "v=spf1 include:_spf.google.com ~all"

This is a standard SPF record. It's concise and follows a predictable format.

Look for TXT records that contain unusually long or highly random-looking strings of characters. These often don't follow the structured format of legitimate records like SPF or DKIM.

Suspicious TXT Record Example:

example.com.      86400 IN TXT "t9G9s7kP2xL5hJ8rD4nB3qM1fC6aZ7eG5l8iK9oP2uY4tX3wV1z7t9rS6jK4fH8gD3oN1eQ2xL5cI8bU3vP1wS4fG7jK8hL2pB9nD4qC6aZ7eG5iL8kS9oP2uY4tX3wV1z7t9rS6jK4fH8gD3oN1eQ2xL5cI8bU3vP1wS4fG7jK8hL2pB9nD4qC6"

This string of characters is far too long and random to be a normal DNS record. It is likely encoded data being exfiltrated from a compromised system.

Correlate with Other Indicators To confirm a DNS tunneling threat, you need to look for other indicators in your network traffic logs.

IndicatorDescription
High Volume of QueriesA single compromised host will likely generate a large number of DNS queries to the same domain over a short period. Look for an unusually high frequency of DNS requests from a specific internal IP address.
Sequential DNS QueriesThe queries may follow a sequential pattern (e.g., part1.malicious.com, part2.malicious.com, etc.) as the data is broken down into smaller chunks.
Unusual Domain NamesThe domain itself may be recently registered or have a low reputation score. Tools like VirusTotal can help with this.

To streamline your investigation, you can script dig to automatically check for TXT records on a list of suspicious domains and then pipe the output to a tool that can analyze the strings for randomness or length.

Conclusion

The dig command is indispensable for both attackers and defenders.

  • Red teams exploit misconfigurations and gather intelligence.
  • Blue teams validate infrastructure, secure configurations, and investigate threats.

By mastering dig, you not only gain visibility into DNS but also sharpen your skills in both offense and defense.

Love it? Share this article: