DNS Security: How DNS Attacks Work and How to Protect Your Domain

by

The Domain Name System (DNS) is the internet’s phone book — it translates domain names to IP addresses. DNS was designed for reliability, not security, and that fundamental weakness has been exploited in numerous creative ways. DNS hijacking, cache poisoning, DNS tunneling, and domain takeovers are all real, active threats. This guide covers the attacks and the defenses.

Common DNS-Based Attacks

DNS Cache Poisoning

# How it works:
# DNS resolvers cache answers to speed up future queries
# If a resolver's cache is "poisoned" with false records,
# ALL users on that resolver get redirected to the attacker's IP

# Classic Kaminsky Attack (2008):
# 1. Attacker floods the DNS resolver with fake responses
# 2. Each response claims a different Transaction ID
# 3. Eventually one matches — cache is poisoned
# 4. All queries for "bankofamerica.com" now go to attacker's server

# Defense: DNSSEC (see below)
# Defense: DNS resolvers should use random source ports (RFC 5452)
# Defense: 0x20 encoding (randomize case in queries)

DNS Hijacking / Domain Takeover

# DNS hijacking at registrar level:
# Attacker compromises domain registrar account
# Changes nameserver records to attacker-controlled DNS
# All traffic now routes through attacker

# Prevention:
# 1. Enable registrar lock on your domain:
# "Registry Lock" / "Domain Lock" prevents unauthorized transfers
# Most registrars offer this — enable it for all production domains

# 2. Enable 2FA/MFA on your domain registrar account
# GoDaddy, Namecheap, Cloudflare all support this

# 3. Monitor your DNS records:
# Free tool: dnschecker.org — check records from multiple locations
# Alert when DNS records change unexpectedly

# Subdomain takeover:
# 1. Company deploys app at: app.example.com -> SomeService
# 2. App is decommissioned, SomeService is cancelled
# 3. DNS CNAME still points to SomeService
# 4. Attacker registers SomeService account
# 5. Attacker now controls content at app.example.com!

# Check for takeover vulnerabilities:
pip install subzy
subzy run --targets subdomains.txt

DNS Tunneling (Data Exfiltration)

# DNS tunneling encodes data in DNS queries to bypass firewalls:
# Attacker controls a domain (tunnel.attacker.com)
# Runs authoritative DNS server that logs all queries
# Victim machine encodes data in DNS queries:
# "aGVsbG8gd29ybGQ.tunnel.attacker.com" = "hello world" (base64 in subdomain)

# Detection with Zeek:
cat /opt/zeek/logs/current/dns.log | zeek-cut query | 
awk 'length($0) > 50' | sort | uniq -c | sort -rn | head 20
# Unusually long DNS queries = tunneling indicator

# Detection in Wazuh:
# Rule 100300: DNS query with subdomain > 50 characters
# Alert on: high DNS query rate to single domain, high entropy subdomains

# Detection with Python:
import math
def entropy(s):
    from collections import Counter
    counts = Counter(s.lower())
    probs = [c/len(s) for c in counts.values()]
    return -sum(p * math.log2(p) for p in probs)

# High entropy subdomain = likely tunneling
# Normal: entropy < 3.5 for real hostnames
# Tunneling: entropy > 3.8

DNSSEC: Cryptographic DNS Integrity

# DNSSEC adds digital signatures to DNS records
# Resolvers verify signatures — prevents cache poisoning

# Check if a domain has DNSSEC:
dig +dnssec example.com
# Look for: RRSIG records in the answer section

# Or use:
delv example.com A  # Performs DNSSEC validation

# Enable DNSSEC on your domain (Cloudflare example):
# Cloudflare DNS > DNS > Settings > DNSSEC > Enable
# Copy DS record to your domain registrar's portal

# Verify DNSSEC is working:
dnsviz.net  # Visual DNSSEC validation tool

DNS over HTTPS (DoH) and DNS over TLS (DoT)

# Traditional DNS: plaintext UDP port 53
# Your ISP can see every domain you query
# Attackers on local network can intercept

# DNS over HTTPS (DoH): encrypts DNS in HTTPS
# DNS over TLS (DoT): encrypts DNS in TLS on port 853

# Configure DoH in Firefox:
# Settings > General > Network Settings > Enable DNS over HTTPS
# Provider: Cloudflare (default) or NextDNS

# Configure DoT on Linux (systemd-resolved):
sudo nano /etc/systemd/resolved.conf
# [Resolve]
# DNS=9.9.9.9#dns.quad9.net
# DNSOverTLS=yes
# DNSSEC=yes
sudo systemctl restart systemd-resolved

# Configure Quad9 DoT:
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
DNSOverTLS=yes

Monitoring DNS for Security

# Deploy Pi-hole as a DNS sinkhole:
# Blocks malicious domains for entire network

# Install Pi-hole:
curl -sSL https://install.pi-hole.net | bash

# Add security blocklists:
# StevenBlack: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
# URLhaus: https://urlhaus.abuse.ch/downloads/hostfile/

# Pi-hole + Unbound (recursive, privacy-respecting DNS):
# pihole-docs.com/guides/dns/unbound

# Monitor DNS logs for:
# - Queries to newly registered domains (< 30 days old)
# - High volume queries to single external domain
# - Queries to IP addresses instead of hostnames
# - DNS queries at unusual hours

DNS Security Checklist

  • ☑ DNSSEC enabled on all production domains
  • ☑ Registrar lock enabled
  • ☑ 2FA on domain registrar account
  • ☑ DNS change monitoring configured
  • ☑ Subdomain takeover checked with Subzy
  • ☑ Internal resolver uses DoT/DoH
  • ☑ DNS logging enabled for detection
  • ☑ Malicious domain blocking (Pi-hole or NextDNS)

Wrap Up

DNS is foundational infrastructure — a successful DNS attack can redirect your entire user base, intercept credentials, and exfiltrate data invisibly. Enable DNSSEC, protect your registrar account with MFA, monitor for subdomain takeovers, and deploy DNS-level malware blocking. These are high-impact, low-cost security improvements every organization can make.