DNS (Domain Name System) runs in the background of almost every network connection: it translates domain names into IP addresses, invisibly to the user. That's exactly why attackers actively abuse DNS — traffic on port 53 is rarely blocked by corporate firewalls, and DNS queries often fly under the radar of traditional security tools.
If you want to get up to speed on the basics, start with "What Is Secure DNS". This article covers specific DNS attack techniques and how to neutralize them.
How DNS Becomes an Attack Vector
Attackers exploit DNS along three main lines.
DNS tunneling is a technique for exfiltrating data and controlling compromised systems through DNS queries. Data gets encoded into subdomains, for example dGhpcyBpcyBhIHRlc3Q=.attacker.com. The queries pass through the corporate recursive resolver and reach the attacker's authoritative DNS server. Because they look like ordinary DNS lookups from the outside, the firewall lets them through without inspecting the content.
C2 over DNS (Command-and-Control) is a scheme where malware receives commands from a control server through DNS responses. Droppers and loaders use this channel for initialization: legitimate-looking DNS traffic masks the initial interaction with the attacker's infrastructure. You can't block this kind of connection at the IP or port level — the channel hides behind a standard protocol.
Phishing and typosquatting domains — attackers register domains that visually resemble trusted resources (paypa1.com, rnicrosoft.com) and route traffic to them through phishing links or DNS hijacking. The user clicks the link without noticing the swap and enters their credentials on the fake site.
How Secure DNS Works
Secure DNS is a protected DNS resolver that checks every query before returning an IP address. Here's how it works:
- The client system sends a DNS query to the Secure DNS resolver.
- The resolver checks the requested domain against several databases: categories, reputation, and threat indicators.
- If the domain falls into a blocked category or has a poor reputation, the resolver returns a stub response — NXDOMAIN or the IP address of a block page.
- If the domain is clean, the resolver returns the correct IP address and the connection proceeds normally.
The whole process requires no changes to the network architecture: you just need to point to the Secure DNS resolver's address in your DHCP settings or at the corporate resolver level. A host agent isn't required for baseline protection.
Category and Reputation Filtering
Secure DNS uses two main blocking mechanisms:
Category filtering — domains are grouped into topical categories: malware, phishing, undesirable content, anonymizers, botnets. The administrator selects which categories to block based on company policy. This is a coarse-grained but fast method: it relies on pre-labeled databases without having to analyze every single query.
Reputation filtering scores a domain based on a combination of signals: domain age, history of DNS record changes, similarity to known malicious domains, and presence in threat intelligence feeds. Domains with a poor reputation get blocked even if they don't fall into any predefined category.
The two methods complement each other. Category filtering covers known threats quickly and at scale. Reputation filtering catches new domains that haven't made it into predefined lists yet — including freshly registered domains that attackers use once and discard.
Protection Against Malware Domains and DGA
Modern malware uses domain generation algorithms (DGA) to automatically create thousands of random domains, so that just one of them ends up serving as the active C2 server. Static blocklists can't keep up: the attacker simply switches to the next domain in the queue.
Secure DNS applies several techniques for detecting DGA domains:
- Entropy analysis — DGA domains are statistically distinguishable from human-readable ones: higher character entropy, atypical letter combinations, and no meaningful word roots.
- Comparison against known family patterns — each malware family generates domains using its own algorithm; the pattern signatures are stored in threat intelligence databases.
- NXDOMAIN storms — infected hosts generate an abnormally high volume of queries to non-existent domains; this activity reveals DGA behavior and gets logged.
BI.ZONE Secure DNS cross-references queries against up-to-date threat intelligence feeds, including data on APT group infrastructure, and blocks malicious domains before the connection is established.
DNS Query Logging and Incident Investigation
DNS logs are a valuable data source during incident investigations. Each query record contains:
- a timestamp;
- the client's IP address;
- the requested domain and record type (A, AAAA, TXT, MX);
- the resolver's response — an IP address or the block type;
- the verification result — allowed, blocked, threat category.
DNS logs let you reconstruct the infection timeline: when the malicious domain was first contacted, which hosts made the queries, how many times, and at what intervals. This shortens investigation time and helps pinpoint the scope of an incident more accurately.
BI.ZONE Secure DNS exports logs to a SIEM via Syslog or API, feeding DNS telemetry into the overall security monitoring pipeline. Correlating DNS events with alerts from EDR and SIEM gives a fuller picture of an attack than either source could on its own.
Encrypted DNS and Channel Security
The DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) protocols encrypt DNS traffic between the client and the resolver — this protects against interception in transit and prevents response spoofing at intermediate nodes.
Secure DNS supports DoH and DoT: the client sends an encrypted query, the resolver decrypts it, checks the domain against its databases, and returns the response over the encrypted channel. Encrypting the channel doesn't cancel out content filtering — the domain check still happens either way.
Support for DoH and DoT also closes off a scenario where malware tries to bypass the corporate resolver by querying public DNS servers directly: network rules forcibly redirect encrypted traffic through Secure DNS.
Frequently Asked Questions
Does Secure DNS replace a firewall or IDS?
No. Secure DNS closes off one specific vector — DNS traffic. It doesn't inspect HTTP payloads, doesn't filter connections by IP, and doesn't detect network-level anomalies. Firewalls, IDS, and Secure DNS work together, each covering a different layer.
Does query verification slow down internet speed?
Verification takes a few milliseconds — negligible for a corporate environment. Caching DNS responses further reduces the load: repeat queries to the same domains are handled without reaching out to the upstream resolver.
What happens if a domain you need gets blocked?
The administrator adds the domain to an allowlist through the management console. Logs show which domains were blocked over a given period, which makes it easier to audit the rules and reduce false positives.
How does Secure DNS handle subdomains?
A block extends to all subdomains of a blocked domain. The reputation system also evaluates each subdomain independently, so a freshly created subdomain on an otherwise clean parent domain will still go through entropy and DGA pattern checks.
Does Secure DNS help against attacks on the DNS infrastructure itself?
Partially. Secure DNS reduces the risk of DNS cache poisoning through DNSSEC validation. Attacks on authoritative DNS servers (amplification, NXDOMAIN flood) require additional measures at the DNS hosting and telecom operator level.
Hands-on Practice on BI.ZONE Cybersecurity Labs
The course on the BI.ZONE Cybersecurity Labs platform covers hands-on work with DNS protection in isolated environments. You'll work through real-world DNS attack scenarios: configuring filtering rules in BI.ZONE Secure DNS, analyzing logs from an infected host, and reconstructing an incident timeline from DNS telemetry.
The environments replicate corporate infrastructure with a configured DNS resolver: you can see how the system responds to DNS tunneling, queries to DGA domains, and attempted C2 communication — without any risk to real systems.