DNS Fundamentals for Penetration Testers: Query Types & Record Analysis

Introduction

Domain Name System (DNS) is the phonebook of the Internet. For penetration testers, DNS is not just a convenience layer; it is a rich source of reconnaissance data, a pivot point for attacks, and a vector for data exfiltration. Mastering DNS query mechanics, record types, and response parsing enables you to discover hidden assets, enumerate sub-domains, and even manipulate traffic for exploitation.

This guide walks you through the core concepts and practical techniques you need to interrogate DNS reliably, extract only the data you care about, and understand the security implications of what you find.

Prerequisites

• Basic networking concepts: IPv4/IPv6 addressing, TCP/UDP transport, and the role of port 53.
• Comfort with a command-line interface on Linux/macOS or Windows (PowerShell).
• Understanding of OSI Layer 3 (Network) and Layer 4 (Transport) - DNS operates at the application layer but relies on UDP/TCP at Layer 4.

Core Concepts

DNS is a hierarchical, distributed database that resolves human-readable names to machine-readable resources. The system is built around zones (authoritative portions) and resolvers (recursive or stub). Queries travel from the client to a resolver, which may recurse through the hierarchy or return cached data.

Key terms:

• Query type (QTYPE): The kind of record you are asking for (A, MX, TXT, etc.).
• Query class (QCLASS): Almost always IN (Internet).
• Response sections: Answer, Authority, Additional - each provides different context.
• TTL (Time-to-Live): How long a resolver may cache the record before re-querying.

From a security perspective, each of these elements can be abused: zone transfers (AXFR) for bulk enumeration, mis-configured TXT records for credential leakage, or low TTL values that enable fast-flux techniques.

Common DNS record types (A, AAAA, MX, TXT, CNAME, NS, SRV, PTR)

Understanding what each record type conveys is the foundation of DNS-based recon.

• A (Address): IPv4 address of a host. Example: IN A 93.184.216.34
• AAAA (IPv6 Address): IPv6 counterpart. Example: IN AAAA 2606:2800:220:1:248:1893:25c8:1946
• MX (Mail Exchange): Mail server priority and hostname. Example: example.com. IN MX 10 mail.example.com.
• TXT (Text): Arbitrary text. Frequently used for SPF, DKIM, DMARC, or custom data exfiltration. Example: example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 -all"
• CNAME (Canonical Name): Alias to another name. Example: blog.example.com. IN CNAME sites.example.net.
• NS (Name Server): Authoritative name servers for a zone. Example: example.com. IN NS ns1.provider.net.
• SRV (Service): Location of services (port, priority, weight). Example: _sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.
• PTR (Pointer): Reverse lookup - maps IP to hostname. Example: 34.216.184.93.in-addr.arpa. IN PTR www.example.com.

When performing penetration testing, you’ll typically start with A/AAAA to map the attack surface, then harvest MX/TXT for mail-related vectors, follow CNAME chains to find hidden services, and finally probe SRV for uncommon protocols.

Using dig, nslookup, and host for queries

Three ubiquitous utilities let you interact with DNS from the console. Each has strengths:

• dig - the most flexible, script-friendly, and provides granular control over every DNS flag.
• nslookup - legacy, interactive mode useful for quick lookups on Windows.
• host - concise output, great for one-liners.

Below are common patterns.

Basic A record lookup with dig

dig +noall +answer example.com A

Output:

example.com. 3600 IN A 93.184.216.34

Querying all record types

dig example.com ANY +multiline

Note: Many modern resolvers restrict ANY responses for security; use individual queries when needed.

Using nslookup in interactive mode

nslookup
> set type=mx
> example.com

Result:

example.com mail exchanger = 10 mail.example.com.

Quick PTR lookup with host

host 93.184.216.34

Result:

34.216.184.93.in-addr.arpa domain name pointer www.example.com.

All three tools can be scripted; dig is preferred for automation because its output can be filtered with +short, +noall, and +answer flags.

Interpreting DNS response sections (Answer, Authority, Additional)

A DNS response is divided into three logical sections. Understanding each helps you infer the resolver’s behavior and locate hidden data.

• Answer: Direct response to the query - the records you asked for (or synthesized by the server).
• Authority: Name servers that are authoritative for the queried zone. When a resolver can’t answer directly, it provides NS records here to indicate where to continue the lookup.
• Additional: Supplemental records, often the A/AAAA of the NS records in the Authority section, or related records (e.g., glue records) needed to complete the resolution without extra queries.

Example: querying dig against a non-authoritative resolver may return:

;; ANSWER SECTION:
www.sub.example.com. 300 IN CNAME sub.example.com.

;; AUTHORITY SECTION:
example.com. 172800 IN NS ns1.provider.net.
example.com. 172800 IN NS ns2.provider.net.

;; ADDITIONAL SECTION:
ns1.provider.net. 86400 IN A 203.0.113.10
ns2.provider.net. 86400 IN A 203.0.113.11

From a pentester’s viewpoint, the Authority and Additional sections reveal the true infrastructure - even if the Answer is an alias. Collecting glue records can help you map the internal DNS hierarchy of a target organization.

Recursive vs. iterative queries and +trace option

Recursive query: The client asks the resolver to do all the work and return the final answer. Most public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) operate recursively by default.

Iterative query: The client asks a specific server for the answer; the server either replies with the data it has or points to the next server (NS). This is the method used by authoritative name servers during zone transfers.

To see each step of the resolution path, use dig +trace:

dig +trace example.com

Output (truncated):

; << DiG 9.16.1-Ubuntu >> +trace example.com
;; global options: +cmd
. 518400  IN NS a.root-servers.net.
... (root servers) ...
com. 172800  IN NS a.gtld-servers.net.
... (gtld servers) ...
example.com. 172800  IN NS ns1.provider.net.
ns1.provider.net. 86400 IN A 203.0.113.10
example.com. 3600 IN A 93.184.216.34

Each block shows the response from a different server in the chain, exposing the delegation path. Attackers can use this to discover hidden sub-domains that are delegated to internal name servers not listed publicly.

TTL values and caching behavior

TTL (Time-to-Live) is a 32-bit field that tells resolvers how long a cached record is considered fresh. Low TTLs (< 300 seconds) are typical for fast-flux or CDN records; high TTLs (> 86400 seconds) indicate static infrastructure.

From a testing perspective:

1. Identify low-TTL records - they may be part of a fast-changing service (e.g., malicious C2 domains).
2. Force a cache refresh by querying a non-recursive server or by flushing the local cache (sudo systemd-resolve --flush-caches on Linux).
3. Use TTL analysis to infer the stability of a target’s DNS architecture - high TTLs can mean static, long-lived assets, while low TTLs hint at dynamic or deliberately obfuscated setups.

Example of TTL inspection with dig:

dig +noall +answer +ttl example.com A

Result:

example.com. 300 IN A 93.184.216.34

Here the TTL of 300 seconds (5 minutes) suggests the record may be refreshed frequently.

Query flags (+short, +noall, +answer) for efficient data extraction

When scripting large-scale reconnaissance, you rarely need the full dig output. The following flag combinations are common:

• +short: Returns only the answer data, one line per record.
• +noall +answer: Suppresses everything except the Answer section (useful when you need the full RR format but not the header).
• +time=2 +tries=1: Lowers timeout and retry count for faster scans.

Example: enumerate all IPv4 addresses for a list of sub-domains in a Bash one-liner:

while read sub; do dig +noall +answer $sub A | awk '{print $5}'; done < subdomains.txt

Result - each line contains just the IP address, perfect for feeding into a scanner.

Practical Examples

1. Sub-domain enumeration via DNS zone transfer (AXFR)

Many mis-configured DNS servers allow anonymous zone transfers. Use dig to test:

dig @ns1.example.com example.com AXFR +noall +answer

If the server permits it, you’ll receive a full list of records, revealing internal hosts, service names, and sometimes even service accounts embedded in TXT records.

2. Extracting SPF & DKIM data from TXT records

dig +short TXT example.com

Typical output:

"v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"
"v=DMARC1; p=none; rua=mailto:[email protected]"

Analyse the include mechanisms to discover third-party mail services that can be targeted for phishing or credential harvesting.

3. Discovering hidden services via SRV records

dig _ldap._tcp.example.com SRV +short

Result:

0 100 389 ldap1.example.com.
0 100 389 ldap2.example.com.

Each SRV entry reveals the hostname and port for LDAP, which can be probed for anonymous binds or credential dumping.

Tools & Commands

• dig - installed on most *nix systems. Full documentation via man dig.
• nslookup - native Windows tool, also available on Linux.
• host - lightweight, part of the bind-utils package.
• dnsrecon - Python script that automates many of the above queries and includes brute-force sub-domain enumeration.
• massdns - high-performance DNS scanner for large wordlists.

Sample dig command with multiple flags for bulk enumeration:

dig +noall +answer +time=1 +tries=1 any.example.com

Expected output (truncated):

example.com. 3600 IN A 93.184.216.34
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 -all"

Defense & Mitigation

From a defensive standpoint, understanding how attackers abuse DNS helps you harden your environment.

• Restrict zone transfers: Allow AXFR only to authorized secondary servers (ACLs on BIND, allow-transfer directive).
• Sanitize TXT records: Avoid embedding secrets; use separate secret management solutions.
• Implement DNSSEC: Provides integrity verification, preventing cache poisoning.
• Monitor low-TTL records: Alert on sudden TTL drops which may indicate fast-flux or C2 activity.
• Rate-limit recursive queries on internal resolvers to mitigate DNS amplification attacks.

Common Mistakes

• Relying on ANY queries: Modern resolvers truncate or block ANY responses, leading to incomplete data.
• Ignoring authority/additional sections: Valuable glue records are often missed, causing blind spots in internal mapping.
• Assuming public DNS equals internal DNS: Many organizations host split-horizon zones; internal resolvers may expose hosts not visible externally.
• Forgetting about IPv6 records: AAAA and PTR for IPv6 can hide assets that scanners miss.
• Overlooking DNSSEC failures: A failed DNSSEC validation can be a sign of tampering; ignoring it loses a detection vector.

Real-World Impact

In 2023, a major healthcare provider suffered a breach after attackers enumerated internal services via mis-configured SRV and TXT records, gaining LDAP credentials that led to patient record exfiltration. The root cause was an open recursive resolver that answered internal queries from the Internet.

My experience with red-team engagements shows that a quick dig +trace often uncovers hidden delegation to internal name servers, which can be leveraged to pivot into the internal network via DNS rebinding or sub-domain takeover.

Trend outlook: With the rise of DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT), attackers are moving to encrypted queries to hide reconnaissance. However, the fundamental record types and response parsing remain unchanged, making this knowledge evergreen.

Practice Exercises

1. Zone Transfer Hunt: Identify a public domain, query its NS records, then attempt AXFR against each NS. Document any records returned.
2. TTL Analysis: Pick 10 sub-domains of a target, record their TTLs using dig +ttl. Plot the TTL distribution and hypothesize why certain records have low values.
3. SRV Enumeration: Use dig to query common service prefixes (_ldap, _sip, _kerberos) for a target domain. Map the discovered services to potential attack vectors.
4. Automation Script: Write a Bash script that reads a list of domains, extracts A, AAAA, and MX records with +short, and writes them to a CSV file for later analysis.

These labs reinforce the concepts and give you tangible data to practice on.

Further Reading

• RFC 1035 - Domain Names - Implementation and Specification (the DNS bible).
• RFC 4034/4035 - DNSSEC Introduction and Implementation.
• “DNS Reconnaissance for Penetration Testers” - Black Hat 2022 presentation.
• Tools: dnsrecon, massdns, PowerSploit's Invoke-DNSLookup.

Summary

DNS is a treasure trove of information for penetration testers. By mastering record types, leveraging powerful query tools, interpreting response sections, and understanding recursion, TTL, and flag usage, you can efficiently map an organization’s attack surface. Combine these techniques with defensive awareness—restrict transfers, monitor low TTLs, and enforce DNSSEC—to both discover and mitigate DNS-related risks.

Keep the following cheat-sheet handy:

• dig +short A example.com - Quick IPv4
• dig +noall +answer MX example.com - Full MX record
• dig +trace example.com - Full delegation path
• dig @ns1.example.com example.com AXFR - Test zone transfer
• dig +short TXT _dmarc.example.com - Retrieve DMARC policy

Use these commands as building blocks for deeper recon, and you’ll be able to turn DNS from a passive lookup service into an active intelligence source.