DNS Internals & Resolution
DNS is the network's phone book, and like a phone book nobody thinks about it until it stops working. Every browser tab, every API call, every piece of malware phoning home starts with a name that has to be turned into an address. That translation happens dozens of times a minute on any given host, almost always unnoticed and almost never inspected. Attackers know this. A protocol that runs constantly, gets waved through most firewalls, and is rarely logged in detail is exactly the kind of protocol worth abusing, which is why DNS shows up in reconnaissance, delivery, command and control, and exfiltration in roughly equal measure.
The DNS Namespace Hierarchy
The DNS namespace is a tree, not a flat list, and that structure is what lets a single global system manage billions of names without any one party owning all of them. At the top of the tree sits the root, represented by an empty, unwritten label. Every fully qualified domain name (FQDN) technically ends in a trailing dot that stands for that root, even though almost nobody types it: www.example.com. is the strict form of www.example.com.
Below the root come the top-level domains (TLDs): generic ones like .com, .org, and .net, country-code ones like .uk or .in, and newer sponsored or specialty TLDs like .bank or .cloud. Read a domain name right to left and you are walking down the tree: in mail.example.com, com is the TLD, example is the second-level domain registered by an organization, and mail is a subdomain (technically a host name within that domain, though the terms get used loosely).
- FQDN (Fully Qualified Domain Name): a complete name ending in the root's trailing dot, e.g.
www.example.com. - TLD (Top-Level Domain): the rightmost label, e.g.
.comor.uk. - Delegation: handing authority for a piece of the namespace down the tree, one level at a time.
- NS record: the record type that publishes which name servers are authoritative for a zone.
Delegation: Who Owns What
An organization that controls example.com can create as many subdomains as it wants underneath it, and delegate parts of that space to other teams or providers. None of that requires touching the TLD registry again. This delegation is the mechanism that makes DNS scale: authority for a piece of the namespace is handed down the tree, level by level.
Root Servers
Root servers sit at the very top of that delegation chain. There are 13 logical root server identities, lettered A through M, operated by a mix of universities, companies, and government-affiliated organizations. In practice each identity is served from hundreds of physical machines worldwide using anycast routing, so a query to a root server usually lands on a nearby instance rather than crossing an ocean.
Root servers do not know the IP address for any given domain. What they know is which servers are authoritative for each TLD, and that is the only answer they hand back.
TLD Servers
TLD servers are the next link. A TLD server for .com does not know the address for example.com either, but it knows which name servers are authoritative for example.com specifically, because that information was registered when the domain was purchased.
This is where NS records come into play: the registrar publishes NS records at the TLD level pointing to the domain's authoritative name servers, which is what makes the final hop of delegation possible. Get those NS records wrong and the domain becomes unreachable, regardless of how correctly everything below it is configured.
Authoritative Name Servers
Authoritative name servers for the domain itself sit at the bottom of the delegation chain and hold the actual answers: the A record for the web server, the MX record for mail, the TXT records for verification and policy. This is the only tier in the whole hierarchy that has ground truth.
Everything above it, root and TLD, exists purely to point a resolver toward the next server down, one level at a time, until it reaches the zone that actually knows the answer.
The Full DNS Resolution Path
Walk through what happens when a laptop looks up www.h3ad-sec.com for the first time with an empty cache. This is the reference sequence, every step happens in this fixed order, even though caching means most real-world lookups skip straight to the end.
- Application to stub resolver. The application asks the operating system's stub resolver, a lightweight client with no real intelligence of its own, to resolve the name.
- Stub resolver to recursive resolver. The stub resolver does not talk to the internet directly. It forwards the query to a recursive resolver, which might be the organization's internal DNS server, an ISP resolver, or a public service like 1.1.1.1 or 8.8.8.8. From here on, the recursive resolver does all the real work on the client's behalf.
- Cache check. The recursive resolver first checks its own cache. On this first-time lookup there's nothing there, so it starts at the top.
- Recursive resolver to root server. It asks a root server where to find answers for
.com. The root server does not know the address forwww.h3ad-sec.com, but it returns a referral: the addresses of the TLD servers responsible for.com. - Recursive resolver to TLD server. The recursive resolver queries one of those TLD servers, asking about
h3ad-sec.com. The TLD server also does not have the final answer, but it returns the NS records forh3ad-sec.com, pointing to the domain's authoritative name servers. - Recursive resolver to authoritative server. The recursive resolver queries one of those authoritative servers directly, asking for the A record of
www.h3ad-sec.com. This time it gets a real answer: an IP address, along with a Time To Live (TTL) value telling the resolver how long that answer is valid, commonly somewhere between five minutes and a day depending on how the zone is configured. - Answer returned to the client. The recursive resolver caches the answer for that TTL, hands the IP address back to the stub resolver, and the stub resolver hands it to the application, which finally opens a connection.
Every subsequent lookup for the same name, from any client using that same recursive resolver, is served straight from cache until the TTL expires, with no round trip to root, TLD, or authoritative servers at all. This is why a full walk down the hierarchy, sometimes called an iterative or referral chain, is the exception rather than the rule in day-to-day traffic.
Most queries an analyst sees in logs are cache hits, and the ones that trigger a fresh recursive lookup are disproportionately interesting: first contact with a new domain, or a domain deliberately configured with a very short TTL.
Record Types That Matter for Security Work
A DNS zone is a collection of resource records, and while there are dozens of record types defined, a small set of them account for almost everything an analyst will encounter during investigations. Knowing what each type is for, and what it reveals when it shows up somewhere unexpected, is basic DNS literacy for anyone doing detection or IR work.
Address & Alias Records
A and AAAA records map a name to an IPv4 or IPv6 address respectively, and are the most common record an analyst pivots on. Given a suspicious domain, resolving its A record is usually the first step toward blocklisting or further infrastructure analysis.
CNAME records alias one name to another rather than to an address. They're frequently abused in phishing infrastructure, where a lookalike domain is CNAMEd to infrastructure hosted somewhere else entirely, letting the attacker rotate backend hosting without touching the domain the victim sees.
Mail & Delegation Records
MX records specify which mail servers accept email for a domain and are a standard early step in email-based investigations: confirming where a domain's mail actually routes helps validate or debunk a spoofed sender.
NS records, already covered in the hierarchy discussion, matter for a different reason during investigations: a domain's NS records reveal which DNS provider or hosting infrastructure is behind it. That's often a stronger pivot point than the IP address itself, since attackers reuse providers and patterns across campaigns more consistently than they reuse infrastructure.
Reverse & Text Records
PTR records do reverse lookups, mapping an IP address back to a name, and are stored in the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones. They're useful for sanity-checking whether an IP has a legitimate-looking hostname attached to it, though their absence is common and not itself a red flag, since PTR records are optional and many legitimate hosts do not have one configured.
TXT records are free-form text fields originally meant for arbitrary notes, and have since become the backbone of email authentication and domain verification: SPF records list which servers are authorized to send mail for a domain, DKIM public keys live in TXT records under a selector subdomain, and DMARC policy is published as a TXT record at _dmarc.domain.com. TXT records also get abused for DNS tunneling, covered later in this chapter, because they can carry more arbitrary data than most other record types.
| Record Type | Purpose | Security Relevance |
|---|---|---|
| A | Maps a name to an IPv4 address | Primary pivot point for blocklisting and infrastructure lookups |
| AAAA | Maps a name to an IPv6 address | Often under-monitored; IPv6-only C2 can evade IPv4-focused tooling |
| CNAME | Aliases one name to another | Used to front phishing infrastructure behind lookalike domains |
| MX | Specifies mail servers for a domain | Validates or debunks spoofed sender infrastructure claims |
| NS | Delegates authority to name servers | Reveals hosting/DNS provider; a stronger campaign pivot than IPs |
| PTR | Reverse-maps an IP to a name | Sanity-checks IP legitimacy; absence is common and not conclusive |
| TXT | Free-form text data | Hosts SPF/DKIM/DMARC policy; also abused for DNS tunneling |
Why Plain DNS Is Unauthenticated and Unencrypted
Classic DNS, as designed in the early 1980s, has no built-in authentication and no built-in encryption. A resolver has no cryptographic way to verify that a response actually came from the authoritative server it asked, and no way to tell whether the response was altered in transit. Queries and answers travel over plain UDP on port 53 by default, in the clear, readable by anything positioned on the network path.
This was a reasonable tradeoff for a protocol built for speed on a much smaller, more trusted internet. It is a serious liability on today's internet.
Cache Poisoning and DNSSEC
The lack of authentication enables cache poisoning and spoofing attacks: an attacker who can guess or intercept a query in time can inject a forged response before the legitimate authoritative answer arrives, causing the resolver to cache a malicious IP address for a legitimate name.
DNSSEC (DNS Security Extensions) was built to close this specific gap. It adds a chain of cryptographic signatures: RRSIG records signing the actual data and DNSKEY records publishing the public keys, anchored by DS records at each parent zone that vouch for the child zone's key. A resolver that validates DNSSEC can confirm a response genuinely came from the authoritative source and was not tampered with in transit.
What DNSSEC Doesn't Cover
It is worth being precise about what DNSSEC does and does not do. It provides origin authentication and data integrity. It does not provide confidentiality.
A DNSSEC-signed query is still sent in plaintext; anyone monitoring the wire can still see exactly which domain was requested, they just cannot forge the answer undetected. Confidentiality is a separate problem, addressed by a different set of protocols.
Encrypting the Wire: DoH vs DoT
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the query and response in transit, wrapping DNS traffic inside TLS so that a network observer can no longer read which domain is being requested. DoT runs on its own dedicated port, 853, which makes it straightforward to identify and, if a network operator chooses, block at the perimeter.
DoH is deliberately harder to distinguish: it rides over standard HTTPS on port 443, often to the same infrastructure that serves ordinary web traffic. That means it blends into traffic that cannot be blocked wholesale without breaking the internet for that host.
| Mechanism | Authentication / Integrity | Confidentiality | Monitoring Impact |
|---|---|---|---|
| Plain DNS (port 53) | None | None | Fully visible; standard enterprise monitoring point |
| DNSSEC | Yes, via RRSIG/DNSKEY/DS chain | None, still plaintext | Still fully visible on the wire |
| DoT (port 853) | Via underlying TLS session | Yes | Easy to identify and block by dedicated port |
| DoH (port 443) | Via underlying TLS session | Yes | Blends into HTTPS traffic; hard to block selectively |
How Attackers Abuse DNS
DNS is abused in three structurally distinct ways: as a covert channel, as a resilience mechanism for C2 domains, and as a way to keep hosting infrastructure a moving target. Each technique below exploits a different property of how DNS is designed to work.
DNS Tunneling
DNS tunneling encodes arbitrary data inside DNS queries and responses, using the protocol as a covert channel rather than for name resolution. A compromised host encodes stolen data into a long subdomain label, for example c2guhq83jd.tunnel.attacker-domain.com, and queries it.
The attacker's authoritative name server for attacker-domain.com receives that query, decodes the payload from the subdomain, and can respond with instructions encoded in a TXT or NULL record. Tools like iodine and dnscat2 automate this into a full two-way tunnel capable of carrying C2 traffic or exfiltrating files, entirely over what looks, at a glance, like ordinary DNS resolution. It works because DNS is almost universally permitted outbound through firewalls, even in networks that lock down nearly everything else.
Domain Generation Algorithms (DGAs)
Domain generation algorithms solve a different problem for attackers: resilience against domain blocklisting and takedown. Rather than hardcoding a single C2 domain that defenders can identify and block, malware runs an algorithm, often seeded by the current date, to generate a large list of pseudo-random candidate domain names each day.
The malware tries resolving each candidate in sequence; the attacker only needs to register one of them ahead of time for that day's C2 channel to come alive. Families like Conficker popularized this technique, and it remains common because it defeats static blocklists: defenders would need to predict and pre-register or block thousands of unregistered candidate domains to fully neutralize it.
Fast-Flux DNS
Fast-flux DNS rotates the infrastructure behind a domain name rapidly to resist takedown and blocklisting at the IP layer. In single-flux, the A record for a malicious domain is set with a very short TTL and returns a different IP address, often from a large pool of compromised hosts acting as reverse proxies, every few minutes.
In double-flux, the attacker rotates the authoritative NS records too, so even the name servers answering for the domain keep changing. The effect is the same either way: by the time a defender identifies and blocks one IP or name server, the domain has already moved on to another, keeping the actual backend C2 infrastructure hidden behind a constantly shifting front layer.
DNS as High-Value Telemetry
DNS query logs are one of the best trades in a SOC's data budget: cheap to collect relative to full packet capture, present on essentially every network segment, and touched by nearly every stage of an intrusion. Reconnaissance often starts with DNS enumeration, delivery frequently resolves a malicious domain before a payload lands, C2 beacons resolve their callback domain on a schedule, and exfiltration over DNS tunneling is, by definition, entirely DNS traffic. A single well-instrumented DNS log source gives visibility into behavior that would otherwise require correlating several other data sources.
- High entropy subdomains. Legitimate subdomains tend to be short, readable, and purposeful:
mail,api,vpn. A subdomain that looks likex7f2kq9zpqm3n.evil-domain.comis a strong indicator of either DGA-generated C2 or DNS tunneling encoding data into the label, and entropy scoring over subdomain strings is a standard, relatively cheap detection technique. - NXDOMAIN spikes. When a DGA cycles through hundreds of candidate domains looking for the one the attacker actually registered, nearly all of those lookups fail with NXDOMAIN (no such domain). A single host generating an unusual burst of NXDOMAIN responses, especially for machine-looking names, is a textbook DGA fingerprint that is much harder for malware to disguise than the eventual successful C2 connection itself.
- Newly registered domains (NRDs). NRDs are disproportionately represented in phishing and C2 infrastructure, simply because attackers frequently register infrastructure shortly before using it rather than maintaining aged domains. A domain queried by an internal host within days or hours of its registration date is worth extra scrutiny even if nothing else about it looks obviously malicious yet, since reputation-based blocklists have not had time to catch up with brand-new registrations.
- Unusual query volume from a single host. A workstation that normally issues a few hundred DNS queries a day suddenly issuing tens of thousands to the same domain is either broken software or a tunneling channel moving data out in small, steady chunks.
None of these four signals is conclusive on its own, and each produces false positives in isolation, but layered together and tuned against a baseline of normal traffic, they turn a cheap log source into one of the more reliable early-warning systems available to a SOC.
Key Takeaways
- DNS is a hierarchical tree: root, then TLDs, then second-level domains, then subdomains, with authority delegated one level at a time via NS records.
- A full resolution walks stub resolver to recursive resolver to root to TLD to authoritative server, but caching and TTLs mean most real-world queries are served from cache without that full chain running.
- A, AAAA, CNAME, MX, NS, PTR, and TXT each carry distinct security relevance; TXT in particular hosts SPF, DKIM, and DMARC and is also abused for tunneling.
- Plain DNS has no authentication or encryption. DNSSEC adds origin authentication and integrity, not confidentiality; DoH and DoT add encryption but DoH's blend into HTTPS undermines enterprise-level monitoring.
- DNS tunneling, DGAs, and fast-flux are three distinct abuse techniques serving exfiltration/C2, blocklist evasion, and infrastructure resilience respectively.
- High entropy subdomains, NXDOMAIN spikes, newly registered domains, and unusual per-host query volume are four cheap, high-value signals to hunt in DNS logs.
Knowledge Check
Click an answer to reveal the explanation.
A recursive resolver queries a root server for www.example.com. What does the root server return?
A SOC analyst notices a single host generating thousands of NXDOMAIN responses for machine-generated-looking domain names within an hour. This is most consistent with:
An organization wants to preserve its ability to monitor and filter DNS traffic at the network perimeter while still adopting encrypted DNS internally. Which statement best reflects the relevant tradeoff?