• Posted by: Eng. Donya Bino
• October 21, 2025

DNS Queries: What They Are and Why They Matter for Security

DNS is the internet’s address book. When your browser wants example.com it does not magically know where to go. It asks DNS. That “ask” is a DNS query and it is one of the most frequent network operations your systems perform. Because they are so common, DNS queries are useful for troubleshooting, performance tuning, and for spotting malicious activity.

Below I explain the basics, show useful examples you can run locally, and highlight security signals you should monitor.

The basics, how a DNS query flows

1. Client asks resolver. Your laptop asks the configured DNS resolver, often your ISP or a public resolver like 1.1.1.1.
2. Resolver checks cache. If it has the answer it returns immediately.
3. If not cached, resolver goes recursive. It asks root servers, then TLD servers, then the authoritative server for the domain.
4. Answer returns to the client and is usually cached for the TTL, time-to-live.

This process is fast, usually milliseconds, and most queries are answered from cache.

Common DNS query types you will see in logs

1. A: IPv4 address record, most common.
2. AAAA: IPv6 address record.
3. CNAME: Canonical name, used for aliases.
4. MX: Mail exchanger records for email routing.
5. TXT: Text records, used for SPF, DKIM, or arbitrary strings.
6. NS: Name server records for delegating subdomains.
7. PTR: Reverse DNS, IP to hostname.
8. SRV: Service records used by some applications such as SIP or XMPP.

Knowing these helps interpret what a client or server is trying to do.

Quick hands-on checks you can run locally

1. dig example.com A, asks for the A record.
2. dig @8.8.8.8 example.com ANY, ask Google’s resolver for any records.
3. nslookup -type=MX example.com, look up mail servers.
4. dig -x 8.8.8.8, reverse lookup for PTR.

These commands are great for troubleshooting DNS resolution problems and confirming configuration.

Real-world scenarios, why DNS queries matter

Performance
A misconfigured TTL or a slow authoritative server causes a lot of repeated queries, increasing latency for users. Caching at the resolver level reduces load, but if TTLs are too low your app may suffer unnecessary delays.

Configuration errors
Wrong CNAME chains or missing MX records can break email delivery. DNS checks should be part of deploy tests.

Security
DNS is often abused in attacks.

1. DNS tunneling and exfiltration: Attackers encode data into subdomain names of DNS queries, for example stolen-data.x4a.example-evil.com, to sneak data out where other channels are blocked.
2. Malware command and control: Compromised hosts may query domains that resolve dynamically, or use TXT records to receive commands.
3. Phishing and typosquatting: DNS records point victims to malicious hosts.

Because DNS is so chatty, it is a great source of detection signals if you monitor logs.

What to monitor in DNS logs, practical signals

1. Unusually high query volume from a host, which could indicate tunneling or a bot.
2. Many unique subdomains queried in a short time from one client, classic for exfiltration.
3. Requests for known-malicious domains, matched against threat intel feeds.
4. Large TXT records or unexpected record types returned to clients.
5. NXDOMAIN spikes, many not-found responses could mean scanning or misconfigured code generating random lookups.
6. Repeated reverse DNS anomalies, IPs with inconsistent or missing PTR records.

Collect logs centrally, from DNS server logs, forwarder logs, and network flow, and correlate with endpoint events for context.

Defenses and controls, real usable steps

1. Harden resolvers: Disable recursion on authoritative servers and enable recursion only on trusted resolvers.
2. Egress filtering: Block outbound DNS that bypasses corporate resolvers and force all DNS through controlled resolvers.
3. DNSSEC: Protect against spoofing and poisoning of responses.
4. Monitor and alert: Set thresholds for query volume, unique subdomains per host, and domain reputations.
5. Use DNS-based allowlists and denylists and integrate threat intelligence.
6. Consider DNS over TLS or HTTPS for privacy but monitor for DoH bypass; enterprise proxies should control allowed DoH providers.
7. Inspect TXT usage: Administrators often forget TXT can be abused, so log and alert on odd sizes or content.

Example detection rule ideas, starters

1. Alert if a single internal host makes more than 1000 unique subdomain queries in 10 minutes.
2. Alert on more than 50 NXDOMAIN responses from a single host in 5 minutes.
3. Alert on any query to domains on a high-confidence malicious domain list.

Tune thresholds to your environment to reduce false positives.

Treat DNS like a sensor. It is cheap to collect, rich in signals, and often overlooked. A quick win for many security teams is to log resolver queries, baseline normal behavior, and create a handful of alerts for the noisy, odd, or high-volume patterns described above. That three-hour investment pays off when you catch the first exfiltration or malware beacon.