DNS is the most useful log you're probably not reading.

Almost every connection a device makes starts with a question: what address belongs to this name? The device asks a resolver, and the resolver either answers from cache or works down the hierarchy — root, then the top-level domain's servers, then the domain's authoritative servers — until something authoritative answers.

Two roles matter here and get conflated constantly. A recursive resolver does the walking on your behalf. A forwarder does no walking at all; it hands the question to another resolver and relays the answer. Both look identical to a client, but they differ enormously in what they control, cache and can be held responsible for.

Answers carry a TTL — how long they may be cached. TTLs are why a change can take hours to be seen everywhere, and why the ability to purge a cache entry immediately is more valuable operationally than it sounds.

Command and control is the common case. Malware needs to reach an operator, and DNS is the one protocol that works nearly everywhere, so beaconing to an attacker-controlled domain is a well-worn path. Domain generation algorithms make it resilient: the malware computes thousands of candidate names, the operator registers one, and blocking a single domain achieves nothing.

Phishing depends on names too — a lookalike domain registered hours ago, sent in an email, clicked before any reputation exists. Newly registered domains are disproportionately malicious for exactly this reason, which is why filtering them as a category is a real control rather than a gimmick.

Then there is the infrastructure itself: cache poisoning to make a resolver believe a forged answer, hijacking a registrar account to repoint a whole domain, and abuse of resolvers as amplifiers in reflection attacks against third parties.

Classic DNS is plaintext UDP, readable and modifiable by anything on the path. DNS-over-TLS wraps it in TLS on a dedicated port, and DNS-over-HTTPS makes it indistinguishable from ordinary web traffic. Both are real privacy improvements against network observers.

They also cut both ways. Encryption between your resolver and its upstream protects your users. Encryption between a browser and a resolver you do not run removes your visibility and your control entirely — the browser simply stops asking you.

The distinction that matters is who terminates the encryption. Encrypted DNS to infrastructure you operate is a gain. Encrypted DNS around your infrastructure is a bypass, and it is the single largest practical weakness of any network-level DNS control.

Mitigations exist — blocking known DoH endpoints, disabling browser DoH by policy, blocking outbound port 853 and 53 to anything but your resolver — but every one of them is manual configuration you have to maintain.

Start by making resolution deliberate. Every client should use resolvers you chose, distributed by DHCP, with outbound DNS to anything else blocked at the firewall. Networks that skip this step find half their devices talking to hard-coded resolvers and never learn.

Then segment policy to match risk. A guest network, a production VLAN and a server subnet do not need identical rules, and the difference between them is often where the useful signal lives.

Log with intent. Query logs are personal data about what people looked at, so decide retention before you collect, and know what you would actually search for during an incident. Data you cannot search is cost without benefit.

Finally, plan for the resolver being down. A DNS control point is also a single point of failure, and a security layer that takes the network with it when it falls over will be removed by whoever is on call — correctly.