This chapter covers DNS hijacking, cache poisoning, and DNSSEC — three critical topics for the Network+ N10-009 exam under Objective 4.1 (Explain common network attacks and their mitigations). DNS attacks are among the most prevalent network threats, and understanding how they work and how to defend against them is essential for any network administrator. Approximately 10-15% of exam questions in the Network Security domain will touch on these concepts, often asking you to identify attack types or recommend mitigation strategies.
Jump to a section
Imagine a large public library where every book's location is recorded in a card catalog. A patron asks for 'War and Peace,' and the librarian checks the catalog, sees it's on shelf 42A, and retrieves it. Now suppose a malicious person sneaks in at night and replaces the card for 'War and Peace' with one pointing to 'The Anarchist Cookbook' on shelf 13B. The next patron asking for Tolstoy gets the wrong book. Worse, if the librarian trusts the catalog and doesn't verify, the wrong book is handed out repeatedly until someone notices. DNS cache poisoning works the same way: a resolver (the librarian) caches DNS records (the cards). An attacker injects a forged record (swapped card) associating a legitimate domain (book title) with a malicious IP address (wrong shelf). All subsequent queries from clients (patrons) are answered with the poisoned data, redirecting traffic to attacker-controlled servers. DNSSEC is like adding a tamper-evident seal to each card: the librarian can cryptographically verify that the card hasn't been altered since the library's central authority signed it. Even if the card is swapped, the seal breaks, and the librarian rejects it.
What is DNS Hijacking?
DNS hijacking is an attack that redirects DNS queries to a different, often malicious, DNS server, or alters the DNS resolution process to return incorrect IP addresses. The goal is to intercept traffic intended for a legitimate domain and send it to an attacker-controlled server. There are several vectors:
- Router/Resolver Hijacking: An attacker gains access to a router or network device and changes its DNS settings to point to a rogue DNS server. All clients using that router's DHCP will then use the attacker's DNS.
- Man-in-the-Middle (MITM) Attacks: The attacker intercepts DNS requests and responses in transit, modifying them before they reach the client or the legitimate DNS server. This can be done via ARP spoofing, rogue DHCP, or compromised network infrastructure.
- Malware: Some malware modifies the host file (on Windows: C:\Windows\System32\drivers\etc\hosts; on Linux: /etc/hosts) or changes the DNS server configuration in the network adapter settings.
- Registrar Hijacking: An attacker compromises the domain registrar account and changes the authoritative name servers for a domain, effectively taking control of the domain's DNS resolution.
How DNS Cache Poisoning Works
DNS cache poisoning (also called DNS spoofing) targets the caching mechanism of DNS resolvers. A resolver stores DNS query results in its cache to speed up subsequent requests. If an attacker can inject a forged DNS response into the cache, all future queries for that domain from any client using that resolver will be answered with the attacker's IP address.
Mechanism: 1. The attacker's DNS server sends a forged response to a resolver before the legitimate authoritative server can respond. This is called a 'race condition.' 2. The forged response must contain:
- A matching DNS transaction ID (16-bit random number, but historically predictable).
- The correct source IP address (the authoritative server's IP) and port (UDP 53, though source port randomization is a mitigation).
- The query name and type that the resolver is waiting for.
- Additional records: This is key for poisoning. The attacker can include extra resource records in the 'Additional' section of the DNS response that are not related to the original query. For example, if the resolver queries for example.com, the attacker can add an A record for www.example.com or even for google.com in the additional section. If the resolver does not validate that these additional records are within the same bailiwick (i.e., the domain name is in the same domain as the query), it will cache them.
Bailiwick Check: Modern resolvers implement bailiwick checking: they will only cache records that are within the same domain as the original query. For example, a response for example.com cannot include a record for www.attacker.com. However, older or misconfigured resolvers may not enforce this.
Kaminsky Attack: In 2008, Dan Kaminsky discovered a variant that allows poisoning without needing to predict the transaction ID. The attacker sends a flood of queries for non-existent subdomains under the target domain (e.g., 1.example.com, 2.example.com, etc.). For each query, the attacker sends a forged response that includes a glue record (an A record for the domain's name server) pointing to the attacker's IP. If any one of these responses is accepted, the resolver will start using the attacker's name server for the entire domain, effectively hijacking all future queries.
Defenses Against Cache Poisoning
Source Port Randomization: Resolvers randomize the UDP source port for each query, making it harder for attackers to guess the port number. The attacker must also guess the port, not just the transaction ID.
Transaction ID Randomization: Use cryptographically random transaction IDs (16-bit).
Query Name Randomization: For the Kaminsky attack, some resolvers use random case in the query name (e.g., ExAmPlE.com) because the case must match in the response.
DNSSEC: The definitive defense, as it cryptographically signs DNS data.
What is DNSSEC?
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records to ensure authenticity and integrity. It does not provide confidentiality (encryption). DNSSEC uses public-key cryptography: each zone signs its records with a private key, and resolvers verify the signatures using the zone's public key, which is itself signed by the parent zone, creating a chain of trust from the root.
Key Components: - RRSIG (Resource Record Signature): Contains the digital signature for a set of records. Each RRSIG is tied to a specific signer's DNSKEY. - DNSKEY (DNS Public Key): Contains the public key used to verify signatures. There are two types: - ZSK (Zone Signing Key): Signs the zone's records (RRSIGs). - KSK (Key Signing Key): Signs the DNSKEY record set (the ZSK). The KSK is signed by the parent zone via DS records. - DS (Delegation Signer): A hash of the child zone's KSK that is stored in the parent zone. This establishes the chain of trust. - NSEC/NSEC3 (Next Secure): Used for authenticated denial of existence. When a queried domain does not exist, the resolver returns an NSEC record that proves there is no record between two existing names, preventing zone walking. NSEC3 uses hashed names to make enumeration harder. - CDS/CDNSKEY: Child-to-parent signaling records that allow a child zone to automatically update DS records in the parent.
Validation Process: 1. A resolver receives a DNS response that includes RRSIG records. 2. The resolver fetches the DNSKEY for the zone from the parent's DS record (or from a trust anchor). 3. It verifies the RRSIG using the DNSKEY. 4. It then checks that the DNSKEY is signed by the parent's KSK (using the DS record). 5. This chain continues up to the root, which is a configured trust anchor.
Trust Anchor: The root zone's KSK is distributed with the resolver software or can be obtained via the IANA. The root zone has been signed since 2010.
Deployment Status: As of 2025, many top-level domains (TLDs) are signed, but adoption among second-level domains is still moderate. Many enterprises use DNSSEC validation internally.
Configuration and Verification
BIND (named): To enable DNSSEC validation, add:
dnssec-validation auto;To sign a zone, use dnssec-signzone:
dnssec-signzone -A -3 <salt> -N INCREMENT -o example.com -t example.com.dbWindows Server: DNSSEC can be configured via the DNS Manager GUI or PowerShell. Use Add-DnsServerSigningKey and Set-DnsServerZoneSigning.
Verification:
- dig example.com +dnssec shows DNSSEC records.
- delv example.com (from BIND) performs DNSSEC validation.
- nslookup -type=ds example.com queries DS records.
- named-checkzone -d example.com example.com.db checks zone file for DNSSEC issues.
Interaction with Related Technologies
DNS over HTTPS (DoH) and DNS over TLS (DoT): These encrypt DNS queries but do not provide authentication. DNSSEC complements them by ensuring the data is authentic, even over encrypted channels.
EDNS0: DNSSEC requires EDNS0 support because DNSSEC responses can exceed 512 bytes (the traditional UDP limit). EDNS0 allows larger UDP packets.
DNS64/NAT64: Used for IPv6 transition; DNSSEC validation must be aware of synthesized records.
CDN and Load Balancing: DNSSEC can complicate dynamic DNS updates and short TTLs used by CDNs. Some CDNs use a single signed zone with short TTLs to minimize impact.
1. Attacker Initiates Query Flood
The attacker sends thousands of DNS queries to a vulnerable resolver, each for a unique non-existent subdomain under the target domain (e.g., `1.example.com`, `2.example.com`, ...). The resolver forwards each query to the authoritative name server for `example.com`. The attacker's goal is to predict the transaction ID and source port for one of these queries and send a forged response before the legitimate server responds. The attacker uses a botnet or script to generate a high query rate, often exceeding 10,000 queries per second.
2. Attacker Sends Forged Responses
For every query sent, the attacker also sends a forged DNS response from a spoofed IP address (the authoritative server's IP). The forged response contains: the same query name, a guessed transaction ID, the correct source port (if not randomized), and an additional record section with a glue A record for the domain's name server pointing to the attacker's IP. The attacker may send hundreds of forged responses per second, hoping one matches the resolver's pending query.
3. Resolver Caches Poisoned Record
When a forged response arrives at the resolver with a matching transaction ID and source port, the resolver accepts it as valid. It caches the glue record: the name server for `example.com` now resolves to the attacker's IP. This cache entry has a TTL (typically set by the attacker to a high value, e.g., 86400 seconds). All subsequent queries for `example.com` will be directed to the attacker's name server, which can then provide any IP address for any subdomain.
4. Client Queries Resolver for Domain
A legitimate client, such as a user's browser, sends a DNS query for `www.example.com` to the poisoned resolver. The resolver checks its cache: it has the NS record for `example.com` pointing to the attacker's server. It then queries the attacker's name server for `www.example.com`. The attacker's server responds with a forged A record pointing to a malicious web server (e.g., a phishing site). The resolver caches this A record and returns it to the client.
5. Client Connects to Malicious Server
The client's browser connects to the IP address returned by the resolver, which is the attacker's server. The attacker's server may present a fake login page that steals credentials, serve malware, or perform a man-in-the-middle attack on TLS connections. The user has no indication that the DNS resolution was compromised. The attack persists until the poisoned cache entries expire or are manually flushed.
Scenario 1: Enterprise DNS Hijacking via Rogue DHCP
A medium-sized company with 500 employees uses a single Windows Server DNS resolver for internal name resolution. An attacker plugs a rogue DHCP server into the network, offering IP addresses with a malicious DNS server (192.168.1.100) instead of the corporate DNS (192.168.1.10). Clients that renew their DHCP lease receive the rogue DNS server. The attacker's DNS server returns a fake IP for mail.company.com (the internal mail server), redirecting all email traffic to a server that logs credentials. The network team discovers the issue when users complain about email login failures. The fix: implement DHCP snooping on switches to block unauthorized DHCP servers, and use static DNS configurations for critical devices. The attack could have been mitigated by using DNSSEC for internal zones, but most internal zones are not signed due to complexity.
Scenario 2: ISP-Level DNS Hijacking for Advertising
A major ISP in a developing country redirects DNS queries for non-existent domains to an advertising page. This is technically a form of DNS hijacking, though often legal in that jurisdiction. Users trying to access a mistyped domain see ads instead of a browser error. From a security perspective, this breaks the expected behavior of DNS and can be exploited by attackers if they can predict the redirected domain. For example, an attacker could register a domain that the ISP's DNS will redirect to, and then use the redirect to inject malicious content. The ISP defends this as a 'value-added service,' but it violates the principle of transparent DNS resolution.
Scenario 3: DNSSEC Deployment in a Government Agency
A federal agency with a .gov domain must implement DNSSEC per US government mandate (OMB M-08-23). The agency uses BIND on Linux servers. The zone administrator generates a KSK and ZSK using dnssec-keygen. The KSK is submitted to the .gov registry via a DS record update. The zone is signed using dnssec-signzone. The resolver at the agency is configured with dnssec-validation auto; and uses the root trust anchor. A common issue: the ZSK expires, causing validation failures. The admin sets up automatic key rollover using dnssec-settime and cron jobs. Performance consideration: signed zones are larger (about 3x the size), so zone transfers take longer. The agency uses IXFR (incremental zone transfer) to minimize bandwidth. When a user's browser connects to an external website that is not DNSSEC-signed, the resolver simply returns the records without the AD (Authenticated Data) flag, and the browser proceeds normally. If validation fails (e.g., expired signature), the resolver returns SERVFAIL, causing the user to see a 'DNS error' page.
N10-009 Objective 4.1: Explain common network attacks and their mitigations.
This objective specifically includes DNS poisoning, DNS hijacking, and DNSSEC. The exam will ask you to:
Identify the attack type from a scenario description.
Recommend a mitigation (e.g., DNSSEC, source port randomization, bailiwick checking).
Understand the difference between hijacking (redirecting queries to a different server) and poisoning (corrupting the cache).
Common Wrong Answers and Why Candidates Choose Them: 1. Confusing DNS hijacking with DNS poisoning: Candidates often think hijacking is the same as poisoning. The key difference: hijacking changes where the query goes (the resolver itself is replaced or redirected), while poisoning corrupts the data inside a legitimate resolver's cache. 2. Thinking DNSSEC encrypts DNS queries: DNSSEC provides authentication and integrity, not confidentiality. Encrypted DNS is provided by DNS over TLS (DoT) or DNS over HTTPS (DoH). Candidates see 'security' and assume encryption. 3. Believing that DNSSEC prevents all DNS attacks: DNSSEC does not prevent DDoS attacks on DNS servers, nor does it protect against attacks on the resolver itself (e.g., exploiting a software bug). It only ensures the data is authentic. 4. Assuming that DNSSEC is widely deployed and enabled by default: Many networks do not use DNSSEC validation. The exam may present a scenario where a company does not use DNSSEC, and you must recommend it as a mitigation.
Specific Numbers and Terms to Memorize: - UDP port 53 (DNS) - Transaction ID: 16-bit random number - Source port randomization: mitigates cache poisoning - TTL (Time to Live): how long a record stays in cache; attackers set high TTLs to prolong poisoning. - Kaminsky attack: exploits the ability to inject glue records without bailiwick check. - DNSSEC record types: RRSIG, DNSKEY, DS, NSEC/NSEC3. - Trust anchor: the root KSK. - EDNS0: required for DNSSEC (larger UDP packets). - Chain of trust: from root to TLD to domain.
Edge Cases the Exam Loves: - What happens if a DNSSEC signature expires? The resolver returns SERVFAIL. - What if the parent zone does not have a DS record? The child zone is considered insecure; validation is not performed. - Can DNSSEC be used with dynamic DNS? Yes, but it requires automatic key management (e.g., using CDS/CDNSKEY).
How to Eliminate Wrong Answers: - If the question mentions 'redirecting users to a fake website' and the DNS server is changed, it's hijacking. If the DNS server is legitimate but its cache is corrupted, it's poisoning. - If the answer suggests 'encrypting DNS traffic' as a defense against cache poisoning, eliminate it — encryption does not prevent injection of forged responses; DNSSEC does. - If the question asks for a way to 'authenticate DNS data,' the answer is DNSSEC, not DNSCrypt (which encrypts).
DNS hijacking redirects queries to a rogue server; DNS cache poising corrupts a legitimate resolver's cache.
The Kaminsky attack allows poisoning without guessing the transaction ID by flooding queries with non-existent subdomains.
DNSSEC uses RRSIG, DNSKEY, and DS records to create a chain of trust from the root zone.
DNSSEC does not encrypt DNS traffic; it only provides authentication and integrity.
Source port randomization mitigates cache poisoning by making it harder to forge responses.
The root zone has been DNSSEC-signed since 2010; the root KSK is the trust anchor.
DNSSEC validation failure (e.g., expired signature) results in SERVFAIL, not fallback to insecure mode.
These come up on the exam all the time. Here's how to tell them apart.
DNS Hijacking
Redirects queries to a rogue DNS server by altering network configuration.
Can be done via router compromise, malware, or rogue DHCP.
Affects all clients using the compromised resolver.
Does not rely on caching; the rogue server answers all queries.
Mitigation: Use static DNS settings, DHCP snooping, monitor DNS server changes.
DNS Cache Poisoning
Injects forged records into a legitimate resolver's cache.
Requires the attacker to send forged responses that match an outstanding query.
Affects only the poisoned resolver's cache; other resolvers unaffected.
Relies on caching; the effect lasts until TTL expires or cache is flushed.
Mitigation: Source port randomization, DNSSEC, bailiwick checking.
Mistake
DNSSEC encrypts DNS queries and responses.
Correct
DNSSEC does not provide encryption; it only adds digital signatures for authentication and integrity. Encryption is provided by DNS over TLS (DoT) or DNS over HTTPS (DoH).
Mistake
DNS cache poisoning can only happen if the attacker can guess the transaction ID.
Correct
The Kaminsky attack bypasses transaction ID guessing by flooding queries and injecting glue records. Modern mitigations include source port randomization and query name randomization.
Mistake
Once a DNS resolver is configured with DNSSEC, all DNS queries are validated.
Correct
DNSSEC validation only occurs if the queried domain is signed and the resolver has a trust anchor. Many domains are not signed, so the resolver will return records without the authenticated data flag.
Mistake
DNS hijacking and DNS cache poisoning are the same attack.
Correct
Hijacking redirects the DNS query to a different server (e.g., by changing resolver settings or compromising a router). Poisoning corrupts the cache of a legitimate resolver. They are different attack vectors.
Mistake
The root zone is not signed, so DNSSEC cannot be trusted.
Correct
The root zone has been signed since 2010. The root KSK is the ultimate trust anchor for DNSSEC validation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
DNS hijacking involves changing the DNS server that a client uses (e.g., by modifying router settings or host file) to redirect all queries to a malicious server. DNS cache poisoning involves inserting forged DNS records into a legitimate resolver's cache, so that queries for specific domains return incorrect IP addresses. The key difference: hijacking changes where queries are sent; poisoning corrupts the data within a legitimate resolver.
DNSSEC adds digital signatures to DNS records. When a resolver receives a response, it can verify the signature using the zone's public key (DNSKEY), which is itself signed by the parent zone. If the signature is invalid, the resolver rejects the response and does not cache it. This prevents forged responses from being accepted, even if they match the transaction ID and port.
The Kaminsky attack is a sophisticated DNS cache poisoning technique discovered by Dan Kaminsky in 2008. Instead of guessing the transaction ID for a single query, the attacker sends many queries for unique non-existent subdomains (e.g., 1.example.com, 2.example.com). For each query, the attacker sends a forged response that includes a glue record for the domain's name server, pointing to the attacker's IP. If any one response is accepted, the resolver's cache is poisoned for the entire domain.
No. DNSSEC only provides data origin authentication and integrity. It does not encrypt the query or response. Encryption of DNS traffic is achieved by DNS over TLS (DoT) or DNS over HTTPS (DoH). DNSSEC can be used together with DoT/DoH to provide both authentication and confidentiality.
A trust anchor is a pre-configured public key (usually the root zone's KSK) that the resolver trusts without validation. The resolver uses this trust anchor to verify the signatures of the root zone, which in turn signs the DS records of TLDs, creating a chain of trust. The root trust anchor is distributed with resolver software and can be updated manually or via RFC 5011 automated updates.
If the RRSIG signature on a record has expired, the resolver will consider the response invalid and return a SERVFAIL error to the client. The resolver will not fall back to insecure mode; it will treat the domain as having a DNSSEC failure. This is why proper key management and timely re-signing are critical.
No. DNSSEC does not protect against DDoS attacks that overwhelm the DNS server with traffic. It only ensures the authenticity of DNS data. DDoS mitigation requires other measures like rate limiting, anycast, or dedicated DDoS protection services.
You've just covered DNS Hijacking, Cache Poisoning, and DNSSEC — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?