DNS Security in 2026: DNSSEC, DoH, DoT, and Preventing DNS Hijacking on Your Domain

In September 2025, a sophisticated DNS hijacking campaign redirected traffic for over 40 cryptocurrency exchanges by compromising the registrar accounts of their domain providers. The attackers did not need to breach a single server — they changed DNS records to point to their own infrastructure, obtained valid TLS certificates via automated domain validation, and intercepted user credentials for approximately 72 hours before detection. This attack would have been prevented by three measures: DNSSEC, CAA records, and registrar lock. Yet fewer than 12% of domains in the .com zone have DNSSEC enabled as of February 2026.

DNS is the foundation layer of the internet. Every HTTPS connection, every email delivery, every API call begins with a DNS lookup. If an attacker controls your DNS responses, they control everything — TLS certificates mean nothing because the attacker can obtain their own valid certificates for your domain through DNS-based domain validation. This guide covers every modern DNS security measure with exact configurations.

Understanding DNS Attack Vectors in 2026

There are five primary DNS attack vectors that organizations face today, each with different risk profiles and mitigations:

1. DNS Cache Poisoning (Kaminsky Attack variants): An attacker sends forged DNS responses to a recursive resolver, causing it to cache incorrect records. Modern resolvers use source port randomization and TXID randomization to make this harder, but it is not impossible — especially on resolvers behind NAT gateways that reduce source port entropy. DNSSEC eliminates this attack entirely.

2. Registrar Account Compromise: Attackers gain access to your domain registrar account (GoDaddy, Namecheap, Cloudflare) through credential stuffing, social engineering, or password reuse. Once inside, they change nameservers or A/AAAA records. Mitigation: registrar lock, 2FA with hardware keys, and registry lock (for high-value domains).

3. BGP Hijacking of DNS Providers: By announcing more-specific IP prefixes for DNS provider IP ranges, attackers can intercept DNS queries at the network level. This has been used against Amazon Route 53 and Google Cloud DNS in documented incidents. Mitigation: RPKI, monitoring, and using providers that implement BGP origin validation.

4. DNS Tunneling and Exfiltration: Malware encodes stolen data in DNS queries (e.g., c2VjcmV0ZGF0YQ.evil.com) to exfiltrate information through firewalls that allow DNS traffic. Mitigation: DNS query logging, anomaly detection, and restricting DNS to known resolvers.

5. Man-in-the-Middle on Unencrypted DNS: Traditional DNS (port 53) is unencrypted plaintext. Anyone on the network path — ISPs, coffee shop WiFi operators, compromised routers — can see and modify DNS queries. Mitigation: DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT).

DNSSEC: Signing Your Zone

DNSSEC adds cryptographic signatures to DNS records. When a resolver queries a DNSSEC-signed zone, it can verify that the response was not modified in transit and was actually published by the zone owner. DNSSEC does not encrypt DNS traffic — it provides authentication and integrity.

For Cloudflare-managed domains (the simplest approach):

# Cloudflare automatically manages DNSSEC when enabled.
# 1. Go to your domain in Cloudflare Dashboard
# 2. Navigate to DNS > Settings > DNSSEC
# 3. Click "Enable DNSSEC"
# 4. Cloudflare provides a DS record
# 5. Add the DS record at your registrar

# Verify DNSSEC is working:
dig +dnssec yourdomain.com A
# Look for the "ad" (Authenticated Data) flag in the response

# Or use an online tool:
# https://dnsviz.net/d/yourdomain.com/dnssec/

# Verify the DS record chain:
dig yourdomain.com DS +short
# Should return something like:
# 2371 13 2 abc123...def456...

For self-hosted BIND 9 zones:

# Generate Zone Signing Key (ZSK) and Key Signing Key (KSK):
cd /etc/bind/keys/

# KSK — signs the DNSKEY RRset, long-lived (2048-bit RSA or Ed25519):
dnssec-keygen -a ED25519 -f KSK yourdomain.com

# ZSK — signs all other records, rotated more frequently:
dnssec-keygen -a ED25519 yourdomain.com

# In named.conf, enable inline signing:
zone "yourdomain.com" {
    type primary;
    file "/etc/bind/zones/yourdomain.com.zone";
    inline-signing yes;
    auto-dnssec maintain;
    key-directory "/etc/bind/keys";
    dnssec-policy default;  # BIND 9.16+ automatic key management
};

# Reload BIND:
sudo rndc reload yourdomain.com
sudo rndc signing -list yourdomain.com

With BIND 9.16+, the dnssec-policy default directive handles key generation, signing, and rotation automatically. You still need to submit the DS record to your registrar, but key rollovers are handled by BIND without manual intervention.

CAA Records: Controlling Certificate Issuance

Certificate Authority Authorization (CAA) records specify which CAs are allowed to issue certificates for your domain. Without CAA records, any of the hundreds of public CAs can issue a certificate for your domain — all they need is to prove domain control, which DNS hijacking provides:

# Only allow Let's Encrypt and Cloudflare to issue certificates:
yourdomain.com.  IN  CAA  0  issue "letsencrypt.org"
yourdomain.com.  IN  CAA  0  issue "comodoca.com"      ; Cloudflare uses Sectigo/Comodo
yourdomain.com.  IN  CAA  0  issuewild "letsencrypt.org"
yourdomain.com.  IN  CAA  0  iodef "mailto:security@yourdomain.com"

# The iodef tag sends violation reports to your email.
# issuewild controls wildcard certificate issuance separately.

# Verify your CAA records:
dig yourdomain.com CAA +short

# Test what CAs can currently issue for your domain:
# https://caatest.co.uk/

CAA records are checked by all CAs since September 2017 (per CA/Browser Forum Ballot 187). If an attacker hijacks your DNS and tries to get a certificate from a CA not listed in your CAA records, the issuance will be denied. This is a simple, free defense that takes 2 minutes to configure and stops a significant class of attacks.

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

Traditional DNS queries are sent as unencrypted UDP packets on port 53. Any network observer can see which domains you are resolving, and any active attacker can modify responses. DoH (RFC 8484) wraps DNS queries in HTTPS on port 443, making them indistinguishable from regular web traffic. DoT (RFC 7858) uses TLS on port 853, which is easier to identify and block but simpler to implement.

Server-side DoT with CoreDNS:

# Corefile for CoreDNS with DoT:
tls://.:853 {
    tls /etc/coredns/cert.pem /etc/coredns/key.pem
    forward . tls://1.1.1.1 tls://1.0.0.1 {
        tls_servername cloudflare-dns.com
        health_check 30s
    }
    cache 3600
    log
    errors
}

# Standard DNS (for local network clients that don't support DoT):
.:53 {
    forward . tls://1.1.1.1 tls://1.0.0.1 {
        tls_servername cloudflare-dns.com
    }
    cache 3600
    log
}

Client-side configuration on Linux servers using systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
FallbackDNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes
Cache=yes
DNSStubListener=yes

# Restart resolved:
sudo systemctl restart systemd-resolved

# Verify DoT is active:
resolvectl status
# Should show "DNSOverTLS: yes" and "DNSSEC: yes"

# Test a query and verify it goes over TLS:
resolvectl query zeonedge.com --type=A
# The output will show "-- Information acquired via protocol DNS/TLS"

Monitoring DNS Changes with Real-Time Alerts

Even with all protective measures, you need to monitor your DNS records for unauthorized changes. A simple cron job can compare current DNS records against a known-good baseline and alert you immediately:

#!/bin/bash
# /opt/dns-monitor/check-dns.sh
DOMAIN="yourdomain.com"
BASELINE="/opt/dns-monitor/baseline.txt"
CURRENT="/opt/dns-monitor/current.txt"
WEBHOOK="https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK"

# Query current records:
dig +short $DOMAIN A > $CURRENT
dig +short $DOMAIN AAAA >> $CURRENT
dig +short $DOMAIN MX >> $CURRENT
dig +short $DOMAIN NS >> $CURRENT
dig +short $DOMAIN TXT >> $CURRENT

# Compare with baseline:
if ! diff -q $BASELINE $CURRENT >/dev/null 2>&1; then
    CHANGES=$(diff $BASELINE $CURRENT)
    curl -s -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"DNS ALERT: Records changed for $DOMAIN\\n$CHANGES\"}" \
        $WEBHOOK

    # Update baseline after alerting:
    cp $CURRENT $BASELINE
fi

# Crontab entry (check every 5 minutes):
# */5 * * * * /opt/dns-monitor/check-dns.sh

For production environments, use dedicated DNS monitoring services like DNSspy, Pingdom DNS monitoring, or build your own with Prometheus and the dns_exporter that queries your domain from multiple geographic locations and alerts on changes or resolution failures.

Registry Lock for High-Value Domains

Registry lock (also called "server transfer lock" or "registrar lock plus") is the strongest protection against unauthorized domain changes. Unlike standard registrar lock (which only prevents transfers), registry lock requires out-of-band verification — typically a phone call to a pre-registered number — before any DNS change can be made at the registry level. This means even if an attacker fully compromises your registrar account, they cannot change your nameservers.

Registry lock is available for .com, .net, .org, and most ccTLDs. The cost is typically $25-$300/year per domain, and the process varies by registrar. For any domain that is critical to your business revenue, registry lock is worth the cost and minor inconvenience of the manual change process.

DNS security is foundational — every other security measure you implement depends on DNS integrity. DNSSEC, CAA records, encrypted DNS, and monitoring together create a defense-in-depth approach that protects against the full range of DNS attacks. At ZeonEdge, we implement comprehensive DNS security as part of our infrastructure hardening service. Learn about our security services.