Nearly every Internet connection begins with a name lookup. A browser cannot send a packet to www.rutgers.edu until something has told it that the name means 128.6.46.88. The browser believes whatever it is told. An attacker who controls the response controls where the user goes. The user sees the correct name in the address bar the entire time.

The Domain Name System was designed in 1983. A traditional lookup is an unencrypted exchange over UDP in which a handful of fields match a reply to its query, fields anyone can guess or copy. That lookup is the baseline for this part; DNS can also run over TCP, and encrypted forms of it are covered at the end.

We begin with how a lookup works, since every attack depends on a detail of that process. Pharming follows: the ways an attacker changes which name server a victim asks. Next is cache poisoning, which forges the response in transit, along with DNSSEC, the signed version of DNS designed to stop it. We end with two attacks that use DNS as designed, DNS rebinding and domain hijacking through abandoned delegations, and with the encrypted DNS protocols that address what DNSSEC does not.

How DNS Works

Before DNS, every host on the ARPANET kept a file listing the name and address of every other host, maintained by hand at one site and copied by file transfer. By 1983, the file was out of date as soon as it was published, and two standards published that November replaced it with a distributed database.

The Name Hierarchy

A domain name is read from right to left. The name www.cs.rutgers.edu is a host named www in the domain cs.rutgers.edu, which is inside rutgers.edu, which is inside the top-level domain edu, which is inside the root. The namespace is divided into zones, each served by its own set of servers. A zone’s servers serve the names in the zone and know where to find the servers for any part of it that has been delegated to someone else. Not every label is a separate zone: cs.rutgers.edu may be delegated to the computer science department or served from the same zone as rutgers.edu.

The DNS hierarchy has three main kinds of servers. The root servers know which servers handle each top-level domain; there are thirteen named root server identities, run by twelve organizations, each served by many physical machines around the world. The top-level domain servers for edu, com, and the rest know which servers are authoritative for each domain registered beneath them. The authoritative name servers for a domain hold its records; Rutgers runs the authoritative servers for rutgers.edu.

A domain under a top-level domain is created by registering it with a registrar, a company accredited to sell names in that top-level domain. The registrar tells the top-level domain’s operator which name servers are authoritative for the new domain. Those name servers may be run by the domain’s owner, by the registrar, or by a separate DNS hosting company.

Resolution

A host does not walk this hierarchy itself. It sends its query to a recursive resolver, a server that performs the full lookup on its behalf and caches the results. The resolver is usually operated by the user’s Internet service provider or organization, though public resolvers such as Google’s 8.8.8.8 and Cloudflare’s 1.1.1.1 serve a large share of the world’s queries. A lookup of www.rutgers.edu by a resolver with an empty cache proceeds in four steps:

1. The resolver asks a root server for www.rutgers.edu. The root server does not know, but it replies with the addresses of the edu servers.

2. The resolver asks an edu server. That server replies with the names and addresses of the authoritative servers for rutgers.edu.

3. The resolver asks one of the Rutgers servers, which replies with the address.

4. The resolver returns the address to the host and caches everything it learned.

Each record has a time to live (TTL) set by the zone’s administrator, which tells the resolver how many seconds it may keep the record in its cache. A second query for any name under rutgers.edu goes straight to the Rutgers servers. A second query for www.rutgers.edu is served from the resolver’s cache without any queries to other servers. Caching is what makes DNS fast enough to run the Internet. It is also what makes a forged reply persist, since a poisoned record is served to every client of that resolver until its TTL expires.

A zone contains several kinds of records, and three come up in this part. An A record maps a name to an IPv4 address. An NS record names the authoritative servers for a zone. An MX record names the servers that accept email for the domain, which is why controlling a domain’s DNS also means controlling its mail.

What DNS Trusts

A traditional query is a UDP message that contains the name and record type being asked for and a 16-bit transaction ID. The resolver remembers which queries it has outstanding. It accepts a reply if the reply arrives from the server’s address at the port the query was sent from, repeats the transaction ID, and asks about the same name and type. Those fields let the resolver match replies to queries. They are not authentication. Anyone who can guess or observe them can produce a reply the resolver will accept, and a UDP packet’s source address can be forged. The query and the reply both travel in the clear, so anyone on the path can read which names a user is looking up. Every attack in this part exploits one of those facts.

Pharming

Pharming sends a user who typed the correct name of a site to a server the attacker runs, by changing which name server the victim’s machine asks or what that server says.

Pharming corrupts name resolution rather than tricking the user into clicking a link. The user types the bank’s name correctly, or follows a bookmark, and still arrives at the attacker’s server. The name is a play on phishing: the attacker farms victims instead of fishing for them one at a time. Each place a host’s lookups can be redirected needs a different kind of access:

• The hosts file, which needs the ability to write files on the victim’s machine. Operating systems commonly consult a local file, /etc/hosts on Unix-like systems and C:\Windows\System32\drivers\etc\hosts on Windows, before sending a DNS query. An entry there overrides DNS for that name.

• The host’s resolver setting, which needs code running on the victim’s machine. Malware changes the address of the DNS server the host uses, so that the attacker’s resolver responds to every query. Between 2007 and 2011, a group operating from Estonia did this on about four million computers to redirect web traffic through advertising they were paid for. When the FBI dismantled the operation in November 2011, so many machines depended on the attacker’s resolvers that a court ordered replacement servers to be run for eight months to keep the victims online.

• The home router, which needs the router’s administrative password, often the factory default. A router hands out a DNS server address to every device on the network through DHCP. Changing that one setting redirects every phone, laptop, and television in the house.

• The local network, which needs the attacker to be on it. A rogue DHCP server or an evil twin access point, both described in Part 1, hands out the attacker’s DNS server to every device that joins.

• The domain’s registrar account, which needs the domain owner’s credentials. An attacker who obtains them changes the NS records to point to name servers the attacker runs. Every resolver in the world then asks the attacker for that domain’s records. In 2019, researchers at Cisco described a campaign that had compromised registrars and DNS providers in the Middle East and used that access to intercept email and login credentials for government organizations in more than a dozen countries.

The defenses follow the access: endpoint protection for the first two, the router’s password and firmware for the third, and the switch controls from Part 1 for the fourth. The registrar account is defended with strong authentication and a registry lock, a service under which the registry will not change a domain’s name servers without an out-of-band confirmation from the owner. An ordinary registrar lock, which prevents a domain from being transferred to another registrar, does not provide that protection.

TLS limits all of these. A browser that reaches the attacker’s server through a corrupted lookup still expects a certificate for the name it typed. The attacker does not have one. The attack then depends on the user clicking past the warning, on the site not using HTTPS at all, or on the attacker obtaining a certificate. A registrar-level hijack makes the last of these possible, because certificate authorities verify domain ownership through DNS.

Cache Poisoning

Cache poisoning plants a forged DNS record in a resolver, so that every user of that resolver is sent to the attacker’s server for as long as the record stays cached.

The attack, also called DNS spoofing, changes a shared resolver’s cached response, so every client that receives that response is affected. An off-path attacker who controls neither the resolver nor the authoritative server does it by beating the real reply with a forged one:

1. The attacker causes the resolver to look up the target name, either by sending the query directly, if the resolver accepts queries from outside, or by getting a client of the resolver to request it.

2. The resolver sends its query to the authoritative server and waits for a reply that matches it.

3. The attacker floods the resolver with forged replies, each with the authoritative server’s source address and a different guess at the fields the resolver will check.

4. If a forged reply that matches arrives before the real one, the resolver caches it. The real reply arrives later and is discarded, because the query is no longer outstanding.

In the original resolvers, the only unpredictable field was the 16-bit transaction ID, and queries were sent from a fixed port. An attacker who could keep triggering queries had a fair chance of winning. The obstacle was the cache. Once the resolver had a record for the name, it stopped asking. The attacker had to wait for the TTL to expire before trying again.

The Kaminsky Attack

In 2008, security researcher Dan Kaminsky found a way around the cache. Instead of racing to poison the record for www.bank.example, the attacker queries non-existent names: aaaa.bank.example, aaab.bank.example, and so on. Each name is new, so each query goes to the authoritative server. Each one is a new chance to get a forged reply in first. The attacker can make thousands of attempts per second.

The forged reply does not respond with an address for the nonexistent name. It is a referral: it says that bank.example is served by the name server ns1.bank.example and includes that server’s address, which is the attacker’s. A referral is a normal reply, since it is how a parent zone points a resolver to a child’s servers. The resolver caches the name server’s address so it doesn’t have to look it up. From then on, the resolver asks the attacker’s server for every name in bank.example. One forged reply that arrives first is enough to make that resolver use the attacker’s name server for every future lookup under bank.example.

Most resolvers were affected at the time. Vendors coordinated a secret patch and released it simultaneously in July 2008. The patch didn’t stop the attack; it made guessing much harder, and it is the first defense below.

Defenses Against Forged Replies

One defense makes forged replies harder to produce, and one makes them detectable:

• Source port randomization. A resolver sends each query from a random UDP port, and a reply must arrive at that port. The attacker now has to guess both the port and the transaction ID, which raises the number of possibilities from about 65,000 to several billion. This was the 2008 patch.

• DNSSEC. Signed records, described next, let the resolver reject a forged record regardless of how it arrived.

Randomization defends against a blind attacker. An attacker on the path between the resolver and the authoritative server sees the query, port, and transaction ID. That attacker doesn’t need to guess at all. Against that attacker, only a signed reply helps.

DNSSEC

The DNS Security Extensions (DNSSEC) add digital signatures to DNS records so that a resolver can verify that a record was published by the zone’s administrator and has not been modified. DNSSEC authenticates data. It doesn’t encrypt anything, and it says nothing about who sent a reply, only whether the records are genuine.

The Chain of Trust

The administrator of a signed zone signs each set of records with the zone’s private key and publishes the signatures alongside the data, together with the zone’s public key. A resolver that receives a response and the key can check the signature, but it still has to know that the key is the right one. The parent zone authenticates the key.

Suppose example.edu is signed. The edu zone publishes a signed record containing a hash of the example.edu key. The root zone publishes a signed record containing a hash of the edu key. A resolver that trusts the root’s public key, the trust anchor that ships with the resolver software, can verify the entire chain from the root down to the record it asked for. The root zone was signed in July 2010. A signed zone also publishes signed records that prove a name does not exist; otherwise, an attacker could forge a reply claiming that a real name doesn’t exist.

A validating resolver handles a reply in one of three ways. If the zone is signed and the signatures verify through the chain to the trust anchor, the resolver accepts the data. If the parent zone states, in a signed record, that the zone is not signed at all, the resolver accepts the data as it always did; most of the Internet’s zones are in this state. If the zone should be signed but the signatures are missing, expired, or wrong, the reply is bogus, and the resolver discards it. The client then gets an error rather than a forged address. That is the behavior that stops cache poisoning for signed zones. It is also the behavior that makes DNSSEC mistakes expensive.

What DNSSEC Does Not Cover

Validation usually happens at the recursive resolver, not on the user’s machine. The resolver’s reply to the laptop is an ordinary unsigned DNS message, so an attacker between the two, such as the gateway in Part 1, can still forge it. Protecting that last hop takes either validation on the host itself or an authenticated connection to a resolver the host trusts, which is what the encrypted DNS protocols at the end of this part provide. DNSSEC also authenticates whatever a zone’s owner published. A malicious domain can sign its own records, including the private addresses used in the rebinding attack below.

Deployment

DNSSEC was standardized in 2005, and the root and almost every top-level domain are signed. Below that, adoption is thin. Only a few percent of com domains are signed. The share of the world’s users whose resolvers validate has hovered around a third for years, with large differences between providers and countries. Three factors keep adoption low:

• Operational risk. Keys must be rotated in coordination with the parent zone. An expired signature or a mismatched parent record makes the domain bogus for every validating resolver, without a fallback to unsigned replies. In September 2021, Slack’s attempt to enable DNSSEC made its service unreachable for many users for several hours, because an edge case in how one of its DNS providers signed wildcard records produced replies that validating resolvers rejected.

• Larger replies. Signatures and keys make replies several times larger. Replies that no longer fit in a single UDP packet are fragmented or retried over TCP. Many firewalls drop fragmented UDP packets.

• Split incentives. A domain owner who signs bears the operational burden, but the benefit only reaches users whose resolvers validate, which the owner cannot control.

When deployed on both ends, DNSSEC does what it was designed to do. A validating resolver cannot be poisoned for a signed zone. The forged responses used against MyEtherWallet in Part 2 would have been rejected as bogus had the domain been signed and the resolvers validating.

DNS Rebinding

DNS rebinding lets a script on a web page the victim visits send requests to devices on the victim’s private network, such as a home router or a development server, that the Internet is not supposed to be able to reach.

The attacks so far corrupt DNS. DNS rebinding uses it exactly as designed, against a security rule that assumed names and addresses were stable. A browser runs JavaScript from many sites at once. The same-origin policy prevents a script loaded from one site from reading responses from another. Two resources have the same origin if their URLs have the same scheme, host name, and port. The policy compares names, not addresses. A script from game.example may send requests to game.example and read the replies, whatever address that name currently resolves to, because addresses change for legitimate reasons.

The attacker needs a domain, its authoritative name server, and a victim who visits the attacker’s page. The target is a service on the victim’s own machine or local network that speaks HTTP, accepts requests without authentication from inside the network, and does not check which hostname the request was addressed to. Home routers, printers, and the development servers that programmers run on their own machines are common examples. The walkthrough uses a plain HTTP page, since an HTTPS page cannot switch to a local device that doesn’t have a certificate for the attacker’s name:

1. The victim visits http://game.example. The browser looks up the name. The attacker’s name server returns the address of the attacker’s web server with a very short TTL.

2. The page loads, and with it a script that waits.

3. The script makes a request back to http://game.example. If the browser looks the name up again, the attacker’s server now returns 192.168.1.1, the address of the victim’s router, or 127.0.0.1, the victim’s own machine.

4. The browser sends the request to the router. The request is to the same origin, so the policy allows the script to read the reply.

The script is now talking to a device inside the victim’s network. Anything that device will do for an unauthenticated local request, it will do for the script.

The attack was first described in 1996 against Java applets and has reappeared with every generation of software that assumed the local network was private. In May 2025, a security research team demonstrated it against servers that expose local tools to AI assistants through the Model Context Protocol, a standard for connecting assistants to tools and data. Visiting a malicious web page lets the page’s script invoke the local tools and read their responses. The second lookup in step 3 is where the sequence usually breaks. Browsers keep their own caches, and some pin an address for the life of a page. A short TTL does not guarantee that the name is looked up again.

The durable defense is on the local service: require authentication for every request, and check the Host header. A router that only responds to requests addressed to router.local then ignores a request addressed to game.example. Two other layers help. Resolvers and home routers can refuse to return private or loopback addresses for public names, which several public resolvers offer as a setting. And browsers have begun treating local network access as a permission: Chrome, starting with version 142 in 2025, asks the user before a public web page may send requests to a private address.

Hijacking Domains Through Abandoned Delegations

Hijacking an abandoned delegation gives the attacker control of a legitimate, established domain name, with its reputation intact, for phishing, malware distribution, and command-and-control servers.

The attacker needs nothing from the owner, neither registrar credentials nor a compromised server. The vulnerability is an inconsistency between what the registrar says and what the DNS provider knows. The domain’s NS records point to a DNS hosting provider, but the zone no longer exists there. The owner may have let a hosting subscription lapse, moved to another provider without updating the registrar, or set the records up incorrectly years earlier. The delegation is said to be lame. The domain may fail to resolve, or it may still resolve through other listed name servers, in which case the owner has no reason to notice.

If the provider lets a new customer claim a domain name without verifying ownership, an attacker can open an account, create a zone for the victim’s domain, and start responding to queries for it. The registrar’s records remain untouched, so the owner sees nothing wrong, and the domain keeps its history and reputation. Researchers first documented the technique in 2016.

In 2024, researchers at Infoblox and Eclypsium, two security companies, reported that they found about 800,000 vulnerable domains and about 70,000 hijacked ones, including domains of well-known brands, nonprofits, and government agencies, and named the attack Sitting Ducks.

The defense is housekeeping on the owner’s side and verification on the provider’s. Owners should remove name servers that no longer serve the domain and audit old domains. Those are the ones most likely to have a delegation nobody has looked at in a decade. The decisive failure is a provider that lets anyone claim any zone. The other half is using a provider that verifies control of a domain before serving it.

Encrypting DNS

DNSSEC authenticates records but leaves queries readable. An Internet service provider, a coffee shop, or anyone along the path sees every name a user looks up, revealing most of the sites the user visits. Two protocols encrypt the connection between the host and its resolver. DNS over TLS (DoT), standardized in 2016, runs DNS over a TLS connection on its own port. DNS over HTTPS (DoH), standardized in 2018, sends queries as HTTPS requests, so that they use the same port and look much like web traffic. Major browsers and operating systems support DoH, and some enable it by default.

Encryption protects the hop between the host and the resolver, which is the hop DNSSEC does not cover. An observer there cannot read the queries, and a forger there cannot respond to them. It does not go further. The resolver still sees every query. Its own lookups to authoritative servers are usually unencrypted, and an encrypted connection to a dishonest resolver delivers dishonest responses securely. Because DoH is often configured to use a large public resolver rather than the local one, it has also moved much of the world’s DNS traffic to a handful of companies. That concentration of visibility is something the original design never had.

What Each Defense Establishes

The defenses in this part protect different things, and none of them covers everything:

Lecture 10: Part 1 | Part 2 | Part 3 | Part 4
Lecture 10 Study Guide | List of terms