1 of 90

DNS

CS 161 Spring 2025 - Lecture 21

Computer Science 161

2 of 90

Last Time: TLS

TLS Handshake

Nonces make every handshake different (prevents replay attacks across connections)
Certificate proves server’s public key
DHE proves that the server owns the private key
DHE helps client and server agree on a shared secret key
MACs ensure no one tampered with the handshake
Messages are sent with symmetric encryption and MACs
Record numbers prevent replay attacks within a connection

2

Client

Server

ClientHello

ServerHello

Certificate

{g^a mod p}K^-1server

g^b mod p

{M, MAC(IB, M)}CB

{M, MAC(IS, M)}CS

Computer Science 161

3 of 90

Last Time: TLS

Security properties

Forward secrecy (thanks to DHE)
End-to-end security: Secure even if all intermediate hops are malicious
Not anonymous: Attackers can determine who you’re talking to
No availability: Connections can be dropped or censored

Can be used by the application layer (e.g., HTTPS)
Trusting certificate authorities can be hard

3

Computer Science 161

4 of 90

Outline

Domain Name System (DNS)

DNS name servers
Steps of a DNS lookup
Stub resolvers and recursive resolvers
DNS message format
DNS records
DNS lookup walkthrough

DNS Security

Cache poisoning attacks
Risk: Malicious name servers
Defense: Bailiwick checking
Risk: Network attackers (MITM, on-path, off-path)
Kaminsky attack
Defense: Source port randomization, glue validation

4

Computer Science 161

5 of 90

LAN/WAN	Local area (e.g. apartment) + wide-area (e.g. internet) networks. A router connects multiple LAN's.
Layer 2 (e.g. Ethernet)	Layer 2 (link layer) connects local machines in a LAN. MAC Addresses uniquely identify machines in a LAN.
Layer 3 (e.g. IP)	Layer 3 (internetwork layer) connects many LAN's. IP addresses uniquely identify machines globally.
Layer 4 (e.g. TCP/UDP)	Layer 4 (transport layer) provides the notion of a connection between individual processes on machines. UDP is a best-effort transport layer protocol (no guarantees on order, but less overhead). TCP is reliable, in-order, and connection-based protocol.
Layer 4.5 (e.g. TLS)	TLS provides a secure connection (e.g. secure channel of communication) between processes on machines.
Layer 7 (e.g. HTTP)	HTTP provides a framework to build applications on top of lower-level layers (e.g. HTTP GET/POST/…)
ARP (Address Resolution)	A protocol based on Layer 2 (e.g. Ethernet) to translate IP addresses into MAC addresses.
WPA (Wi-Fi Protected Access)	A protocol that enables secure wireless communication in a LAN. With WPA2-PSK, multiple devices within a LAN (e.g. multiple computers, or a computer and a router) can communicate securely.
DHCP (Dynamic Host Configuration Protocol)	A protocol based on Layer 2/3 (e.g. Ethernet and IP) that enables communication over a LAN and the internet. It allows clients to acquire an IP address, the IP address of the DNS server, and IP address of the router.
BGP (Border Gateway)	A protocol based on Layer 3 (e.g. IP addresses) that connects lots of local networks (border gateway protocol).
DNS (Domain Name System) & DNSSEC	A protocol based on Layer 4 (e.g. TCP) that allows computers to resolve https://google.com/ into 127.217.4.174 (IP addresses). It uses a hierarchical system of name servers that exist across the internet. DNS queries are made over UDP.

Computer Science 161

6 of 90

DNS

6

Computer Science 161

7 of 90

Domain Names

Computers are addressed by IP address on the Internet

Example: 74.125.25.99
Useful for machines: Can be used to route packets to the correct destination
Not useful for humans: Numbers are not meaningful to humans, hard to remember

More useful to humans: Human-readable domain names

Example: www.google.com
Not useful for machines: Contains no relevant routing information
Useful for humans: Meaningful words and phrases, easy to remember
Note: Domain names are not URLs. Domain names are part of a URL:�https://www.google.com/index.html

7

Computer Science 161

8 of 90

DNS: Definition

DNS (Domain Name System): An Internet protocol for translating human-readable domain names to IP addresses
Usage

You want to send a packet to a certain domain (e.g., you type a domain into your browser)
Your computer performs a DNS lookup to translate the domain name to an IP address
Your computer sends the packet to the corresponding IP address

8

74.125.25.99

www.google.com

DNS

Computer Science 161

9 of 90

DNS Name Servers

Name server: A server on the Internet responsible for answering DNS requests

Name servers have domain names and IP addresses too
Example: Domain a.edu-servers.net with IP 192.5.6.30 is a name server

Usage:

To perform a DNS lookup, your computer sends a DNS query (e.g., “What is the IP address of www.google.com?”)
The name server sends a DNS response with the answer (e.g., “The IP address of www.google.com is 74.125.25.99”)

Issues

One name server won’t be able to handle every DNS request from the entire Internet
If there are many name servers, how do you know which one to contact?

9

Computer Science 161

10 of 90

DNS Name Server Hierarchy

Idea #1: If one name server doesn’t know the answer to your query, the name server can direct you to another name server

Analogy: If I don't know the answer to your question, I will direct you to a friend who can help

Idea #2: Arrange the name servers in a tree hierarchy

Intuition: Name servers will direct you down the tree until you receive the answer to your query

10

. (root)

.edu

.org

.com

google.com

edstem.org

cs161.org

mit.edu

berkeley.edu

berkeley.edu is the oldest .edu domain!

Computer Science 161

11 of 90

DNS Name Server Hierarchy

11

Each box is a name server. The label represents which queries the name server is responsible for answering.

For example, this name server is responsible for .edu queries like eecs.berkeley.edu, but not a query like mail.google.com.

. (root)

.edu

.org

.com

google.com

edstem.org

cs161.org

mit.edu

berkeley.edu

Computer Science 161

12 of 90

DNS Hierarchy

Each node in the tree represents a zone of domains.

An organization managing a zone can delegate part of its zone to somebody else.

Each zone has an authoritative name server that knows about the domains in that zone.

12

The berkeley.edu zone

Owned by: UC Berkeley

Name server: adns1.berkeley.edu

Manages:

www.berkeley.edu

calcentral.berkeley.edu

systemstatus.berkeley.edu

...

The ischool.berkeley.edu zone

Owned by: School of Information

Name server: is-dns.berkeley.edu

Manages:

pink.ischool.berkeley.edu

blue.ischool.berkeley.edu

...

The eecs.berkeley.edu zone

Owned by: EECS Department

Name server: cs-dns.berkeley.edu

Manages:

repo.eecs.berkeley.edu

rise.eecs.berkeley.edu

...

Computer Science 161

13 of 90

Steps of a DNS Lookup

13

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

Let's walk through a DNS query for the IP address of eecs.berkeley.edu.

Computer Science 161

14 of 90

Steps of a DNS Lookup

14

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

DNS queries always start with a request to the root name server, which is responsible for all requests.

1

“What is the IP address of eecs.berkeley.edu?”

Computer Science 161

15 of 90

Steps of a DNS Lookup

15

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

The root name server responds by directing you to the correct child name server (in this case, the .edu name server).

1

2

“I don’t know, but I have delegated authority to the .edu name server.”

Computer Science 161

16 of 90

Steps of a DNS Lookup

16

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

1

2

3

“What is the IP address of eecs.berkeley.edu?”

Computer Science 161

17 of 90

Steps of a DNS Lookup

17

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

3

4

“I don’t know. But I have delegated authority to the berkeley.edu name server.”

1

2

Computer Science 161

18 of 90

Steps of a DNS Lookup

18

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

“What is the IP address of eecs.berkeley.edu?”

3

4

1

2

5

Computer Science 161

19 of 90

Steps of a DNS Lookup

19

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

5

6

“The IP address of eecs.berkeley.edu is 23.185.0.1.”

3

4

1

2

Computer Science 161

20 of 90

Stub Resolvers and Recursive Resolvers

In practice, your computer usually tells another resolver to perform the query for you
Stub resolver: The resolver on your computer

Only contacts the recursive resolver and receives the answer

Recursive resolver: The resolver that makes the actual DNS queries

Usually one recursive resolver per local network
Benefits: The recursive resolver can cache common requests for the network, building a large cache from multiple users’ requests
Reduces load on name servers
Recursive resolver asks the name server for www.google.com once, and can serve the answer to many users
Recursive resolvers usually run by ISPs or application providers (Google, Cloudflare)

20

Computer Science 161

21 of 90

Recall: DHCP Initial Network Configuration

To connect to a network, a user needs:

An IP address so that other people can contact the user
The IP address of the DNS server
The IP address of the router (gateway) so that the user can contact machines outside of the LAN

The first time a user connects, they don’t have this information yet

The user also doesn’t know who to ask for this information

DHCP gives the user a configuration when they first join the network

21

(← a recursive resolver!)

Computer Science 161

22 of 90

Steps of a DNS Lookup

22

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

The stub resolver sends the query to the recursive resolver.

1

Recursive Resolver

Computer Science 161

23 of 90

Steps of a DNS Lookup

23

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

The recursive resolver contacts all the name servers to answer the query, as we saw earlier.

Recursive Resolver

1

6

7

4

5

3

2

Computer Science 161

24 of 90

Steps of a DNS Lookup

24

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

The recursive resolver returns the final answer to the stub resolver.

Recursive Resolver

1

8

6

7

4

5

3

2

Computer Science 161

25 of 90

DNS Message Format

25

Computer Science 161

26 of 90

DNS Uses UDP

DNS is designed to be lightweight and fast

Any access that involves a domain name (websites, email, etc.) is preceded by a DNS query, so we want DNS lookups to be fast

DNS uses UDP instead of TCP for better performance

No 3-way handshake!

26

Computer Science 161

27 of 90

DNS Packet Format: UDP Header

Source port (16 bits): Chosen by the client

Can be randomized for security, as we’ll see later

Destination port (16 bits): Usually 53

DNS name servers answer requests on port 53

Checksum: Code to check the UDP payload was not corrupted in transit

You don’t need to worry about this

Length: Length of the UDP payload

You don’t need to worry about this

27

Source Port	Destination Port
Checksum	Length
ID number	Flags
Question count	Answer count
Authority count	Additional count
Question Records
Answer Records
Authority Records
Additional Records

UDP Payload

UDP Header

Computer Science 161

28 of 90

DNS Packet Format: DNS Header

ID number (16 bits): Used to associate queries with responses

Client picks an ID number in the query
Name server uses the same ID number in the response
Should be random for security, as we’ll see later

Counts: The number of records of each type in the DNS payload

28

Source Port	Destination Port
Checksum	Length
ID number	Flags
Question count	Answer count
Authority count	Additional count
Question Records
Answer Records
Authority Records
Additional Records

DNS Payload

UDP Header

DNS Header

Computer Science 161

29 of 90

DNS Packet Format: DNS Payload

The DNS payload contains a variable number of resource records (RRs)
Each RR is a name-value pair
RRs are sorted into four sections

Question section
Answer section
Authority section
Additional section

29

Source Port	Destination Port
Checksum	Length
ID number	Flags
Question count	Answer count
Authority count	Additional count
Question Records
Answer Records
Authority Records
Additional Records

DNS Payload

UDP Header

DNS Header

Computer Science 161

30 of 90

DNS Record Format

Each record is a name-value pair with a type

A (answer) type records: Maps a domain name to an IPv4 address
NS (name server) type records: Designates another DNS server to handle a domain
Other types exist, but these are the two you need to know for now

Each record also contains some metadata

Time to live (TTL): How long the record can be cached
Other metadata fields exist, but you don’t need to worry about them

30

Computer Science 161

31 of 90

DNS Record Types

Other record types you might encounter:

AAAA type record: Maps a domain name to an IPv6 address
CNAME type record: Maps one domain name to another domain name. Used for aliases.
MX type record: Used for mail servers
SOA: Contains information about the operator/administrator of a zone
Other types for text records, cryptographic information, etc. exist too
You don’t need to know about any of these

31

Computer Science 161

32 of 90

DNS Record Sections

Question section: What is being asked

Included in both requests and responses
Usually an A type record with the domain being looked up

Answer section: A direct response to the question

Empty in requests
Used if the name server responds with the answer
Usually an A type record with the IP address of the domain being looked up

32

Computer Science 161

33 of 90

DNS Record Sections

Authority section: A delegation of authority for the question

Empty in requests
Used to direct the resolver to the next name server
Usually an NS type record with the zone and domain of the child name server

Additional section: Additional information to help with the response, sometimes called glue records

Empty in requests
Provides helpful, non-authoritative records for domains
Usually an A type record with the domain and IP address of the child name server (since the NS record provides the child name server as a domain)

33

Computer Science 161

34 of 90

DNS Record Caching

For performance, resolvers cache as many records as possible

Records returned by name servers are cached until their time-to-live expires
No DNS requests need to be sent if answer can be found in the cache
Makes response time faster for clients
Reduces load on name servers

34

Computer Science 161

35 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

35

You can try this at home! Use the dig utility in your terminal, and remember to set the +norecurse flag so you can traverse the name server hierarchy yourself.

Computer Science 161

36 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

36

We are performing a DNS lookup for the IP address of eecs.berkeley.edu.

Computer Science 161

37 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

37

DNS queries always start with a request to the root name server. The IP address of the root name server is usually hard-coded into recursive resolvers.

Computer Science 161

38 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

38

Here’s the DNS response from the root name server.

Computer Science 161

39 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

39

Here’s the DNS header.

Computer Science 161

40 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

40

Here’s the 16-bit ID number in the DNS header.

Computer Science 161

41 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

41

Here are the flags in the DNS header.

Here are the record counts in the DNS header.

Computer Science 161

42 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

42

Here’s the DNS payload. It’s a collection of resource records (one per line), sorted into four sections.

Computer Science 161

43 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

43

Here’s the question section. The name is eecs.berkeley.edu, the type is A, and the value is blank. It shows that we are looking for the IP address of eecs.berkeley.edu.

Computer Science 161

44 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

44

The answer section is blank, because the root name server did not return the answer we’re looking for.

We can confirm this by checking the header, which says there are 0 records in the answer section.

Computer Science 161

45 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

45

The authority and additional sections tell the resolver where to look next.

Note that there are multiple .edu name servers for redundancy.

Computer Science 161

Remember in our lookups before we said “I don’t know, but my friend there the .edu server can help you better”. Here’s the packet version of that!

At a high level, to find out how to get to the next name server that can help us, we need to know three things:

Human-readable domain name of that name server (a.edu-servers.net)
What zone the name server is responsible for (.edu)
That name server’s IP address (192.5.6.30)
Imperfect analogy: In an address book, if you don’t know someone: you’ll mark down their name (domain name), their address (IP address), and who they know (what that server is the name server for) so you can get to that final person!

Everything’s a name-value pair, so how are we going to get 3 values? Write two records that repeat one value twice (the domain name of the name server)

All these domain name to IP value mappings are cached! Any later .edu request can now go directly to a .edu name server (any of the three) without needing to go through the root!

46 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

46

For redundancy, there are usually several name servers for each zone. Any of them will usually work. Let’s pick the first one.

This NS record says that a.edu-servers.net is a .edu name server.

Computer Science 161

47 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26114

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

edu. 172800 IN NS a.edu-servers.net.

edu. 172800 IN NS b.edu-servers.net.

edu. 172800 IN NS c.edu-servers.net.

...

;; ADDITIONAL SECTION:

a.edu-servers.net. 172800 IN A 192.5.6.30

b.edu-servers.net. 172800 IN A 192.33.14.30

c.edu-servers.net. 172800 IN A 192.26.92.30

...

47

This A record helpfully tells us the IP address of the next name server we mean to contact.

Computer Science 161

Second record: A record

We’ve gotten two pieces of information already–what zone the name server is responsible for and what the human-readable domain name of that name server was. We need to know the IP address
Luckily, we already have a record type that can give us the IP address attached to a domain name (used in the Question and Answer section)
What do A records store as a name-value pair? (Name: domain name (a.edu-servers.net), Value: IP address (192.5.6.30))

Given this information, we know that the root is telling us “I don’t know what the IP address of eecs.berkeley.edu is, but I can tell you 3 things that will guide you towards a person who will have a better answer”

Their domain name is a.edu-servers.net, and as a name server, their zone is .edu–they’re an expect for .edu!
Their IP address is 192.5.6.30 (so contact them there!)

What happens if we only gave an NS record (and no A record)? Well, we’d have to go through the DNS query over again just for that name server (walkthrough)!

So, now that we know their IP address, let’s ask them next!

48 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @192.5.6.30

48

Next, we query the .edu name server. We know the IP address of the .edu name server because the root name server gave the information to us.

Computer Science 161

49 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @192.5.6.30

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36257

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; AUTHORITY SECTION:

berkeley.edu. 172800 IN NS adns1.berkeley.edu.

berkeley.edu. 172800 IN NS adns2.berkeley.edu.

berkeley.edu. 172800 IN NS adns3.berkeley.edu.

;; ADDITIONAL SECTION:

adns1.berkeley.edu. 172800 IN A 128.32.136.3

adns2.berkeley.edu. 172800 IN A 128.32.136.14

adns3.berkeley.edu. 172800 IN A 192.107.102.142

...

49

The answer section is blank again. The authority and additional section tell us to query a berkeley.edu name server, and provide us with the IP address of the next name server.

Computer Science 161

50 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

50

Next, we query the berkeley.edu name server for the IP address of eecs.berkeley.edu. We know the IP address of the berkeley.edu name server because the root name server gave the information to us.

Computer Science 161

51 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52788

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1

51

The answer section has one A type record. It tells us that the IP address of eecs.berkeley.edu is 23.185.0.1.

Computer Science 161

52 of 90

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52788

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1

52

Here’s the time-to-live (TTL) field in the record. It tells us that we can cache this answer for 86,400 seconds (24 hours).

Computer Science 161

53 of 90

DNS Lookup Walkthrough: su24.cs161.org

53

Takeaway: You can query common recursive resolvers instead of the root directly!�8.8.8.8 a public DNS recursive resolver operated by Google.

Computer Science 161

54 of 90

DNS Security

54

Computer Science 161

55 of 90

Cache Poisoning Attacks

Cache poisoning attack: Returning a malicious record to the client

The victim will cache the malicious records, “poisoning” it

Example: Supply a malicious A record mapping a legitimate domain to the attacker’s IP address

Now when the victim visits eecs.berkeley.edu, they’ll actually be sending packets to the attacker (6.6.6.6), who can act as a MITM!

55

Computer Science 161

56 of 90

Security Risk: Malicious Name Servers

Malicious name servers can lie and supply a malicious answer
Malicious records could also poison the cache with other records

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52788

;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:

;eecs.berkeley.edu. IN A

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1

;; ADDITIONAL SECTION:

www.google.com. 172800 IN A 6.6.6.6

56

We made a query to a malicious berkeley.edu name server...

...and it returned a malicious record for www.google.com!

Computer Science 161

An attacker can hack a name server… uh oh! Here’s an attacker in our threat model

Other people send them requests and malicious name servers can lie
The interesting thing is in a request for the IP address for eecs.berkeley.edu, the malicious name server can give the right or wrong answer, but something else they can do is provide answers records to other domains

Those requests would be cached
If the attacker’s IP is 6.6.6.6, they’ve now become a MITM for any requests sent to www.google.com

The malicious name server can poison whatever it wants, but doesn’t this look weird? If this is the response we get for eecs.berkeley.edu, why does it contain a www.google.com answer?

Sus -> we should do something about that! berkeley.edu name server shouldn’t be able to provide an answer for www.google.com (since it’s not in its zone!)

57 of 90

Defense: Bailiwick Checking

Idea: Limit the amount of damage a malicious name server can do
Bailiwick checking: the resolver only accepts records if they are in the name server’s zone

Bailiwick: “one’s sphere of operations or particular area of interest”
Example: The berkeley.edu name server can provide a record for eecs.berkeley.edu, but not mit.edu
Example: The .edu name server can provide a record for mit.edu and berkeley.edu, but not google.com
Example: The root name server can provide a record for any domain (everything is in bailiwick for the root)

57

Computer Science 161

58 of 90

Security Risk: Man-in-the-middle (MITM) Attackers

DNS is not secure against MITM attackers
MITM attackers can poison the cache by adding, removing, or changing any record in the DNS response

58

;; ANSWER SECTION:

eecs.berkeley.edu. 86400 IN A 23.185.0.1 6.6.6.6

Computer Science 161

59 of 90

Security Risk: On-Path Attackers

DNS is not secure against on-path attackers
On-path attackers can poison the cache by sending a spoofed response

If the spoofed response arrives before the legitimate response, the victim will cache the attacker’s malicious records
The on-path attacker can see every field in the unencrypted DNS request. Nothing to guess!

59

Recursive Resolver

berkeley.edu name server

Attacker

From: Port 1234

To: Port 80

ID	Flags
Counts
Records

(Unencrypted) ID

Layer 4: UDP

Computer Science 161

60 of 90

Security Risk: Off-Path Attackers

The off-path attacker needs to guess the ID field to spoof a response

If the ID in the response doesn’t match the ID in the request, the resolver won’t accept the response

If the ID number is randomly generated:

Probability of guessing correctly = 1/2¹⁶, since the ID number is 16 bits long
Requires approximately 65,000 tries to successfully send a spoofed packet
This is feasible for a patient attacker

60

Source Port	Destination Port
Checksum	Length
ID number	Flags
Question count	Answer count
Authority count	Additional count
Question Records
Answer Records
Authority Records
Additional Records

DNS Payload

UDP Header

DNS Header

Computer Science 161

61 of 90

Security Risk: Off-Path Attackers

What if the ID field is incremented by 1 for every request?
Off-path attacker can spoof a packet as follows:

Trick the victim into visiting the attacker’s website
Include this HTML on the attacker’s website: <img src="http://www.attacker.com">
The victim’s browser will make a DNS query for www.attacker.com
If the attacker controls the attacker.com DNS name server, they can see the request and learn the ID field
Include this HTML on the attacker’s website: <img src="http://www.google.com">
The victim’s browser will make a DNS query for www.google.com
The attacker knows the ID is 1 more than the previous ID, so they can spoof a response!

ID numbers need to be random in DNS requests

61

Computer Science 161

62 of 90

Kaminsky Attack

Notice: If the attacker places <img src="http://www.google.com"> multiple times on their website, the browser will only make 1 DNS query

The browser caches address of www.google.com
The attacker only gets one try

Dan Kaminsky, security researcher, noticed that DNS clients would cache additional glue records as if they were authoritative answers, even though they aren’t

62

Computer Science 161

1 hr - 1:40

You can change the race condition: you can now try as many times as you want without being locked out.

A core problem is that if you lose the race condition, you have to wait for that cached response to expire

We’re kind of screwed against in-path and on-path attackers right now (come back when we talk about DNSSEC to fix that)
Off-path attacker needs to win the race condition and to guess the ID number correctly in order to poison the cache.

What happens if the off-path attacker loses?

They guess the ID wrong or they lose the race condition
In both cases, the attacker’s response is rejected and the real answer is accepted and cached

This means the recursive resolver, until the record expires, will not even attempt a DNS query, it’ll just look in the cache and find its answer

No racing anymore until you have to race -> it’s like an extremely harsh timeout (this is why people were comfortable with small numbers like 2^16 and 2^32)

63 of 90

Kaminsky Attack

Now, the attacker can gain more tries at once:

The attacker includes

<img src="http://fake1.google.com">
<img src="http://fake2.google.com">
<img src="http://fake3.google.com">
<img src="http://fake4.google.com">

For each, the client makes a request for the domain name
The attacker’s spoofed response contains:

Authority: fake1.google.com. 172800 IN NS www.google.com.
Additional: www.google.com. 172800 IN A 6.6.6.6

The client now caches the record for www.google.com, and the cache is poisoned!

63

Computer Science 161

Well, that’s true for actual domains right? But what if we used fake domains?

Instead of racing by querying for real domains, let’s use fake ones! Okay, so what’s the legit answer: it would be “This answer doesn’t exist”. We’ll talk about how to formally show that in DNSSEC.

Off-path attacker race:

If you lose (either because you guessed the ID wrong or you lost the race): the actual domain that you want to poison (www.google.com) is still up for grabs!

It’ll just say “fake1.google.com does not exist as a domain”. Could get cached, could not -> try again with fake2.google.com!

Fake2 isn’t cached, so another DNS query will have to be made: another chance where you can race!

No longer have to wait! We can just spam these fake domains and it’s fine if you lose one or two–you just keep going!

If you win: you have successfully poisoned the cache

You can spoof a response and poison other domains in the cache!
This additional section will be cached since all records are cached!
Bailiwick checking doesn’t stop this either because the google.com name server can provide IPs for both fake1.google.com and www.google.com

Even if we cache the google.com name server (not the same thing as www.google.com), we can race against them -> remember google.com NS is in charge of responding to DNS queries within their zone, including for the domain www.google.com.

This makes 65000 go from “eh, that’s good enough” to “that is definitely not enough”.

64 of 90

Kaminsky Attack: Example

Mallory includes the following image tags on their website

<img src="http://fake1.google.com">
<img src="http://fake2.google.com">
<img src="http://fake3.google.com">
<img src="http://fake4.google.com">
… and so on

Alice loads Mallory’s website
Alice’s browser makes a DNS request for fake1.google.com

We’ll show you an example of what happens during this step

Alice’s browser makes a DNS request for fake2.google.com
… And so on. Alice’s browser continues to make DNS requests for each tag on the website

64

Computer Science 161

65 of 90

Kaminsky Attack: Example

65

. (root)

.com

google.com

Stub Resolver

Let's walk through the DNS query for the IP address of fake1.google.com.

Recursive Resolver

Recursive Resolver Cache

We’ll use this color to represent normal packets across Alice’s DNS query.

We’ll use this color to represent Mallory’s packets across Alice’s DNS query.

Computer Science 161

66 of 90

Kaminsky Attack: Example

66

Stub Resolver

Recursive Resolver

Recursive Resolver Cache

1

“Can you figure out what the ip address of fake1.google.com is?”

. (root)

.com

google.com

Computer Science 161

67 of 90

Kaminsky Attack: Example

67

Stub Resolver

Recursive Resolver

Recursive Resolver Cache

1

“What is the IP address of fake1.google.com? This request has ID 161.”

. (root)

.com

google.com

2

Computer Science 161

68 of 90

Kaminsky Attack: Example

68

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30

“I don’t know, but I have delegated authority to the .com name server. This response has ID 161.

Authority: .com NS a.gtld-servers.net.

Additional: a.gtld-servers.net. A 192.5.6.30”

2

. (root)

.com

google.com

3

The .com name server a.gtld-servers.net. is cached with IP 192.5.6.30.

1

Computer Science 161

69 of 90

Kaminsky Attack: Example

69

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30

“What is the IP address of fake1.google.com? This request has ID 972.”

4

. (root)

.com

google.com

3

1

2

Computer Science 161

70 of 90

Kaminsky Attack: Example

70

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10

5

“I don’t know. But I have delegated authority to the google.com name server. This response has ID 972.

Authority: google.com NS ns1.google.com

Additional: ns1.google.com. A 216.329.32.10”

4

. (root)

.com

google.com

The google.com name server ns1.google.com. is cached with IP 216.239.32.10.

1

2

3

Computer Science 161

71 of 90

Kaminsky Attack: Example

71

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10

5

. (root)

.com

google.com

“What is the IP address of fake1.google.com? This request has ID 774.”

6

1

2

3

4

Computer Science 161

72 of 90

Kaminsky Attack: Example

72

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10

. (root)

.com

google.com

6

7

1

2

3

Let’s see what happens when Mallory correctly guesses the ID number and wins the race condition.

4

5

“fake1.google.com doesn’t exist! This response has ID 774.”

“I don’t know. But I have delegated authority to the fake1.google.com. NS. This response has ID 774.

Authority: fake1.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

Computer Science 161

73 of 90

Kaminsky Attack: Example

73

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
www.google.com.	6.6.6.6

. (root)

.com

google.com

7

Mallory correctly guessed the ID number and won the race condition, so www.google.com. is cached with Mallory’s malicious IP 6.6.6.6.

1

2

3

4

5

6

“I don’t know. But I have delegated authority to the fake1.google.com. NS. This response has ID 774.

Authority: fake1.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

Computer Science 161

74 of 90

Kaminsky Attack: Example

74

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
www.google.com.	6.6.6.6

. (root)

.com

google.com

7

1

2

3

We don’t really care what next steps are involved in this request, as we have already poisoned the cache.

4

5

6

Computer Science 161

75 of 90

Kaminsky Attack: Example

75

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10

. (root)

.com

google.com

7

1

2

What if Mallory didn’t guess the ID number correctly?

3

4

5

6

“I don’t know. But I have delegated authority to the fake1.google.com. NS. This response has ID 129.

Authority: fake1.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

“fake1.google.com doesn’t exist! This response has ID 774.”

Computer Science 161

76 of 90

Kaminsky Attack: Example

76

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10

. (root)

.com

google.com

7

The recursive resolver discards the response packet from Mallory, because the ID does not match the ID from the request.

1

2

What if Mallory didn’t guess the ID number correctly?

3

4

5

6

“I don’t know. But I have delegated authority to the fake1.google.com. NS. This response has ID 129.

Authority: fake1.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

Computer Science 161

77 of 90

Kaminsky Attack: Example

77

Stub Resolver

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
fake1.google.com	Doesn’t exist!

. (root)

.com

google.com

7

“fake1.google.com doesn’t exist! This response has ID 774.”

What can Mallory do to still poison the cache?

1

2

What if Mallory didn’t guess the ID number correctly?

3

4

5

6

Computer Science 161

78 of 90

Kaminsky Attack: Example

78

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
fake1.google.com	Doesn’t exist!
…	Doesn’t exist!
fake26.google.com	Doesn’t exist!

google.com

“fake7.google.com doesn’t exist! This response has ID 432.”

“fake3.google.com doesn’t exist! This response has ID 324.”

Mallory can use the DNS requests from her other image tags to try to guess the ID number.

“fake4.google.com doesn’t exist! This response has ID 691.”

“I don’t know. But I have delegated authority to the fake7.google.com. NS. This response has ID 774.

Authority: fake7.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

“I don’t know. But I have delegated authority to the fake3.google.com. NS. This response has ID 425.

Authority: fake2.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

“I don’t know. But I have delegated authority to the fake4.google.com. NS. This response has ID 712.

Authority: fake4.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

“I don’t know. But I have delegated authority to the fake5.google.com. NS. This response has ID 821.

Authority: fake5.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

“I don’t know. But I have delegated authority to the fake6.google.com. NS. This response has ID 234.

Authority: fake6.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

“fake6.google.com doesn’t exist! This response has ID 629.”

“fake6.google.com doesn’t exist! This response has ID 427.”

“fake27.google.com doesn’t exist! This response has ID 161.”

“I don’t know. But I have delegated authority to the fake27.google.com. NS. This response has ID 161.

Authority: fake27.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

Computer Science 161

79 of 90

Kaminsky Attack: Example

79

Recursive Resolver

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
fake1.google.com	Doesn’t exist!
…	Doesn’t exist!
fake26.google.com	Doesn’t exist!
www.google.com.	6.6.6.6

If Mallory wins the race condition and guesses the correct ID during any one of these DNS queries, Mallory’s IP will be cached.

“I don’t know. But I have delegated authority to the fake27.google.com. NS. This response has ID 161.

Authority: fake27.google.com. NS www.google.com

Additional: www.google.com. A 6.6.6.6”

Computer Science 161

80 of 90

Kaminsky Attack: Example

80

Stub Resolver

Recursive Resolver

. (root)

.com

google.com

Now that the cache is poisoned, what happens when Alice wants to know the ip address of www.google.com?

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
www.google.com.	6.6.6.6

Computer Science 161

81 of 90

Kaminsky Attack: Example

81

Stub Resolver

Recursive Resolver

1

. (root)

.com

google.com

“Can you figure out what the ip address of www.google.com is?”

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
www.google.com.	6.6.6.6

Computer Science 161

82 of 90

Kaminsky Attack: Example

82

Stub Resolver

Recursive Resolver

. (root)

.com

google.com

2

“My cache says the ip address of www.google.com is 6.6.6.6.”

Recursive Resolver Cache
a.gtld-servers.net.	192.5.6.30
ns1.google.com.	216.239.32.10
www.google.com.	6.6.6.6

Mallory will receive all traffic Alice meant to send to www.google.com!

1

Computer Science 161

83 of 90

Pre-Kaminsky Attack: Response Possibilities

83

	Attacker correctly guesses the ID number	Attacker does not correctly guess the ID number
Attacker beats the race condition against the legitimate NS	The recursive resolver caches a mapping from a legitimate domain name to the attacker’s IP address.	Failure. The recursive resolver caches the actual responses and we have to wait until the record expires to try again.
Attacker does not beat the race condition against the legitimate NS	Failure. The recursive resolver caches the actual responses and we have to wait until the record expires to try again.	Failure. The recursive resolver caches the actual responses and we have to wait until the record expires to try again.

Computer Science 161

84 of 90

Kaminsky Attack: Response Possibilities

84

	Attacker correctly guesses the ID number	Attacker does not correctly guess the ID number
Attacker beats the race condition against the legitimate NS	The recursive resolver caches a mapping from legitimate domain names to the attacker’s desired IP addresses.	The recursive resolver ignores the response because the ID does not match the request sent earlier. The recursive resolver caches something saying “This domain does not exist”. Try again with another fake domain!
Attacker does not beat the race condition against the legitimate NS	The recursive resolver caches something saying “This domain does not exist”. Try again with another fake domain!	The recursive resolver caches something saying “This domain does not exist”. Try again with another fake domain!

Computer Science 161

85 of 90

Defense: Source Port Randomization

Randomize the source port of the DNS query

The attacker must guess the destination port of the response in addition to the query ID
This adds 16 bits to guess, to total 2³² possibilities

Other ways to increase entropy:

Randomly capitalize the domain, since the question is copied in the response

85

Source Port	Destination Port
Checksum	Length
ID number	Flags
Question count	Answer count
Authority count	Additional count
Question Records
Answer Records
Authority Records
Additional Records

DNS Payload

UDP Header

DNS Header

Computer Science 161

86 of 90

Defense: Glue Validation

Don’t cache glue records as part of DNS lookups

They are necessary, since NS records are given in terms of domain names, not IP addresses
If you want to cache, you can perform a separate recursive DNS lookup to validate the glue record authoritatively

Issue: This was not implemented by all DNS software

Unbound, a major DNS implementation, implemented validation
BIND, the oldest and most common implementation, did not

Mainly for political reasons: They supported DNSSEC, which uses cryptography to validate DNS records (we’ll look at this next time)

86

Computer Science 161

87 of 90

Profiting from DNS Attacks

Suppose you take over a lot of home routers… How do you make money from your attack?
Change the DNS server settings

Each router is programmed with the IP address of the recursive resolver
Replace the IP address of the recursive resolver with the attacker’s IP address
Cache poisoning attacks are now possible!

Redirect all DNS requests for ads to an attacker-controlled domain and serve attacker-chosen ads to the victim

The attacker can now sell this advertising space!

TLS can defend against this, as it provides end-to-end security

87

Computer Science 161

88 of 90

DNS: Summary

DNS (Domain Name System): An Internet protocol for translating human-readable domain names to IP addresses

DNS name servers on the Internet provide answers to DNS queries
Name servers are arranged in a domain hierarchy tree
Lookups proceed down the domain tree: name servers will direct you down the tree until you receive an answer
The stub resolver tells the recursive resolver to perform the lookup

88

. (root)

.edu

.org

.com

google.com

piazza.com

cs161.org

mit.edu

berkeley.edu

Computer Science 161

89 of 90

DNS: Summary

DNS message structure

DNS uses UDP for efficiency
DNS packets include a random 16-bit ID field to match requests to responses
Data is encoded in records, which are name-value pairs with a type

A (answer) type records: Maps a domain name to an IPv4 address
NS (name server) type records: Designates another DNS server to handle a domain

Records are separated into four sections

Question: Contains query
Answer: Contains direct answer to query
Authority: Directs the resolver to the next name server
Additional: Provides extra information (e.g. the location of the next name server)

Resolvers cache as many records as possible (until their time-to-live expires)

89

Computer Science 161

90 of 90

DNS Security: Summary

Cache poisoning attack: Send a malicious record to the resolver, which caches the record

Causes packets to be sent to the wrong place (e.g., to the attacker, who becomes a MITM)

Risk: Malicious name servers

Defense: Bailiwick checking: Resolver only accepts records in the name server’s zone

Risk: Network attackers

MITM attackers can poison the cache without detection
On-path attackers can race the legitimate response to poison the cache
Off-path attackers must guess the ID field (Defense: Make the ID field random)

Kaminsky attack: Query non-existent domains and put the poisoned record in the additional section (which will still be cached). Lets the off-path attacker try repeatedly until succeeding
Defense: Source port randomization (more bits for the off-path attacker to guess)

90

Computer Science 161