How DNS Works

• Trace a full resolution from client cache to authoritative server
• Read and query A, AAAA, CNAME, MX and TXT records
• Explain DNS' role in attacks and how defenders use DNS logs

• Attackers abuse DNS for command-and-control, exfiltration and phishing; DNS logs reveal those patterns.
• Most incidents start with a lookup — 'which domains did this host query?' is one of the first triage questions.
• Email security (SPF/DKIM/DMARC) and certificate validation all hang off DNS records.
• Knowing consumption (recursion) vs delegation (authoritative) is where a lot of DNS debugging goes wrong.

You ask an operator (recursive resolver) for a business number. They check their notebook (cache), then call the business's regional office (authoritative nameserver) if needed, and hand you back the number. Your call then goes directly to the number.

• A client asks its configured recursive resolver for example.com's A record.
• The resolver checks its cache; a live answer respecting the TTL is returned without further queries.
• On a miss: resolver queries a root server, which points to the .com TLD servers.
• The resolver queries a .com server, which points to example.com's authoritative nameservers.
• The resolver queries the authoritative nameserver and receives the final answer, caches it, and returns it to the client.
• Record types: A/AAAA (IPv4/IPv6), CNAME (alias), MX (mail), TXT (arbitrary text, used for SPF/DKIM/DMARC and verification).

• A SOC sees an endpoint resolving a never-before-seen domain; SIEM correlation against a sinkhole/allowlist flags it as a C2 beacon before the connection fully establishes.
• An email security team checks that their domain's SPF/DKIM/DMARC records exist and are correct — missing TXT records mean forgery is trivially possible.
• A security engineer runs a local resolver on the lab network to sinkhole known-bad domains during malware analysis.

• Log DNS queries and responses for your zones — passive visibility into every host's name activity.
• Pin high-value records (SPF, MX, AXFR) and alert on changes you didn't make.
• Use TTL deliberately: short TTLs let you respond fast to takedowns; long TTLs reduce load.

• Confusing recursion (finding the answer) with authority (owning the zone) when debugging 'our DNS is broken'.
• Forgetting TTLs — a changed record can remain cached for hours, so 'we fixed it' still shows stale answers.
• Assuming a DNS query logged by an attacker means a successful connection; many probes are passive.

• dig +trace first when an answer looks wrong — it shows exactly where the chain breaks.
• Compare your resolver's answer against a public resolver (dig @1.1.1.1) to isolate cache vs authority issues.
• For 'domain resolves but site fails', check whether the A record differs from what the app expects (CNAME chasing, geo DNS).

• DNS is not encrypted by default; DNSSEC validates authenticity, and DoH/DoT protect privacy.
• Zone transfer requests (AXFR) must be locked down — an open AXFR hands an attacker your entire network map.
• DNS tunnels look like innocuous lookups; for example a slow trickle of TXT queries to one domain is a classic exfiltration signal.