4.2 DNS Infrastructure, Record Types & Zone Transfers

4.2 DNS Infrastructure, Record Types & Zone Transfers

The Domain Name System (DNS) serves as the directory service of the Internet, translating human-friendly Fully Qualified Domain Names (FQDNs) into routable IP addresses. For a penetration tester, DNS is one of the richest sources of architectural intelligence. A thorough understanding of DNS hierarchy, resource record structures, and query mechanics enables analysts to map internal network layouts, locate authentication servers, identify high-value targets, and uncover misconfigurations that reveal entire namespaces.

---

1. DNS Resolution Hierarchy & Transport Mechanics

The DNS namespace is an inverted hierarchical tree originating at the Root Domain, represented textually by a single dot (.):

                              [ . (Root) ]
                                    │
        ┌───────────────────────────┼───────────────────────────┐
        ▼                           ▼                           ▼
     [ .com ]                    [ .uk ]                     [ .org ]     (TLDs)
        │                           │                           │
   [ target.com ]             [ co.uk ]                  [ foundation.org ](Second-Level)
        │                           │
  [ corp.target.com ]        [ police.uk ]                                (Subdomains)
        │
 [ dc01.corp.target.com ]                                                 (Hosts/FQDNs)

The Resolution Ecosystem

1. Root Name Servers: 13 logical root server identities (named a.root-servers.net through m.root-servers.net) operated by 12 independent organizations, distributed globally across hundreds of physical nodes using Anycast routing.
2. Top-Level Domain (TLD) Servers: Authoritative for global TLDs (generic gTLDs like .com, .net, .org and country-code ccTLDs like .uk, .de, .jp).
3. Authoritative Name Servers: The definitive servers responsible for publishing resource records for a specific domain. The Master (Primary) server holds the read-write zone database, while Slave (Secondary) servers maintain read-only replicas synchronized via zone transfers.
4. Recursive Resolvers (Caching Resolvers): Intermediate DNS servers (such as corporate internal resolvers, ISP servers, or public resolvers like 8.8.8.8 or 1.1.1.1) that query the authoritative hierarchy on behalf of end-user client stub resolvers and cache responses according to Time-to-Live (TTL) values.

Iterative vs. Recursive Query Resolution

• Recursive Query: The client instructs the resolver: "Give me the complete answer for portal.target.com, or return an error." The resolver takes complete responsibility for tracking down the address.
• Iterative Query: The resolver queries nameservers down the tree. Each authoritative nameserver replies: "I don't know the final IP address, but you should query this nameserver who is closer to the answer."

Client Stub ──► Recursive Resolver
                       │
                       ├── 1. Iterative Query: portal.target.com? ──► Root Server (.)
                       │◄── 2. Referral: Query .com TLD Server ──────┘
                       │
                       ├── 3. Iterative Query: portal.target.com? ──► .com TLD Server
                       │◄── 4. Referral: Query ns1.target.com ────────┘
                       │
                       ├── 5. Iterative Query: portal.target.com? ──► ns1.target.com (Auth)
                       │◄── 6. Authoritative Answer: 198.51.100.25 ──┘
                       │
Client Stub ◄──────────┴── Final Answer: 198.51.100.25

Transport Layer Protocol & Port Mechanics

• UDP Port 53: Used for standard DNS queries and responses. Under RFC 1035, legacy UDP DNS messages were capped at 512 bytes. If a response exceeds 512 bytes and the client does not support Extension Mechanisms for DNS (EDNS0, RFC 6891), the server sets the Truncation Flag (TC) in the DNS header, forcing the client to fall back to TCP.
• TCP Port 53: Used whenever message payloads exceed UDP MTU limits, during EDNS0 buffer exhaustion, and exclusively for DNS Zone Transfers (AXFR/IXFR) to ensure reliable, stream-oriented transport of entire zone databases.
• Encrypted DNS Transports: Modern architectures also deploy DNS over TLS (DoT) on TCP port 853 and DNS over HTTPS (DoH) on TCP port 443 to prevent eavesdropping and MITM manipulation between clients and recursive resolvers.

---

2. Core DNS Record Types Tested on the CPSA

Penetration testers must possess an exhaustive understanding of DNS resource record types, their syntax, and their specific security implications:

+-------------+---------------------------------------+-------------------------------------+
| Record Type | Primary Purpose                       | Penetration Testing Relevance       |
+-------------+---------------------------------------+-------------------------------------+
| A           | Maps FQDN to IPv4 address             | Identifies public perimeter targets |
| AAAA        | Maps FQDN to 128-bit IPv6 address     | Uncovers unmonitored dual-stack paths|
| MX          | Designates Mail Exchanger & priority  | Identifies email filtering gateways |
| NS          | Authoritative nameserver delegation   | Targets for zone transfer attempts  |
| PTR         | Maps IP address to FQDN (Reverse DNS) | Enables sweeps of full IP subnets   |
| SOA         | Master zone authority & timing timers | Extracts admin email, zone revision |
| TXT         | Arbitrary text / SPF / DKIM / DMARC   | Evaluates email spoofing & SaaS use |
| CNAME       | Hostname alias to Canonical Name      | Identifies dangling subdomain takeovers|
| HINFO       | Declares host CPU and OS strings      | Free OS/hardware fingerprint if set |
| SRV         | Locates services (Port, Target, Prio) | Maps Active Directory controllers  |
| CAA         | Restricts authorized TLS CAs          | Evaluates certificate issuance policy|
+-------------+---------------------------------------+-------------------------------------+

In-Depth Record Syntax & Security Analysis

1. A & AAAA Records

Standard forward mapping records. A returns a 32-bit IPv4 address, while AAAA returns a 128-bit IPv6 address. Discovering AAAA records is critical: security teams often harden IPv4 perimeter firewalls but leave parallel IPv6 interfaces exposed or unmonitored.

2. MX (Mail Exchanger) Records

Specifies the mail servers responsible for accepting incoming email on behalf of the domain, accompanied by a numeric Preference / Priority value:

example.com.   3600  IN  MX  10  mail-primary.example.com.
example.com.   3600  IN  MX  20  mail-backup.example.com.

• Preference Rule: Lower numbers indicate higher priority. Sending mail servers attempt delivery to the lowest number first (10), falling back to secondary servers (20) only if the primary fails to respond.
• Testing Implication: Backup mail servers (MX 20) frequently run older software, lack advanced anti-spam/anti-malware defenses (like Mimecast or Proofpoint), or have weaker authentication controls than primary gateways.

3. NS (Name Server) Records

Delegates a DNS zone to authoritative nameservers. During reconnaissance, every authoritative nameserver identified in NS records must be queried individually for zone transfer vulnerabilities and version banners (dig version.bind chaos txt @ns1.example.com).

4. PTR (Pointer) Records & Reverse DNS Lookups

Maps an IP address back to its FQDN. Reverse DNS operates in specialized pseudo-domains:

• IPv4: Uses the in-addr.arpa domain. The IPv4 octets are reversed and appended to .in-addr.arpa. For example, the reverse lookup domain for 198.51.100.25 is 25.100.51.198.in-addr.arpa.
• IPv6: Uses the ip6.arpa domain. Each hexadecimal nibble is reversed and separated by dots. For example, 2001:db8::1 becomes 1.0.0.0.0...8.b.d.0.1.0.0.2.ip6.arpa.
• Testing Implication: Penetration testers execute automated reverse lookups across an entire client CIDR range (198.51.100.0/24) to discover unindexed servers, database nodes, VPN endpoints, and staging systems.

5. SOA (Start of Authority) Records

Every valid zone file must begin with exactly one SOA record, providing essential zone management parameters:

example.com.  IN  SOA  ns1.example.com. hostmaster.example.com. (
                        2026091401 ; Serial Number
                        7200       ; Refresh (2 hours)
                        3600       ; Retry (1 hour)
                        1209600    ; Expire (2 weeks)
                        300        ; Minimum / Negative Caching TTL (5 minutes)
)

• Primary Master (MNAME): ns1.example.com. specifies the single primary nameserver where zone updates are authored.
• Responsible Person Email (RNAME): hostmaster.example.com. specifies the administrator's email. The first unescaped dot is converted to an @ symbol (hostmaster@example.com). If the local part contains a dot, it is escaped (e.g., john\.smith.example.com becomes john.smith@example.com), disclosing administrator usernames.
• Serial Number: A 32-bit integer incremented whenever the zone is modified. Industry best practice uses the date format YYYYMMDDNN (e.g., 2026091401 represents revision 01 on September 14, 2026). This reveals how actively the zone is maintained.
• Refresh: Interval secondary servers wait before polling the primary server's SOA to check for serial number increments.
• Retry: Interval a secondary server waits before retrying if the primary server fails to respond to a refresh query.
• Expire: Maximum time a secondary server will continue serving cached zone data if the primary remains unreachable. When reached, the secondary purges the zone.
• Minimum TTL (RFC 2308): In modern DNS standards, this field defines the Negative Caching TTL—how long recursive resolvers cache a negative answer (NXDOMAIN - non-existent domain).

6. TXT (Text) Records: SPF, DKIM, and DMARC

TXT records carry arbitrary text, heavily utilized for email authentication and SaaS ownership verification:

• SPF (Sender Policy Framework, RFC 7208): Defines authorized sender IP addresses: v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all Qualifiers: -all (Hard Fail - reject unauthorized), ~all (Soft Fail - deliver to spam), ?all (Neutral), +all (Pass all - completely insecure).
• DKIM (DomainKeys Identified Mail): Stored under selector._domainkey.example.com, holding the public cryptographic key used to verify message signatures.
• DMARC (RFC 7489): Stored under _dmarc.example.com: v=DMARC1; p=reject; rua=mailto:dmarc@example.com Policy (p=): none (monitoring only, spoofing possible), quarantine (deliver to junk), reject (drop outright).
• Domain Verification Tokens: TXT records like google-site-verification=..., atlassian-domain-verification=..., and MS=ms12345678 explicitly enumerate which cloud SaaS platforms the target organization uses.

7. CNAME (Canonical Name) vs. DNAME & Subdomain Takeovers

• CNAME: Maps a specific alias hostname to its canonical target (e.g., blog.example.com -> target.github.io). Under RFC 2181, if a CNAME record exists for a node, no other data records may exist for that same name.
• DNAME (Delegation Name, RFC 6672): Maps an entire sub-tree of the DNS namespace to another domain.
• Subdomain Takeover Flaw: If a CNAME points to a third-party service (e.g., AWS S3, GitHub Pages, Heroku) and the client terminates the third-party subscription without deleting the CNAME record, an attacker can register the abandoned bucket/subdomain on that service and gain control of subdomain.example.com.

8. SRV (Service) Records (RFC 2782)

Specifies the location, port, and protocol of specific services. Crucial in Microsoft Windows Active Directory (AD) networks:

; Format: _Service._Proto.Name TTL Class SRV Priority Weight Port Target
_ldap._tcp.dc._msdcs.corp.local. 3600 IN SRV 0 100 389 dc01.corp.local.
_kerberos._tcp.corp.local.       3600 IN SRV 0 100 88  dc01.corp.local.

• Fields: Priority (lower is prioritized), Weight (load balancing between equal priorities), Port (TCP/UDP port number), Target (canonical host providing the service).
• Testing Implication: External exposure of SRV records leaks internal Active Directory domain controller hostnames, Kerberos servers (port 88), Global Catalog servers (port 3268), and SIP VoIP gateways without requiring active port scanning.

9. CAA (Certification Authority Authorization, RFC 6844)

Restricts which Certificate Authorities (CAs) are authorized to issue SSL/TLS certificates for the domain (e.g., 0 issue "letsencrypt.org"). Protects against rogue certificate issuance.

---

HINFO (Host Information) Records

HINFO records (RFC 1035) publish two free-text strings describing a host's CPU type and operating system, for example mail01.example.com. IN HINFO "Intel-Xeon" "RHEL-8". The record type predates modern security practice: where it is populated it hands an attacker an authoritative hardware and OS fingerprint with no probing at all, so no active OS fingerprinting or banner grab is needed to choose an exploit. RFC 8482 now lets resolvers return a synthetic HINFO value of "RFC8482" in response to ANY queries instead of dumping the whole record set, so a modern HINFO reply is more often a refusal to answer ANY than a genuine host description. Treat any real HINFO string found during enumeration as a finding in its own right and recommend its removal.

3. DNS Zone Transfers (AXFR & IXFR)

A DNS Zone Transfer is the mechanism defined in RFC 5936 allowing secondary (slave) nameservers to replicate the complete master zone database from a primary nameserver over TCP port 53.

+-------------------------------------------------------------------------+
|                       AUTHORITATIVE MASTER NAMESERVER                    |
|                              (ns1.target.com)                           |
+-------------------------------------------------------------------------+
                                     ▲
        1. Client initiates TCP connection to Port 53
        2. Client sends AXFR request: "target.com"
                                     │
        3. Server checks Access Control List (ACL)
           [ MISCONFIGURATION: ACL allows ANY (0.0.0.0/0) ]
                                     │
        4. Full Zone Database Transmitted (TCP Stream)
                                     ▼
+-------------------------------------------------------------------------+
|                       UNAUTHORIZED PENETRATION TESTER                   |
|       Discovers: dev-portal, internal-db, vpn-gw, 10.0.0.0/8 ranges      |
+-------------------------------------------------------------------------+

AXFR vs. IXFR

• AXFR (Asynchronous Full Transfer): Replicates the entire zone file from Start of Authority to the final record. If a zone contains 50,000 records, all 50,000 are transmitted.
• IXFR (Incremental Zone Transfer, RFC 1995): Transfers only records modified since a specific SOA serial number, saving network bandwidth.

The Security Impact of AXFR Misconfiguration

Nameservers should restrict zone transfers strictly to trusted secondary server IP addresses using Access Control Lists (ACLs) or cryptographic Transaction Signatures (TSIG, RFC 2845). When an administrator fails to configure ACLs, the nameserver defaults to permitting zone transfers from any querying IP address.

Impact of an Open AXFR:

1. Complete exposure of the internal and external attack surface.
2. Discovery of hidden staging servers (staging-api.target.com), development instances, internal wikis, and administrative panels.
3. Exposure of internal RFC 1918 network IP layouts and server naming conventions.
4. Complete elimination of the need for noisy brute-force subdomain scanning.

---

4. DNS Enumeration Toolkits & Methodologies

Penetration testers employ both command-line utilities and automated discovery pipelines to enumerate DNS infrastructure.

1. dig (Domain Information Grok)

The industry-standard diagnostic tool for querying DNS nameservers:

# 1. Attempting an AXFR zone transfer against a specific nameserver
dig axfr @ns1.target.com target.com

# 2. Querying for all available records with clean, multiline output
dig +nocmd target.com ANY +multiline +noall +answer

# 3. Performing a reverse lookup for an IPv4 address
dig -x 198.51.100.25

# 4. Tracing the resolution path iteratively from the root servers down
dig +trace target.com

# 5. Querying nameserver version banner via the CHAOS class
dig @ns1.target.com version.bind chaos txt

2. host

A simple, fast utility for forward and reverse lookups:

# Perform a zone transfer using host
host -l -a target.com ns1.target.com

# Query specific record types
host -t MX target.com
host -t SOA target.com

3. nslookup

A cross-platform utility available on both Linux and Windows. Useful for interactive debugging:

C:\> nslookup
> server ns1.target.com
> set type=any
> target.com
> ls -d target.com    (Executes an AXFR zone transfer in Windows nslookup)

4. Subdomain Brute-Forcing & Permutation Generation

When AXFR is blocked, testers deploy dictionary-based brute forcing:

• Wordlist Iteration: Tools such as gobuster dns, ffuf, or massdns pair comprehensive wordlists (e.g., SecLists subdomains-top1million.txt) with multi-threaded resolvers to query millions of potential FQDNs (dev.target.com, vpn.target.com).
• Permutation / Mutation Generators: Tools like altdns take discovered subdomains and generate permutations using common development prefixes and suffixes (api-staging, portal-dev, auth-v2.target.com).

5. Passive Certificate Transparency (CT) Log Analysis

Certificate Transparency (RFC 6962) mandates that Certificate Authorities publicly log all issued SSL/TLS certificates into append-only cryptographic ledgers. Querying public aggregators like crt.sh reveals subdomains passively without sending a single DNS query to the target's nameservers:

# Query crt.sh API via curl and parse unique discovered subdomains using jq
curl -s "https://crt.sh/?q=%25.target.com&output=json" | jq -r '.[].name_value' | sort -u