pk.org: Computer Security/Lecture Notes

DNS Attacks

Exploiting the Internet's Phone Book

Paul Krzyzanowski – 2025-11-11

Part 1: Link Layer Attacks
Part 2: Network Layer Attacks
Part 3: Transport Layer Attacks
Part 4: DNS Attacks
Part 5: DDoS Attacks

The Domain Name System (DNS) is one of the internet's most critical infrastructure components, yet it operates with minimal built-in security. Every time you type a web address, send an email, or connect to an online service, DNS works invisibly in the background, translating human-readable domain names like cs.rutgers.edu into machine-readable IP addresses like 128.6.48.178.

Because DNS is so fundamental to internet operations, attacks against DNS can have a widespread impact. A compromised DNS response can redirect users to malicious websites, intercept email, enable phishing attacks, or take services completely offline. To understand DNS vulnerabilities, we first need to understand how DNS works, and then examine the various ways attackers exploit its trust-based design.

How DNS Works

Disclaimer: This is a high-level overview and doesn't touch on all the functions of DNS.

DNS operates as a distributed, hierarchical database. When your computer needs to resolve a domain name to an IP address, it follows a multi-step process involving several types of DNS servers:

The DNS Hierarchy

The DNS namespace is organized as a tree, with the root at the top:

  1. Root servers: The top level, represented by a dot (.). There are 13 root server addresses operated by different organizations worldwide.

  2. Top-level domain (TLD) servers: Servers responsible for domains like .com, .org, .edu, .gov, and country codes like .uk, .jp.

  3. Authoritative name servers: Servers that have definitive information about specific domains (like www.rutgers.edu).

DNS Resolution Process

When you type www.rutgers.edu into your browser, here's what happens:

  1. Local cache check: Your computer first checks its own cache to see if it recently looked up this domain.

  2. Recursive resolver query: If not cached, your computer contacts a recursive resolver (usually operated by your ISP or a service like Google's 8.8.8.8 or Cloudflare's 1.1.1.1).

  3. Root server query: If the resolver doesn't have the answer cached, it queries a root server asking "who handles .edu domains?"

  4. TLD server query: The root server responds with the IP addresses of .edu TLD servers (a list of 13 servers a.edu-servers.net, ... m.edu-servers.net). The resolver then picks one of those TLD servers and asks "who handles rutgers.edu?"

  5. Authoritative server query: The TLD server responds with the IP addresses of rutgers.edu's authoritative name servers (dns2.rutgers.edu and ns1.rutgers.edu). The resolver asks one of these servers, "what's the IP address of www.rutgers.edu?"

  6. Final answer: The authoritative server responds with the IP address (128.6.46.88). The resolver caches this answer (typically for hours to days) and returns it to your computer.

DNS Record Types

DNS stores several types of records:

The Trust Problem

The original DNS design assumes all participants are honest. DNS responses are not authenticated, so resolvers trust that responses actually come from legitimate servers. DNS queries and responses typically use UDP (for speed), which makes them easy to spoof. Most DNS traffic is unencrypted, allowing anyone monitoring network traffic to see what domains you're looking up.

These trust assumptions create the vulnerabilities we'll explore.

The Dangers of DNS Attacks

DNS attacks are particularly dangerous because they can:

Affect many victims simultaneously: Compromising a single DNS server or poisoning a popular resolver's cache can impact thousands or millions of users.

Be difficult to detect: Users see familiar domain names in their browsers and may not realize they've been redirected to malicious sites.

Bypass some security measures: Even if you're careful about clicking links, DNS attacks can redirect legitimate requests without any suspicious indicators.

Enable other attacks: DNS hijacking often serves as the first step in sophisticated attack chains, enabling phishing, malware distribution, or man-in-the-middle attacks.

Persist invisibly: Once a DNS cache is poisoned or a DNS server is compromised, the malicious redirections continue automatically until the cache expires or the compromise is discovered.

Undermine HTTPS: While HTTPS encrypts the connection between your browser and a website, if DNS is compromised, you might be establishing an encrypted connection to an attacker's server instead of the legitimate site.

Pharming Attacks

Pharming is an attack that redirects users from legitimate websites to fraudulent ones by manipulating DNS resolution. Unlike phishing (which relies on fooling users into clicking malicious links), pharming works even when users type the correct address or click legitimate bookmarks. The name "pharming" suggests "farming" users, harvesting credentials and information at scale.

Pharming attacks can be implemented through several vectors:

Social Engineering Pharming

Attackers trick users into manually changing their DNS settings to use malicious DNS servers. Common tactics include:

Fake technical support: Scammers pose as technical support and convince users that changing their DNS settings will speed up their internet or fix connectivity problems.

Malicious tutorials: Attackers create seemingly helpful guides or videos that instruct users to change DNS settings as part of "optimizing" their system or accessing geo-restricted content.

Once users configure their systems to use attacker-controlled DNS servers, the attackers can resolve any domain to any IP address they choose, redirecting users to phishing sites or malware distribution points while appearing completely legitimate.

Malware-Based Pharming

More sophisticated attackers use malware to modify DNS settings automatically:

DNS hijacking malware: Infects computers and changes system DNS settings to use attacker-controlled servers. The malware often hides these changes or makes them difficult to revert.

Hosts file modification: The hosts file (located at /etc/hosts on Unix/Linux/Mac or C:\Windows\System32\drivers\etc\hosts on Windows) allows local DNS overrides. Malware can add entries mapping legitimate domains to malicious IP addresses. Because the hosts file is checked before DNS queries, these entries take precedence over legitimate DNS responses.

Router compromise: Some malware targets home routers, changing the DNS settings for the entire network. This affects all devices connected to the router, including smartphones, tablets, and IoT devices that users might not think to check for DNS configuration issues.

DHCP-Based Pharming

The Dynamic Host Configuration Protocol (DHCP) automatically configures network settings for devices joining a network. When you connect to a Wi-Fi network, DHCP typically provides your IP address, default gateway, and DNS server addresses.

Attackers can exploit DHCP in several ways:

Rogue DHCP servers: An attacker on a network (such as a coffee shop Wi-Fi) runs a rogue DHCP server. If the attacker's server responds faster than the legitimate one, connecting devices receive malicious DNS server addresses.

Compromised DHCP servers: Attackers compromise a network's legitimate DHCP server and modify it to distribute attacker-controlled DNS addresses to all clients.

Evil twin access points: Attackers set up fake Wi-Fi access points with legitimate-sounding names. Users connecting to these fake networks receive DHCP configurations that include malicious DNS servers.

DNS Server Compromise

The most impactful pharming attack involves compromising DNS servers themselves:

Recursive resolver compromise: Attackers compromise DNS servers operated by ISPs or public DNS services. Because these servers handle queries for many users, a single compromise affects a large population.

Authoritative server compromise: Attackers compromise authoritative name servers for specific domains. This allows them to change the legitimate DNS records, redirecting all users of that domain.

Registrar account compromise: Attackers gain access to domain registrar accounts and change the authoritative name servers to attacker-controlled servers. This gives them complete control over domain resolution without compromising the legitimate name servers.

Defending Against Pharming

Defense requires multiple approaches:

User education: Train users to recognize suspicious requests to change DNS settings and to verify secure connections (HTTPS with valid certificates).

Network security: Implement network access controls to prevent rogue DHCP servers. Use managed switches with DHCP snooping to validate DHCP messages.

Endpoint security: Deploy antimalware software that monitors for changes to DNS settings and hosts files. Regular security audits should verify DNS configurations.

DNS security extensions: Implement DNSSEC (discussed later) to authenticate DNS responses.

Certificate validation: Even if DNS is compromised, HTTPS certificate validation can alert users when the certificate doesn't match the expected domain (though sophisticated attackers may obtain fraudulent certificates through various means).

DNS Cache Poisoning

DNS cache poisoning (also called DNS spoofing) is an attack where an attacker injects false DNS records into a resolver's cache, causing the resolver to return incorrect IP addresses to users. Once poisoned, the cache serves malicious responses to all users of that resolver until the cache entries expire.

How Cache Poisoning Works

The attack exploits the fundamental design of DNS:

  1. The attacker identifies a target domain (like bank.example.com) they want to hijack.

  2. The attacker triggers a DNS query: They cause the target resolver to query for the domain. This might be done by sending a query to the resolver (if it accepts queries from external sources) or by getting a user on that resolver to visit a domain the attacker controls.

  3. The race begins: The resolver sends a query to an authoritative name server. The query includes a transaction ID (a 16-bit number) that the response must match.

  4. The attacker floods fake responses: Before the legitimate response arrives, the attacker rapidly sends thousands of fake DNS responses to the resolver, each with different transaction IDs, hoping one matches the query's transaction ID.

  5. If successful: If the attacker guesses the correct transaction ID before the legitimate response arrives, the resolver accepts the fake response and caches it. Now all users of that resolver receive the attacker's IP address when requesting bank.example.com.

The Kaminsky Attack

In 2008, Dan Kaminsky discovered a technique that made cache poisoning much more practical. Previous cache poisoning required the attacker to wait for cache entries to expire before making new attempts. Kaminsky's technique bypassed this limitation:

  1. Query for nonexistent subdomains: Instead of querying for www.example.com, the attacker queries for random subdomains that don't exist: asdf.example.com, qwerty.example.com, etc.

  2. Each query creates a new opportunity: Because these subdomains don't exist and aren't cached, each query triggers a new request to the authoritative server, giving the attacker a new opportunity to inject a poisoned response.

  3. Additional section poisoning: The attacker's fake responses include not just the answer for the random subdomain, but also an "additional section" that provides the IP address for www.example.com or the entire domain's authoritative name server. If the resolver accepts these additional records, the attacker has poisoned the cache with information that will be used for legitimate queries.

The Kaminsky attack revealed that DNS cache poisoning was far easier than previously believed, prompting urgent security updates across the internet.

Defenses Against Cache Poisoning

Several defenses have been deployed to make cache poisoning more difficult:

Source port randomization: In addition to the 16-bit transaction ID, modern resolvers randomize the UDP source port for queries. This gives attackers a much larger space to guess (16 bits of transaction ID × 50,000 possible ports = 3 billion combinations).

Query rate limiting: Resolvers can limit how many queries they accept for the same domain in a short time, making it harder for attackers to repeatedly trigger queries as part of cache poisoning attempts.

DNS cookies (RFC 7873): A lightweight transaction security mechanism where clients and servers exchange cookies, making it harder for off-path attackers to inject fake responses.

DNSSEC: Cryptographically signs DNS records, allowing resolvers to verify that responses haven't been tampered with. We'll explore DNSSEC in detail in the next section.

0x20 encoding: Randomizes the capitalization of domain names in queries (DNS is case-insensitive). The name comes from the ASCII bit (0x20) that distinguishes uppercase from lowercase letters. Because legitimate servers echo back the same capitalization, responses that don't match can be detected as spoofed.

Minimal responses: Resolvers should ignore additional records in responses that weren't explicitly requested, preventing additional section poisoning.

Despite these defenses, cache poisoning remains a threat, particularly for resolvers that haven't implemented modern protections or in situations where attackers have network-level capabilities.

DNSSEC: Cryptographic DNS Security

DNSSEC (DNS Security Extensions) adds cryptographic authentication to DNS, allowing resolvers to verify that DNS responses haven't been tampered with and actually come from the legitimate authoritative source.

How DNSSEC Works

DNSSEC uses public-key cryptography to create a chain of trust from the root zone down to individual domain records:

Digital signatures: Each DNS record is signed with the zone's private key. The signature is published as an RRSIG (Resource Record Signature) record alongside the data.

Public keys published: The public key needed to verify signatures is published as a DNSKEY record in the zone.

Chain of trust: Each zone's public key is signed by its parent zone. The root zone's public key is signed by itself (self-signed) and must be independently trusted (this is the "trust anchor"). Parent zones publish DS (Delegation Signer) records containing hashes of child zones' keys, forming this trust chain up to the DNS root.

Validation: When a resolver receives a DNS response, it can verify the signature using the public key, then verify that public key was signed by the parent zone, continuing up the chain to the root. If any link in the chain is broken or invalid, the resolver knows the response has been tampered with.

Authenticated denial: DNSSEC can cryptographically prove that a record or name does not exist, preventing attackers from falsely claiming nonexistent records.

DNSSEC Benefits

When properly implemented, DNSSEC provides:

Response authenticity: Confirms responses come from the authoritative name server for the domain.

Data integrity: Ensures responses haven't been modified in transit.

Cache poisoning prevention: Makes cache poisoning effectively impossible because fake responses can't be properly signed.

Protection against BGP hijacking: Even if BGP hijacking redirects queries to attacker-controlled servers, those servers can't forge valid DNSSEC signatures.

DNSSEC Adoption Challenges

Despite being standardized for over a decade, DNSSEC adoption remains limited. Several factors contribute to slow deployment:

Operational complexity: DNSSEC requires careful key management. Keys must be rotated periodically, and the rotation process must be coordinated between parent and child zones to avoid breaking resolution.

Larger responses: DNSSEC significantly increases DNS response sizes due to signatures and keys. This can cause issues with UDP packet fragmentation and networks that filter large UDP packets.

Performance impact: Signature verification adds computational overhead. While modern hardware handles this well, it's still a concern for high-volume DNS services.

Breaking changes: If DNSSEC is misconfigured (expired signatures, broken chain of trust), it causes resolution failures. The consequence of errors is severe: domains become completely unreachable rather than falling back to unsigned resolution.

Limited validation: Even if domains sign their zones, benefits only materialize if resolvers validate signatures. Many resolvers don't perform DNSSEC validation, so the effort to sign zones provides no security benefit for users of those resolvers.

No confidentiality: DNSSEC provides authentication and integrity but not encryption. DNS queries and responses remain visible to network observers.

Lack of incentive: Domain owners who implement DNSSEC bear the costs (operational complexity, larger responses) but can't ensure their users' resolvers will validate. Users benefit only if both the domain implements DNSSEC and their resolver validates it.

DNSSEC Status

As of 2024, DNSSEC deployment shows mixed results:

The result is a partially deployed security layer that provides strong protection when fully implemented but leaves gaps where it's absent.

DNS Rebinding Attacks

DNS rebinding is a sophisticated attack that bypasses the same-origin policy enforced by web browsers, allowing malicious websites to access services on the victim's private network.

Understanding the Same-Origin Policy

Web browsers enforce a same-origin policy: JavaScript running on a page from attacker.com cannot access content from bank.com. This policy is crucial for web security, preventing malicious sites from reading data from other sites.

The policy is based on:

If any of these differ, the browser treats them as different origins and blocks access. Note that the browser considers the domain name, and not the IP address of that domain. This was a deliberate decision since IP addresses may change due to load balancing or failover, but it creates a vulnerability.

How DNS Rebinding Works

DNS rebinding exploits a weakness in how browsers evaluate the same-origin policy in combination with DNS time-to-live (TTL) values.

A rebinding attack allows attackers to provide different IP addresses for the same domain when the victim queries it repeatedly.

A common use of this attack is to run JavaScript that probes addresses on the victim's local network, allowing the attacker to check for exploitable services.

Since the attacker controls the DNS service for their domain, the first query for the domain name returns the attacker's real address (so the victim can load a malicious page and JavaScript), but it has a short TTL (time-to-live), so the address doesn't remain cached for long.

A bit later, when the JavaScript runs, it accesses the attacker's domain again (which the web security model permits because it's the same name), but now the address is no longer cached because of the short TTL, which means the system has to contact the attacker's DNS service for another lookup. The DNS service now returns an IP address on the victim's internal network (or a guess). The JavaScript can try repeatedly, getting different addresses each time.

Here's a concrete example:

The Attack Scenario:

  1. Victim visits malicious site: You visit malicious-game.com, a seemingly innocent online game site that the attacker controls completely, including its DNS server.

  2. Initial DNS response: When your browser looks up malicious-game.com, the attacker's DNS server responds with the attacker's public server IP (like 203.0.113.50) and sets a very short TTL of 0 seconds, telling your browser not to cache this result.

  3. Malicious JavaScript loads: The game page loads from 203.0.113.50 and includes JavaScript that starts making requests back to malicious-game.com to "save your score" or "load game data."

  4. DNS rebinding occurs: Because of the 0-second TTL, your browser makes a new DNS query for malicious-game.com. This time, the attacker's DNS server responds with 192.168.1.1: your home router's private IP address.

  5. Same-origin bypass: From your browser's perspective, the JavaScript is still making requests to malicious-game.com (same domain = same origin). But those requests now go to 192.168.1.1. The browser allows this because the domain name hasn't changed—only the IP address has.

  6. Router compromise: The attacker's JavaScript can now interact with your router's web interface at 192.168.1.1. Many home routers don't require authentication when accessed from inside the local network, so the JavaScript can read your WiFi password, change DNS settings to point to the attacker's DNS servers permanently, or modify other router configurations.

The beauty (from an attacker's perspective) is that you never left the game website: you're still on malicious-game.com. The browser's URL bar shows nothing suspicious. But the attacker's code is now talking to devices on your private network that should be completely inaccessible from the internet.

Attack Scenarios

DNS rebinding enables several dangerous attack scenarios:

Router configuration access: Many home routers have web interfaces accessible without authentication from the local network. DNS rebinding allows external attackers to access these interfaces and potentially reconfigure routers, change DNS settings, or extract WiFi passwords.

Local service exploitation: Development servers, databases, or other services running on the victim's machine (localhost) become accessible. If these services lack authentication (common for development environments), attackers can exploit them.

Internal network reconnaissance: Attackers can scan the victim's internal network, identifying devices and services that exist behind firewalls.

IoT device control: Many IoT devices have web interfaces with weak or no authentication when accessed from the local network. DNS rebinding can enable external control of security cameras, smart home devices, or industrial control systems.

Defending Against DNS Rebinding

Defense against DNS rebinding requires multiple approaches:

DNS rebinding protection in browsers: Modern browsers implement some protections, such as pinning DNS results for the lifetime of a page or blocking resolution to private IP addresses for public domain names. However, these protections aren't perfect.

DNS Response Filtering: DNS resolvers can filter responses that attempt to resolve public domain names to private IP addresses. Public DNS services like Google Public DNS and Cloudflare implement such filtering.

Authentication on local services: Services on private networks should require authentication even for local access. Many home routers and IoT devices fail this requirement.

Host file management: Legitimate services that need to bind to specific domain names can use hosts file entries with appropriate IP addresses, bypassing DNS entirely.

Short-lived browser sessions: Limiting browser session lifetimes reduces the window for rebinding attacks to succeed.

Application-level defenses: Services can verify the Host header in HTTP requests and reject requests where the Host header doesn't match expected values.

Despite these defenses, DNS rebinding remains a practical attack vector, particularly against poorly secured IoT devices and home networks.

Recent example

In May 2025, the Straiker AI Research team showed a DNS rebinding attack against internal Model Context Protocol (MCP) servers. MCP servers expose local tools, files, or system functions so an AI assistant can use them. The attack lures a user to a malicious domain that first resolves to a public IP, then quickly rebinds to 127.0.0.1 or another internal address. The victim's browser keeps treating the site as the same origin and forwards traffic into the local MCP server over a long-lived Server-Sent Events connection. Once that channel is open, the attacker can issue internal MCP tool calls and exfiltrate data.

Sitting Ducks Attacks

Sitting Ducks is a DNS hijacking technique that allows attackers to gain complete control over legitimate domain names without compromising the domain owner's account at the registrar or DNS provider. First documented in 2016 but widely exploited since 2018, this attack vector has resulted in tens of thousands of hijacked domains, including those belonging to well-known brands, nonprofits, and government entities.

How Sitting Ducks Attacks Work

The attack exploits a combination of DNS misconfiguration and insufficient ownership verification:

Domain with broken DNS delegation: A domain is configured to use specific name servers, but those name servers either don't exist anymore, were never properly set up, or point to expired hosting services. Imagine a domain that says "ask server X for my DNS records," but server X doesn't actually have any records for that domain—this broken configuration is called "lame delegation."

Split DNS providers: The domain uses a DNS hosting provider that's different from the domain registrar (e.g., registered at GoDaddy but using another company's DNS services).

Exploitable DNS provider: The DNS hosting provider allows new accounts to claim domains without properly verifying ownership.

The attack: An attacker simply creates an account at the DNS provider and claims the broken domain. The provider allows them to configure DNS records without verifying they own the domain at the registrar. The attacker now controls where the domain points, while the legitimate owner still has their domain registered and may not realize anything is wrong.

Scale and Impact

Research by Infoblox and Eclypsium in 2024 identified approximately 800,000 vulnerable domains, with roughly 70,000 already hijacked. The attack is:

Easy to execute: Requires no sophisticated hacking skills, just identifying vulnerable domains and signing up for DNS provider accounts.

Difficult to detect: The domain registration remains valid and in the legitimate owner's control. DNS records appear to be functioning normally. The hijack may go unnoticed until the domain is used maliciously.

Widely exploited: Multiple Russian cybercriminal groups have actively used this technique since at least 2019 for spam campaigns, phishing, malware distribution (including IcedID, DarkGate, and AsyncRAT), and command-and-control infrastructure.

Defending Against Sitting Ducks

Organizations can protect their domains through several measures:

Verify DNS configurations: Regularly check that all your name servers are properly configured and actively serving your domains.

Use consistent providers: When possible, use your domain registrar's DNS services rather than third-party providers, eliminating the split-provider vulnerability.

Monitor DNS changes: Implement alerts for unexpected DNS record changes.

Choose secure providers: Select DNS providers that properly verify domain ownership before allowing accounts to claim domains.

Regular audits: Periodically audit older domains (especially those 10+ years old) as these are more likely to have accumulated configuration issues.

Conclusion: The Ongoing Challenge of DNS Security

DNS security illustrates the challenges of securing foundational internet infrastructure. The protocol was designed for a smaller, more trusted internet and never anticipated the scale, diversity, and threat landscape of today's internet.

Each attack vector we've examined exploits different aspects of DNS's trust-based design:

Comprehensive DNS security requires defense in depth:

The slow adoption of DNSSEC demonstrates that technical solutions alone are insufficient. Success requires coordination across registrars, DNS providers, resolver operators, domain owners, and users—a coordination challenge as complex as the technical ones.

DNS will remain a critical attack surface. As DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) add encryption, they address some threats while introducing new considerations around centralization and monitoring. As the internet continues to evolve, DNS security will require continuous attention, improvement, and adaptation to emerging threats.

Next: DDoS Attacks