Overview
DNS is the protocol that turns names into addresses. Every other internet protocol depends on it, and almost every security incident touches it, whether the team is paying attention to it or not. C2 callbacks hide in DNS lookups. Data exfiltration rides on DNS queries. Cache poisoning rewrites where users end up. Botnet command and control uses DNS as both signaling channel and a way to keep infrastructure nimble (a domain that resolves to a different IP every few hours is hard to block at the IP layer).
For a security professional, DNS is two things: a protocol with specific failure modes you can detect, and an attack surface that is rarely instrumented as well as HTTP, TLS, or DNS-over-HTTPS traffic. The protocol is older than most of the security tooling that surrounds it. The most useful defensive moves are not complicated, but they require understanding what DNS is doing on the wire, not just treating it as a black-box resolver.
How it works
DNS is a hierarchical, distributed, eventually-consistent database. A client sends a query to a recursive resolver, the resolver walks the hierarchy from the root servers down to the authoritative server for the queried name, and the answer comes back with a TTL (time to live) that the resolver respects. Recursive resolvers cache the answer; the same client asking the same question a minute later hits the cache, not the authoritative server.
The query types matter. An A record maps a name to an IPv4 address; AAAA maps to IPv6; MX maps to mail servers; TXT records carry arbitrary text and are used for SPF, DKIM, DMARC, and domain verification. NS records identify the authoritative servers for a zone. The query path for a typical web request is: client asks the resolver, resolver asks root, root refers to TLD, TLD refers to authoritative, authoritative returns the A record, resolver caches it and returns it to the client. The whole conversation is normally UDP on port 53, with TCP fallback for large responses and for zone transfers.
Security-relevant details: DNS responses are not authenticated by default. A response that arrives at the resolver is trusted if it came from the IP the resolver expected, but the path is unencrypted. DNSSEC adds cryptographic signatures to the chain of trust, but deployment is partial and most resolvers do not validate. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the client-to-resolver leg, which closes the eavesdropping hole on the local network but does not authenticate the resolver-to-authoritative leg.
In practice
The default DNS infrastructure in most enterprises is a recursive resolver (often a corporate DNS server, sometimes a cloud-managed service like Route 53 Resolver, Azure DNS Private Resolver, or Google Cloud DNS) talking to upstream resolvers (typically the ISP's resolvers, or 8.8.8.8 / 1.1.1.1, or the same cloud provider's resolvers) talking to authoritative servers. The recursive resolver is where the operational leverage is: it sees every DNS query from every endpoint, it can be configured to log them, and it can be configured to apply policy.
Stub resolvers on endpoints do their own thing. Windows clients use the system resolver, which honors group policy and DHCP-supplied resolvers. Linux and macOS clients can be configured to use DoH or DoT to upstream resolvers, which means the corporate recursive resolver sees nothing from those clients unless they have been explicitly configured to use it. In a modern environment with mixed client types, the visibility gap is real and worth instrumenting.
A practical visibility stack for a security team: log every query at the recursive resolver, with the source IP, the queried name, the query type, the response code, and the resolved IP. Forward the logs to a SIEM. The query stream is high-volume, so summary indexes and sampled analysis are usually necessary for storage reasons, but the high-signal events (NXDOMAIN bursts, queries for known C2 domains, queries to authoritative servers the resolver has never talked to, queries for newly-registered domains) are worth alerting on.
Common mistakes
Treating DNS as a black box. The single biggest operational mistake is treating DNS as an opaque service. The protocol is plaintext, the queries are logged, and the failure modes are visible in the data. A team that does not have a DNS query log feed into its SIEM is leaving a lot of incident response capability on the floor.
Allowing direct egress to arbitrary DNS resolvers. If endpoints can reach 8.8.8.8 directly, they can leak DNS queries to a resolver the corporate network does not monitor. The fix is egress filtering that allows only the corporate resolver's IP, and DoH/DoT enforcement on the client to prevent fallback to plaintext DNS over the local network. Egress filtering is the operational floor; DoH enforcement is the belt-and-suspenders.
Trusting DNS for authentication of service identity. DNS is a name-to-address lookup, not an authentication protocol. A service that authenticates itself by presenting a hostname and expecting the client to look it up in DNS is vulnerable to cache poisoning, BGP hijacks, and any other DNS-path attack. The fix is to use TLS with certificate validation (the certificate pins the hostname to a cryptographic key, not to a DNS path) and to use DNSSEC only as a defense-in-depth check, not as the primary authentication.
Not monitoring for DNS tunneling. Data exfiltration over DNS works by encoding the payload in subdomain labels: a query for a-base64-encoded-string.exfil.example.com, where the authoritative server for example.com is attacker-controlled, exfiltrates the encoded payload in the query itself. Detection is by looking at unusually long subdomain labels, queries with high entropy in the subdomain, and unusually high query volumes to a single zone. Most enterprises do not detect this.
Defensive guidance
Egress-filter DNS at the network boundary. Allow only the corporate resolver's IP to be reachable from internal hosts. Block port 53 outbound from anything except the resolver. This forces all DNS through a single observation point.
Enable DoH or DoT on the recursive resolver side and on the endpoint side. DoH/DoT does not authenticate the resolver-to-authoritative leg, but it does prevent on-path observers from seeing queries, and it prevents attackers on the local network from injecting forged responses.
Run a DNS query log feed into your SIEM. High-value alerts: NXDOMAIN bursts (often a sign of C2 callback attempts where the C2 domain has been sinkholed or has expired), queries for known-bad or newly-registered domains (a strong C2 signal), and queries to authoritative servers that have never been seen before (a sign of newly-compromised infrastructure or a new C2 channel). The volume is high, so the right approach is summary indexes for the bulk of the data and selective alerting on the high-signal events.
Treat DNS as a path you cannot trust for authentication. Use TLS with certificate validation for service identity, not DNS. Use mTLS where the architecture supports it. Use DNSSEC as a defense-in-depth check, not as the primary trust signal. A defense that relies on DNS being correct is a defense that fails when DNS is poisoned.
If you operate your own authoritative DNS, deploy DNSSEC. The operational cost is real (key rollovers, algorithm choices, validation by parent zones) but the protection against cache poisoning and path attacks is worth it for any name that matters. If you do not deploy DNSSEC, do not advertise that you do, and do not treat unsigned answers from your nameservers as authenticated.