DNS as a Security Tool and Target: Cache Poisoning, Hijacking, and DNSSEC

DNS can be both the target of attacks and the tool for defending against them

Most of the DNS security conversation focuses on DNSSEC — the cryptographic extension that authenticates DNS responses. But the practical security story of DNS is broader: attackers use DNS for exfiltration and command-and-control, DNS hijacking has compromised major websites, and monitoring your own DNS records is one of the most straightforward security posture checks available.

How DNS attacks actually happen

DNS cache poisoning

The classic attack. DNS resolvers cache responses to avoid re-querying for every lookup. If an attacker can inject a malicious response into that cache — making bank.example.com resolve to the attacker's IP — every user querying that resolver gets the malicious answer.

The mechanism: before DNS responses were protected, an attacker could send a flood of forged responses with matching transaction IDs, attempting to win the "race" against the legitimate response. The Dan Kaminsky attack (2008) revealed that the attack was much easier than previously understood, allowing cache poisoning in under 10 seconds on vulnerable resolvers.

Mitigation: DNSSEC, DNS over HTTPS (DoH), DNS over TLS (DoT), source port randomisation, 0x20 encoding (randomising case of query letters to introduce entropy).

DNS hijacking

Direct modification of DNS records — usually through compromising the domain registrar account or DNS provider's management interface. The attacker changes your A records, MX records, or nameservers to redirect traffic.

Notable incidents:

• Sea Turtle campaign (2019): state-sponsored attackers compromised dozens of organisations by hijacking their DNS providers, then intercepted email and VPN traffic
• DNSpionage (2018): similar campaign targeting Middle Eastern organisations
• Numerous ad hoc account compromises at registrars

Mitigation: strong authentication at registrar (hardware 2FA), registrar transfer lock, monitoring DNS records for unexpected changes.

DNS tunneling

Using DNS to exfiltrate data or communicate with command-and-control servers in environments where other protocols are blocked. The technique: encode data in DNS query hostnames (base64encodedpayload.attacker.com) and receive data in DNS responses.

DNS tunneling is slow (limited by DNS query size and frequency) but can bypass firewalls that block direct outbound connections while allowing DNS traffic. It's been used by malware including FrameworkPOS, DNXFP, and Cobalt Strike's DNS beacon.

Detection: unusually long subdomain labels, high DNS query volume for unusual domains, queries for domains that don't resolve.

DNS amplification attacks (DDoS)

DNS amplification exploits open recursive resolvers to amplify DDoS traffic. A small query (ANY record) produces a large response (potentially 50-70× amplification). Attackers spoof the victim's IP address as the source, causing DNS responses to flood the victim.

Open recursive resolvers — DNS servers that answer queries from any IP — are the attack enablers. Operators of recursive resolvers should restrict queries to their own users and networks.

DNSSEC: cryptographic authentication of DNS

DNSSEC adds digital signatures to DNS records, allowing resolvers to verify that a DNS response came from the authoritative server and hasn't been tampered with.

How it works:

1. The zone owner generates a key pair
2. DNS records are signed with the private key; the signature is published as RRSIG records
3. The public key is published as a DNSKEY record
4. A chain of trust extends from the root zone (signed by ICANN/IANA) down through TLDs to individual domains

What DNSSEC protects against: cache poisoning and record tampering.

What DNSSEC doesn't protect against: attacks on the authoritative nameserver itself, social engineering at the registrar, DDoS against nameservers.

DNSSEC adoption: approximately 20–30% of domains have DNSSEC enabled. Support for DNSSEC validation is widespread in resolvers (Cloudflare 1.1.1.1 and Google 8.8.8.8 both validate DNSSEC).

Monitoring your own DNS records as a security practice

Unexpected DNS changes are an early indicator of account compromise. Setting up monitoring on your critical DNS records provides rapid detection:

What to monitor:

• A records for your primary domains (website, mail server)
• MX records (changes could redirect incoming email)
• NS records (nameserver changes indicate registrar-level compromise)
• SPF, DKIM, DMARC TXT records (authentication changes)

Monitoring tools:

• MXToolbox DNS Monitor (free tier): email alerts for DNS changes
• DNSWatch: change detection and alerting
• Custom scripting: query records hourly via dig or nslookup, compare against stored baseline, alert on differences

A simple approach: a cron job that queries your critical records and emails you when any change is detected. This catches domain hijacking within hours.

Domain shadowing: the attack DNS monitoring catches

Domain shadowing involves compromising a domain registrar account and creating malicious subdomains rather than changing existing records. The main domain continues working normally; the attacker uses subdomains for phishing, malware distribution, or C2 infrastructure.

Why it works: the main domain has legitimate history and reputation. Search engines, security tools, and email filters give established domains more trust than newly registered domains.

DNS monitoring that covers the entire zone (not just specific records) would catch unexpected subdomain creation. Zone transfer access or monitoring via a DNS management API provides this visibility.

DNS over HTTPS and DNS over TLS

Traditional DNS queries are transmitted in cleartext. An ISP, network operator, or on-path attacker can see every domain you query.

DNS over HTTPS (DoH): DNS queries sent as HTTPS requests to a DoH resolver. Traffic is encrypted and indistinguishable from regular HTTPS traffic. Supported by Chrome, Firefox, and most modern operating systems.

DNS over TLS (DoT): DNS queries over an encrypted TLS connection. Uses port 853 (easily distinguishable from regular DNS on port 53, making it easier to block in some environments).

Both provide privacy against passive observation. Neither provides security if the DNS resolver itself is compromised.

How to use the DNS Lookup tool on sadiqbd.com

1. Enter domain and record type — query any record type
2. For security investigation: query NS records to confirm your nameservers match expectations; query A records to verify your IP; query TXT to confirm SPF/DKIM/DMARC are correct
3. For monitoring baseline: document your current critical records — this becomes the reference for change detection

Frequently Asked Questions

How do I know if my domain has been hijacked? Your website or email may behave strangely, or you might see it reported in security news. Proactively: query your NS and A records from multiple DNS resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, your ISP's resolver) and compare. Disagreement may indicate cache poisoning or ongoing propagation.

Should I enable DNSSEC for my domain? Yes, if your registrar and DNS provider support it and you're willing to manage the key rotation (or use automatic key management). DNSSEC prevents cache poisoning attacks against your domain's records.

Is the DNS Lookup tool free? Yes — completely free, no sign-up required.

DNS is critical infrastructure — and like all critical infrastructure, it's both a target and a tool for defenders. Monitoring your DNS records for unexpected changes and enabling DNSSEC are practical steps that require modest effort relative to the attack surface they close.

Try the DNS Lookup tool free at sadiqbd.com — query any DNS record type for any domain instantly, with results from authoritative nameservers.