What Is DNS Security?

DNS is involved in almost every network interaction and is monitored in relatively few organisations. That combination makes it both a highly effective control point and a reliable blind spot.

This entry covers the practice of securing and using DNS. The specific protocol extension providing record integrity is covered in DNSSEC.

Why attackers rely on it

Malware needs to find its command infrastructure, and it usually does so by name rather than address, because names are easier to change when infrastructure is taken down. That means the lookup happens before the connection — and blocking at the DNS layer stops the connection from being attempted at all.

DNS is also a viable exfiltration channel. Data encoded into subdomain queries reaches an attacker-controlled name server, and because DNS is almost universally permitted outbound, it frequently succeeds where other channels would be blocked. It is slow and it is reliable.

What monitoring surfaces

Queries to known malicious domains. Queries to newly registered domains, which are strongly associated with phishing infrastructure. Unusual query volume from a single host, which is the tunnelling signature. Long or high-entropy subdomains, which encoded data produces. And internal systems querying external resolvers directly, bypassing whatever controls you configured.

That last one is worth checking specifically. A device using a public resolver instead of the corporate one is outside every DNS policy and log you maintain.

Encrypted DNS complicates the picture

DNS over HTTPS and DNS over TLS protect queries from observation in transit, which is good for privacy and awkward for organisational visibility — particularly where a browser uses its own encrypted resolver, bypassing the operating system configuration entirely.

The workable approach is to provide an encrypted resolver you operate, so queries are protected in transit while remaining visible to you, and to block or detect direct use of external encrypted resolvers.

Internal DNS is an information source for attackers

Record names describe infrastructure. An attacker who can query internal DNS broadly — or transfer a zone — obtains a map of server names, functions and naming conventions without scanning anything.

Zone transfers should be restricted to authorised secondaries, which is well understood and still occasionally found open. Internal resolvers should not be reachable from outside, and internal names should not resolve publicly.

Split-horizon configurations — different answers for internal and external queries — are the standard approach, and the common failure is an internal name accidentally published in the external zone, where it advertises infrastructure indefinitely.

Resolver availability is worth planning as well. Because essentially every interaction begins with a lookup, a resolver outage presents as a total network failure to users. Redundancy and a tested failover path matter more than the single-service nature of DNS usually suggests.

A common mistake worth avoiding

Where to start

Check whether internal systems can reach external DNS resolvers directly. If they can, your DNS controls are optional from the endpoint's perspective, and malware will simply use its own resolver.

See blocking the quiet exfiltration path. GuardsArm delivers managed security.