DNSSEC (DNS Security Extensions) adds digital signatures to DNS records to verify their authenticity. When a DNS resolver receives a response, it verifies the cryptographic signature using the zone's public key — if the signature doesn't validate, the response is rejected. This prevents DNS cache poisoning attacks where an attacker injects false DNS records. DNSSEC creates a chain of trust from the DNS root down through TLDs to individual domain zones.

What is the difference between DNS over HTTPS and DNS over TLS?

Both DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries to prevent eavesdropping and tampering. DoH sends encrypted DNS queries inside standard HTTPS traffic on port 443 — this makes DNS traffic indistinguishable from regular web traffic, preventing interception but also making it harder for network administrators to monitor or filter DNS. DoT uses TLS on a dedicated port 853 — DNS traffic is encrypted but identifiable as DNS, allowing network administrators to monitor and apply policies while still protecting against eavesdropping.

What is DNS cache poisoning?

DNS cache poisoning (also called DNS spoofing) is an attack where an attacker injects malicious DNS records into a resolver's cache. When a victim queries the resolver for a domain, the resolver returns the attacker's fake IP address instead of the legitimate one, redirecting the victim to a malicious server — often a phishing site. Historically exploited using the Kaminsky attack (race condition in resolvers). DNSSEC cryptographic signatures and source port randomisation are the primary defences.

DNS Security — DNSSEC, DoH, DoT & Cache Poisoning

⚡ Quick Answer

DNSSEC = digital signatures on DNS records — verifies responses are authentic and haven't been tampered with (prevents cache poisoning). DoH (DNS over HTTPS) = encrypts DNS queries inside HTTPS on port 443 — hides DNS from ISPs/snoopers but harder for admins to filter. DoT (DNS over TLS) = encrypts DNS using TLS on port 853 — encrypted but identifiable as DNS traffic. Cache poisoning = attacker injects fake DNS records into a resolver. DNS hijacking = attacker changes where DNS queries are sent (via malware, rogue DHCP, or router compromise). DNSSEC prevents cache poisoning; DoH/DoT prevent eavesdropping and on-path manipulation.

Why DNS Security Matters

DNS is the internet's phone book — it translates human-readable domain names into IP addresses. Nearly every internet connection starts with a DNS query. Because traditional DNS operates in plaintext over UDP port 53, it is vulnerable to eavesdropping (anyone on the network can see which domains you're visiting), tampering (responses can be modified in transit), and poisoning (fake records can be injected into caches).

A successful DNS attack is particularly dangerous because it operates invisibly to the user. The user types a legitimate URL, the browser shows no obvious warning, and they are seamlessly delivered to an attacker-controlled server. Credentials, sensitive data, and malware delivery can all follow.

DNS Attack Types

DNS Cache Poisoning

Spoofing / Injection

Attacker sends forged DNS responses to a resolver before the legitimate response arrives, injecting a fake IP address into the resolver's cache. All subsequent clients querying that resolver get the malicious IP. Kaminsky attack (2008) demonstrated this at scale using transaction ID prediction. Defence: DNSSEC, randomise source ports and transaction IDs.

DNS Hijacking

Redirection

Attackers redirect DNS queries to a malicious DNS server that returns attacker-controlled IP addresses. Methods include: local hijacking (malware modifies /etc/hosts or DNS settings on the victim's device), router hijacking (attacker compromises home/office router to change its DNS settings), or rogue DHCP (attacker issues DHCP offers with a malicious DNS server IP).

DNS Amplification (DDoS)

DDoS / Reflection

Attacker sends small DNS queries with a spoofed source IP (victim's IP) to many open DNS resolvers. The resolvers send large DNS responses to the victim, amplifying traffic. A query of 60 bytes can generate a 3,000-byte response — 50x amplification. Defence: Response Rate Limiting (RRL) on DNS servers, BCP38 (ISP-level source address filtering).

DNS Tunnelling

Data Exfiltration

Attacker encodes data inside DNS queries and responses to exfiltrate data or establish a covert command-and-control channel — bypassing firewalls that allow DNS traffic. Encoded payloads appear in subdomains: exfiltrated-data.attacker.com. Detection: unusually long DNS query names, high query frequency, non-existent TLD patterns. Defence: DNS monitoring and anomaly detection.

DNSSEC — DNS Security Extensions

DNSSEC adds cryptographic digital signatures to DNS records so that resolvers can verify that responses are authentic and have not been tampered with in transit. It does not encrypt DNS queries — it only validates their authenticity. DNSSEC creates a chain of trust starting from the DNS root zone.

Zone Signing

The DNS zone owner generates a key pair. The private key signs each DNS resource record set (RRSET) creating a RRSIG (Resource Record Signature) record. The public key is published in the zone as a DNSKEY record.

Delegation Signer (DS) Record

A hash of the zone's DNSKEY (called a DS record) is published in the parent zone. For example, the .com zone holds a DS record for itstudyhub.com's DNSKEY. This links child zone trust to the parent zone's signature, building the chain of trust upward.

Root Zone Anchor

The chain terminates at the DNS root zone, which is signed by ICANN. Resolvers have the root zone's public key pre-configured as a trust anchor. This allows validation of the entire chain from root → TLD → domain → record.

Validation

A validating resolver retrieves the RRSIG and DNSKEY for each response and verifies the signature cryptographically. If validation fails, the resolver returns SERVFAIL — the client receives no answer. Poisoned or tampered records fail validation because the attacker cannot forge signatures without the zone's private key.

📌 Key DNSSEC Record Types

DNSKEY — the zone's public key, published in DNS so resolvers can verify signatures.

RRSIG — the digital signature for a resource record set. Included alongside every signed record in a DNSSEC response.

DS (Delegation Signer) — a hash of a child zone's DNSKEY, published in the parent zone. Creates the chain of trust between zones.

NSEC / NSEC3 — proves that a DNS name does NOT exist (authenticated denial of existence). Prevents attackers from fabricating negative responses.

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

While DNSSEC validates the authenticity of DNS responses, it does not encrypt them. Traditional DNS over UDP/53 is visible to anyone on the network — ISPs, network administrators, and on-path attackers can see every domain you query. DoH and DoT solve this by encrypting the DNS query and response.

🔒

DNS over HTTPS (DoH)

DNS queries are sent as HTTPS POST or GET requests inside standard TLS on port 443. DNS traffic is completely indistinguishable from regular HTTPS web traffic — ISPs, firewalls, and even corporate content filters cannot see or block DNS queries without blocking all HTTPS. Security benefit: strong encryption and confidentiality. Enterprise concern: bypasses DNS-based security controls and monitoring — some organisations block DoH to maintain visibility.

Port 443HTTPSHidden from ISP

🛡️

DNS over TLS (DoT)

DNS queries are sent over a dedicated TLS connection on port 853. Queries are encrypted but the traffic is identifiable as DNS — firewalls can allow or block port 853 specifically. Preferred in enterprise environments where encrypted DNS is desired but DNS visibility and policy enforcement must be maintained. RFC 7858. Commonly used by mobile operating systems and privacy-conscious resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8).

Port 853TLS encryptedIdentifiable as DNS

🎯 Exam Tip — DoH vs DoT Port Numbers

DoH = port 443 (HTTPS port — blends with web traffic). DoT = port 853 (unique DNS-over-TLS port — visible and blockable).

The exam may present a scenario where a company wants encrypted DNS but needs to maintain the ability to monitor and filter DNS traffic. The answer is DoT (port 853) — not DoH, because DoH blends into HTTPS and cannot be separately filtered.

Split-Horizon DNS

Split-horizon DNS (also called split-brain DNS or split-view DNS) uses different DNS answers for the same domain depending on who is asking. Internal users querying from inside the corporate network receive internal IP addresses (or hostnames of internal servers). External users querying from the internet receive public IP addresses.

📌 Split-Horizon DNS Use Case

A company has an application server accessible internally at 192.168.1.100 and externally via a public IP 203.0.113.45. Without split-horizon, internal users would connect through the external firewall to reach their own server — inefficient and potentially insecure.

With split-horizon: internal DNS server returns 192.168.1.100 for app.company.com → internal traffic stays internal. External DNS server (hosted publicly) returns 203.0.113.45 → internet users connect through the normal public path.

Security note: split-horizon prevents internal server names and addresses from being exposed to external queries — attackers cannot enumerate internal infrastructure via DNS.

DNS Security Comparison Table

Technology	What It Protects Against	What It Doesn't Do	Port
DNSSEC	Cache poisoning, tampered DNS responses, forged records	Does not encrypt queries — queries are still visible in plaintext	53 (UDP/TCP)
DNS over TLS (DoT)	Eavesdropping on DNS queries, on-path manipulation	Does not validate record authenticity (use with DNSSEC for full protection)	853 (TCP)
DNS over HTTPS (DoH)	Eavesdropping, ISP monitoring, network-level censorship	Harder for enterprises to filter/monitor; doesn't authenticate records	443 (TCP)
DNSSEC + DoT/DoH	Both authentication AND encryption — full DNS security	Not protection against DNS hijacking at the endpoint (malware)	853 or 443
Split-Horizon DNS	Internal infrastructure enumeration by external attackers	Does not prevent attacks against the DNS server itself	53 (UDP/TCP)

Exam Scenarios

Scenario 1: Users are being redirected to a fake banking site even though they type the correct URL. Investigation reveals the local DNS resolver has incorrect records for the bank's domain. What attack occurred and what is the primary defence? Answer: DNS cache poisoning. The attacker injected false records into the resolver's cache. The primary defence is DNSSEC — cryptographic signatures on DNS records allow the resolver to detect and reject tampered responses.

Scenario 2: A company wants to encrypt DNS queries from employee devices to prevent ISPs from logging which sites employees visit, while still allowing the IT team to monitor and filter DNS traffic at the network level. Which encrypted DNS protocol should they use? Answer: DNS over TLS (DoT) on port 853. DoT encrypts DNS queries but uses a dedicated port that is identifiable and manageable — IT can monitor port 853 traffic and apply filtering policy. DoH on port 443 would blend with HTTPS and be much harder to inspect.

Scenario 3: An organisation needs internal users to resolve app.company.com to an internal private IP address while external users resolve the same name to a public IP. What DNS technique achieves this? Answer: Split-horizon (split-brain) DNS. An internal DNS server returns the private IP to internal clients; an external-facing DNS server returns the public IP to internet clients. This also prevents internal IP ranges from being exposed in public DNS.

Scenario 4: A security analyst notices unusually long subdomains in DNS queries leaving the network — strings like "dGhpcyBpcyBzZWNyZXQgZGF0YQ.attacker.com". What type of attack is this? Answer: DNS tunnelling. The attacker is encoding data (likely Base64) inside DNS query subdomains to exfiltrate data or maintain a covert C2 channel. Detection relies on DNS anomaly monitoring — abnormal subdomain length, query frequency, and entropy analysis.

Scenario 5: A company's home office employees have their DNS settings changed by malware on their router, redirecting all DNS queries to an attacker-controlled server. What type of attack is this? Answer: DNS hijacking via router compromise. The attacker changed the router's DNS configuration so all DHCP clients receive a malicious DNS server address. DNSSEC alone does not prevent this — even with DNSSEC, if the client's resolver is an attacker-controlled server that ignores validation. Defence: secure router credentials, firmware updates, and monitoring for DNS setting changes.

Scenario 6: What record type in DNSSEC proves that a DNS name does NOT exist, preventing attackers from fabricating negative responses? Answer: NSEC (Next Secure) or NSEC3 records. They provide authenticated denial of existence — the resolver can cryptographically verify that a queried name truly doesn't exist in the zone, preventing an attacker from claiming a domain doesn't exist when it does.

Prepare for Security+ and Network+

Free cheat sheets, study guides, and practice scenarios.

View Cheat Sheet →

DNS Security Explained