1 of 72

1

CS 168, Spring 2026 @ UC Berkeley

Slides credit: Sylvia Ratnasamy, Rob Shakir, Peyrin Kao, Nicholas Ngai, Nicholas Weaver

DNS

Lecture 14 (Applications 1)

2 of 72

What is DNS For?

Lecture 14, CS 168, Spring 2026

DNS

  • What is DNS For?
  • Design
  • Implementation
  • Scaling
  • Other Uses

3 of 72

Application Layer

Lots of applications are built on the Internet infrastructure we've seen.

We'll focus on some common ones:

  • DNS (today).
  • HTTP (next time).

Physical

Data Link

Network

Transport

Application

7

4

3

2

1

(DNS, HTTP)

(TCP, UDP)

(IP)

(Ethernet)

(Optical fiber, copper)

4 of 72

Domain Names

Recall: Computers are addressed by IP address.

  • Example: 74.125.25.99.
  • Useful for machines: Helps making routing scalable.
  • Not useful for humans: Numbers not meaningful to humans. Hard to remember.

Alternative addressing system: 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.

5 of 72

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.

​

​

74.125.25.99

www.google.com

DNS

6 of 72

Brief History of DNS

On the Internet and ARPANET (its predecessor), three main applications.

Remote terminal (telnet 34.8.12.0):

  • Connect to someone else's machine remotely. SSH is a modern successor.

File transfer (ftp 74.1.254.1):

  • Copy files across the network.

Email (mail alice@88.1.24.0):

  • Send a message to another user.

​

Remembering the remote host address is difficult for humans.

7 of 72

Brief History of DNS

Original design: Computers had a hosts.txt file that mapped names to IP addresses.

  • Example: ucb-arpa maps to 10.0.0.78.
  • Using IP address: mail mosher@10.0.0.78.
  • Using hostname: mail mosher@ucb-arpa.

Originally maintained by Elizabeth Jocelyn "Jake" Feinler.

  • The file was photocopied and exchanged between users.

8 of 72

Brief History of DNS

Originally, hosts.txt was human-readable.

"I remembered that back then we simply xeroxed the hosts.txt file and put it into the Arpanet Directory, so I copied that." –Elizabeth Feiner

9 of 72

Brief History of DNS

Problems with hosts.txt:

  • Everyone needs to use the same file.
    • If you type mail mosher@ucb-arpa on different computers, you should be emailing the same person.
  • Users might have an outdated file.

It seems about time to put an end to the absurd situation where each site on the network must maintain a different, generally out-of-date, host list.

–RFC 606 (1973)

10 of 72

Brief History of DNS

First step: Make the file machine-readable.

  • Can use FTP to transfer the hosts.txt file between computers.

Scaling is still an issue as the Internet grew.

  • Could end up with a partial file if the download breaks halfway through.

Check out RFC608 and this 1983 hosts file.

NET : 44.0.0.0 : AMPRNET :

NET : 45.0.0.0 : C3-PR :

NET : 46.0.0.0 : UCB-ETHER :

NET : 47.0.0.0 : SAC-PR-TEMP :

​

HOST : 46.0.0.4 : UCBARPA : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,UDP :

HOST : 46.0.0.5 : UCBCAD : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,UDP :

HOST : 46.0.0.6 : UCBERNIE : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,UDP :

HOST : 46.0.0.7 : UCBMONET : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,UDP :

HOST : 46.0.0.9 : UCBESVAX : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,UDP :

HOST : 46.0.0.10 : UCBVAX : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,UDP :

11 of 72

Brief History of DNS

DNS was first proposed in RFC882 (1983).

We use this system (with some modifications – but not many) today.

There's a huge amount of DNS history here at UC Berkeley!

  • First DNS server written for Unix was BIND.
  • berkeley.edu is the oldest .edu domain!

The Berkeley Internet Name Domain Server

Douglas B. Terry, Mark Painter, David W. Riggle, Songnian Zhou (UC Berkeley)

1984

12 of 72

Goals of DNS

DNS must be scalable.

  • Many hosts/names. Many lookups. Many updates.

DNS must be highly available.

  • No single point of failure.

DNS must be lightweight and fast.

  • Connections often start with a name lookup (e.g. user typing domain in browser).
  • If DNS is slow, every connection is slow.

74.125.25.99

www.google.com

DNS

13 of 72

DNS Design

Lecture 14, CS 168, Spring 2026

DNS

  • What is DNS For?
  • Design
  • Implementation
  • Scaling
  • Other Uses

14 of 72

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: There's a name server with name a.edu-servers.net and IP 192.5.6.30.

DNS is a client-server, request-response protocol.

  • To perform a DNS lookup, you (the client) send a DNS query:�"What is the IP address of www.google.com?"
  • The name server sends a DNS response with the answer:�"The IP address of www.google.com is 74.125.25.99."

Issues:

  • One name server can't handle every DNS request from the entire Internet.
  • If there are many name servers, how do you know which one to contact?

15 of 72

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.

. (root)

.edu

.org

.com

google.com

piazza.com

cs161.org

mit.edu

berkeley.edu

16 of 72

DNS Name Server Hierarchy

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

. (root)

.edu

.org

.com

google.com

piazza.com

cs161.org

mit.edu

berkeley.edu

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

17 of 72

Steps of a DNS Lookup

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

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

18 of 72

Steps of a DNS Lookup

First, you check your cache to see if you already know the answer to your query.

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

Hmm, I don't remember previously seeing the IP address of eecs.berkeley.edu.

19 of 72

Steps of a DNS Lookup

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

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

1

"What is the IP address of eecs.berkeley.edu?"

20 of 72

Steps of a DNS Lookup

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

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

1

"I don't know, but I have delegated authority to the .edu name server."

2

21 of 72

Steps of a DNS Lookup

Next, you ask the same question, but now to the .edu name server.

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

1

2

3

"What is the IP address of eecs.berkeley.edu?"

22 of 72

Steps of a DNS Lookup

The .edu name server redirects you to the berkeley.edu name server.

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

1

2

3

4

"I don't know. But I have delegated authority to the berkeley.edu name server."

23 of 72

Steps of a DNS Lookup

Next, you ask the same question, but now to the berkeley.edu name server.

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

1

2

3

"What is the IP address of eecs.berkeley.edu?"

4

5

24 of 72

Steps of a DNS Lookup

The berkeley.edu name server responds with the answer.

You can cache the answer to avoid having to ask again later.

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

You

1

2

3

"The IP address of eecs.berkeley.edu is 23.185.0.1."

4

5

6

Store this in your cache for the next 24 hours so you don't bother me again with the same request.

25 of 72

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.

26 of 72

Steps of a DNS Lookup (With Recursive Resolver)

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

1

Recursive Resolver

The stub resolver sends the query to the recursive resolver.

27 of 72

Steps of a DNS Lookup (With Recursive Resolver)

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

Recursive Resolver

1

6

7

4

5

3

2

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

28 of 72

Steps of a DNS Lookup (With Recursive Resolver)

. (root)

.edu

.org

cs161.org

mit.edu

berkeley.edu

Stub Resolver

Recursive Resolver

1

8

6

7

4

5

3

2

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

29 of 72

Recursive Resolvers

How do we know where the recursive resolver is?

  • When you first join the network, somebody can tell you a resolver address.
  • You can use a well-known resolver with a memorable IP address.
    • 1.1.1.1 (operated by Cloudflare).
    • 8.8.8.8 (operated by Google).

Why are recursive resolvers useful?

  • The recursive resolver can build a larger cache from multiple users' requests.
    • If you query for www.google.com for the first time, the recursive resolver might have the answer cached from somebody else's query.
  • 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).

30 of 72

Recursive Resolver Failures

What happens if a resolver breaks?

  • Anyone relying on 1.1.1.1 to resolve DNS queries cannot access webpages.

Resolvers can be a single point of failure!

  • Yesterday, 1.1.1.1 stopped responding.
  • Maybe a BPG issue?

31 of 72

DNS Implementation

Lecture 14, CS 168, Spring 2026

DNS

  • What is DNS For?
  • Design
  • Implementation
  • Scaling
  • Other Uses

32 of 72

APIs for Developers

What does DNS look like from a developer perspective?

Relatively simple, common APIs that are available in almost all languages.

Example API in C:

  • result = gethostbyname("foo.com")
    • Limited to IPv4.
    • Deprecated, but still used.
  • error = getaddrinfo("example.com", NULL, NULL, &result)
    • Replaces the deprecated method.
    • Supports more than IPv4.

Functions usually just make requests to the OS's configured resolving DNS server.

  • All the complexities of DNS hidden from the end developer.

33 of 72

DNS Uses UDP

Recall UDP vs. TCP:

  • UDP: Unreliable, but faster.
  • TCP: Reliable, but slower.

DNS should be lightweight and fast, so it uses UDP.

  • No 3-way handshake needed.
  • No need for servers to maintain connection state.
  • Most queries/responses fit in a single UDP packet (no bytestream needed).

34 of 72

DNS Packet Format: UDP Header

Source port (16 bits): Chosen by the client.

Destination port (16 bits): Usually 53.

  • Servers typically listen for queries on a well-known UDP port (53).

Checksum on UDP payload.

Length of UDP payload.

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

35 of 72

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 randomly chosen for security purposes (not discussed further).

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

36 of 72

DNS Packet Format: DNS Header

Flags:

  • QR bit: 0 in queries, 1 in responses.
  • RD bit: 1 if we want the recursive resolver to do the lookup for us, and 0 otherwise.

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

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

37 of 72

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.

​

​

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

38 of 72

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.
  • AAAA type records: Maps a domain name to an IPv6 address.
  • NS (name server) type records: Designates another DNS server to handle a domain.
  • Other types exist, but these are the ones you need to know for now.

Each record also contains some metadata.

  • Time to live (TTL): How long the record can be cached.
  • Class: We'll ignore this. Basically always set to IN (Internet).

39 of 72

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.

40 of 72

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 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).

41 of 72

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

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.

42 of 72

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

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

43 of 72

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @198.41.0.4

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.

44 of 72

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

...

​

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

45 of 72

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

...

Here's the DNS header.

46 of 72

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

...

​

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

47 of 72

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

...

Here are the flags in the DNS header.

Here are the record counts in the DNS header.

48 of 72

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

...

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

49 of 72

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

...

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.

50 of 72

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

...

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.

51 of 72

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

...

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

​

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

52 of 72

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

...

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.

53 of 72

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

...

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

54 of 72

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @192.5.6.30

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.

55 of 72

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

...

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.

56 of 72

DNS Lookup Walkthrough

$ dig +norecurse eecs.berkeley.edu @128.32.136.3

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.

57 of 72

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

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

58 of 72

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

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).

We finished our original query!

Let's try a few other queries.

59 of 72

Scaling DNS

Lecture 14, CS 168, Spring 2026

DNS

  • What is DNS For?
  • Design
  • Implementation
  • Scaling
  • Other Uses

60 of 72

DNS Hierarchy

The DNS tree represents 3 forms of hierarchy.

Names are hierarchical. This is why our domain names are words separated by dots.

ischool

berkeley

math

eecs

rise

repo

pink

edu

. (root)

pink.ischool.berkeley.edu.

rise.eecs.berkeley.edu.

61 of 72

DNS Hierarchy

Authority is hierarchical. Each organization manages a zone, and can delegate parts of the zone to other organizations.

ischool

berkeley

math

eecs

rise

repo

pink

edu

. (root)

UC Berkeley owns the berkeley.edu zone.

UC Berkeley gives the eecs.berkeley.edu zone to the EECS department.

62 of 72

DNS Hierarchy

Infrastructure is hierarchical. Each name server only needs to know about a subset of domains.

ischool

berkeley

math

eecs

rise

repo

pink

edu

. (root)

I have to answer all berkeley.edu queries.

For eecs.berkeley.edu queries, I can redirect users to that name server.

63 of 72

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.

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

...

64 of 72

DNS Hierarchy

A zone corresponds to an administrative authority response for some part of the hierarchy.

  • A zone is authoritative for how names within that part of the hierarchy are controlled.
  • You can choose to delegate authority for part of the zone to somebody else.

​

Zones help DNS scale.

  • Different administrative authorities are responsible for different parts of the hierarchy.
  • Example: Educause (.edu zone operators) don't have to know about what's happening in the berkeley.edu zone (authority delegated to UC Berkeley).

65 of 72

Administrative Authorities

The DNS root is controlled by ICANN.

  • Internet Corporation for Assigned Names and Numbers.

. (root)

uk

org

edu

com

jp

fr

...

...

co

ac

google

amazon

66 of 72

Administrative Authorities

Top-level domains (TLDs) are the zones directly below root.

  • Historically, relatively few, based on purpose (organization, education, commercial, etc.), and country (UK, France, Japan, etc.).
  • More recently, many more weird ones (.travel, .pizza, etc.). Over 1500 TLDs today!

. (root)

uk

org

edu

com

jp

fr

...

...

co

ac

google

amazon

TLDs

67 of 72

Administrative Authorities

Second-level domains, third-level domains, etc. are below TLDs.

  • Each TLD can decide its own structure.
  • Example: The .uk zone delegated .co.uk (commercial) and .ac.uk (academic).

. (root)

uk

org

edu

com

jp

fr

...

...

co

ac

google

amazon

TLDs

Second-level domains

Third-level domains

68 of 72

Administrative Authorities

Users can lease specific domains from domain registries (e.g. Verisign).

  • If you want to host your website on example.com, you have to reserve the domain for a recurring (e.g. monthly) fee.
  • Then, the authoritative .com name servers add a record mapping example.com to your IP address.

Organizations (e.g. Google, Amazon) can operate their own zones, with their own name servers.

  • The organization has to tell its parent about its name server(s).
  • Then, the parent will redirect queries to the organization.

69 of 72

Zone Availability

Recall: Each zone has several name servers for redundancy.

Zones "must" have two authoritative name servers.

  • This ensures availability of that zone.

The name servers work in a primary/secondary model.

  • The primary name server manages and updates the actual records.
  • The secondary name server uses a read-only copy of the primary server's records.
  • The primary server periodically transfers its records to the secondary servers.
    • Transfer can be large! This is where DNS might use TCP instead of UDP.

"Must" = it's standard practice, and many registrars require it.

70 of 72

Root Zone Availability with Anycast

It would be really bad if the root servers were unavailable.

  • Someone with an empty cache would be unable to make any lookups.

Root servers use a trick called anycast to ensure high availability.

  • There are only 13 root-server domains (a.root-servers.net to m.root-servers.net).
  • But, there are actually thousands of root servers.

Anycast: Use the same IP address for many servers on the Internet.

  • Thousands of servers all claim to be k.root-servers.net with address 193.0.14.129 in routing protocols.
  • You might hear advertisements from many different servers. You can pick any route (e.g. the shortest one), and you'll reach one of the root servers.

​

Anycast can also be used for other highly-available services (e.g. the 8.8.8.8 resolver).

71 of 72

Root Zone Availability with Anycast

All of these servers are advertising themselves as k.root-servers.net, with IP 193.0.14.129.

Lots of cooperation between network operators to keep root servers highly available.

72 of 72

Summary: DNS

  • DNS was created to allow for name to IP address resolution.
    • Helps humans easily access things on the Internet.
  • DNS is a hierarchical system.
    • Zones and name servers have a hierarchy.
    • Allows for delegation to authoritative entities.
  • DNS is implemented over UDP, and organizes data in records of various types.
  • DNS extends beyond address resolution into service resolution (e.g. email).
  • DNS can be used for load-balancing.