CS473: Lecture 8

Network Attacks - IP/TCP

Spring 2024

Mobin Javed

Slides adapted from Vern Paxson’s CS161 at UC Berkeley

 Recap

• Lower Layer Threats

• Eavesdropping

• WPA-2 Protection against eavesdropping

• DHCP-Spoo ng threats
fi
 Lesson Plan
• IP Layer Threats

• TCP Layer Threats

• Connection Termination

• Connection Hijacking

• Connection Spoo ng

• DNS Background (Time Permitting)

fi
Layer 3 Threats
 Layer 3’s View of the World
7 Application Bridges multiple “subnets” to
provide end-to-end internet
4 Transport
connectivity between nodes
3 (Inter)Network
4-bit 8-bit
2 Link 4-bit
Version Header Type of Service 16-bit Total Length (Bytes)
Length (TOS)

1 Physical 3-bit
16-bit Identification Flags 13-bit Fragment Offset

8-bit Time to
Live (TTL) 8-bit Protocol 16-bit Header Checksum

32-bit Source IP Address

32-bit Destination IP Address

IP = Internet Protocol
Payload
 Network-Layer (IP) Threats

• Can set arbitrary IP source address

– “Spoofing” - receiver has no idea who attacker is
– Could be blind, or could be coupled w/ sniffing
– Note: many attacks require two-way communication
o So successful off-path/blind spoofing might not suffice

• Can set arbitrary destination address

– Enables “scanning” - brute force searching for hosts
• Can send like crazy (flooding)
– IP has no general mechanism for tracking overuse
– IP has no general mechanism for tracking consent
– Very hard to tell where a spoofed flood comes from!
The Transport Layer:
TCP
“Best Effort” is Lame! What to do?
• It’s the job of our Transport (layer 4) protocols to build
data delivery services that our apps need out of IP’s
modest layer-3 service
Layer 4: Transport Layer
End-to-end communication
between processes

7 Application Different services provided:

4 Transport TCP = reliable byte stream
UDP = unreliable datagrams
3 (Inter)Network
2 (Datagram = single packet message)
Link

1 Physical
“Best Effort” is Lame! What to do?
• It’s the job of our Transport (layer 4) protocols to build
data delivery services that our apps need out of IP’s
modest layer-3 service
• #1 workhorse: TCP (Transmission Control Protocol)
• Service provided by TCP:
– Connection oriented (explicit set-up / tear-down)
o End hosts (processes) can have multiple concurrent long-lived
communication
– Reliable, in-order, byte-stream delivery
o Robust detection & retransmission of lost data
TCP “Bytestream” Service

Process A on host H1
Byte 0
Byte 1
Byte 2
Byte 3

Byte 80

Processes don’t ever see packet boundaries,

lost or corrupted packets, retransmissions, etc.

Process B
on host H2
Byte 0
Byte 1
Byte 2
Byte 3

Byte 80
Bidirectional communication:

Process B on host H2
Byte 0
Byte 1
Byte 2
Byte 3

Byte 73

There are two separate bytestreams, one in

each direction

Process A
on host H1
Byte 0
Byte 1
Byte 2
Byte 3

Byte 73
 (Link Layer Header)
TCP Header
(IP Header)
Ports are
associated Source port Destination port
with OS
processes Sequence number
Acknowledgment
HdrLen 0 Flags Advertised window

Checksum Urgent pointer

Options (variable)

Data …
 What combination of header elds
uniquely identi es a (bi-directional) TCP
connection?

IP source & destination addresses

+
TCP source and destination ports
fi
fi
 4. Connect to google.com server

The R
gateway

216.97.19.132

router
the In
resolver

Suppose our browser used port 23144 for our

connection, and Google’s server used 443.
172.217.6.78
Then our connection will be fully specified by the single
tuple <216.97.19.132, 23144, 172.217.6.78, 443>
TCP Header

Starting Source port Destination port

sequence
number (byte Sequence number
offset) of data Acknowledgment
carried in this
“segment” HdrLen 0 Flags Advertised window

Checksum Urgent pointer

Options (variable)

Data …
TCP Header

Starting Source port Destination port

sequence
number (byte Sequence number
offset) of data Acknowledgment
carried in this
“segment” HdrLen 0 Flags Advertised window

Checksum Urgent pointer

Byte streams
numbered Options (variable)
independently in
each direction
Data …
TCP Header

Starting Source port Destination port

sequence
number (byte Sequence number
offset) of data Acknowledgment
carried in this
“segment” HdrLen 0 Flags Advertised window

Checksum Urgent pointer

Byte streams
numbered Options (variable)
independently in
each direction
Data …
Sequence number assigned to start of
byte stream is picked when connection
begins; doesn’t start at 0
TCP Header

Source port Destination port

Acknowledgment gives Sequence number

seq # just beyond
Acknowledgment
highest seq. received
in order. HdrLen 0 Flags Advertised window

If sender successfully Checksum Urgent pointer

sends N bytestream
bytes starting at seq S Options (variable)
then “ack” for that will
be S+N.
Data …
Sequence Numbers
Host A
ISN (initial sequence number)

Sequence number TCP

TCP Data ACK sequence
HDR
from A = 1st byte number from B =
of data next expected
byte
TCP
TCP Data
HDR

Host B
TCP Header

Source port Destination port

Uses include: Sequence number

Acknowledgment
acknowledging
data (“ACK”) HdrLen 0 Flags Advertised window

setting up (“SYN”) Checksum Urgent pointer

and closing
connections (“FIN” Options (variable)
and “RST”)
Data …
Establishing a TCP Connection
A B

• Three-way handshake to establish connection

Establishing a TCP Connection
A B
Each host tells its Initial
Sequence Number
(ISN) to the other host.

(Spec says to pick based on

a clock)

• Three-way handshake to establish connection

Establishing a TCP Connection
A B
SYN
Each host tells its Initial
Sequence Number
(ISN) to the other host.

(Spec says to pick based on

a clock)

• Three-way handshake to establish connection

– Host A sends a SYN (open; “synchronize sequence
numbers”) to host B
Establishing a TCP Connection
A B
SYN
Each host tells its Initial
CK
Sequence Number
SYN+A
(ISN) to the other host.

(Spec says to pick based on

a clock)

• Three-way handshake to establish connection

– Host A sends a SYN (open; “synchronize sequence
numbers”) to host B
– Host B returns a SYN acknowledgment (SYN+ACK)
Establishing a TCP Connection
A B
SYN
Each host tells its Initial
CK
Sequence Number
SYN+A
(ISN) to the other host.
ACK
(Spec says to pick based on
a clock)

• Three-way handshake to establish connection

– Host A sends a SYN (open; “synchronize sequence
numbers”) to host B
– Host B returns a SYN acknowledgment (SYN+ACK)
– Host A sends an ACK to acknowledge the SYN+ACK
Establishing a TCP Connection
A B
SYN
Each host tells its Initial
CK
Sequence Number
SYN+A
(ISN) to the other host.
ACK
(Spec says to pick based on
Data a clock)
Data

• Three-way handshake to establish connection

– Host A sends a SYN (open; “synchronize sequence
numbers”) to host B
– Host B returns a SYN acknowledgment (SYN+ACK)
– Host A sends an ACK to acknowledge the SYN+ACK
Timing Diagram: 3-Way Handshaking
Passive
Different starting Open
Active initial sequence
Open numbers (ISNs) in Server
each direction
Client (initiator) listen()

connect() SYN, Seq

Num = x

y, A ck = x+1
um =
SYN + ACK, SeqN

A C K , Se q
Num = x
+ 1, Ack
=y+1
accept()
TCP Conn. Setup & Data Exchange
Client (initiator) Server
IP address 1.2.1.2, port 3344 IP address 9.8.7.6, port 80
SrcA=1.2.1
DstA=9.8.7 .2, SrcP=33
.6, DstP=80 44,
, SYN, Seq
=x

, SrcP=80,
SrcA=9.8.7.6 K , S e q = y, Ack = x+1
AC
.2 .1 .2 , D s tP =3344, SYN+
DstA =1

SrcA=1.2.1
DstA=9.8.7 .2, SrcP=33
.6, DstP=80 44,
, ACK, Ack
= y+1
SrcA=1.2.1
.2, SrcP=33
ACK, Seq= 44, DstA=9
x +1 , A c k = .8.7.6, DstP
y+1, Data= =
“GET /login 80,
.html

4,
D s tA = 1 .2 .1 .2, DstP=334 ”
.6 , SrcP=80 , … <html> …
S rc A = 9 .8 .7 = “ 2 0 0 O K
Data
S e q = y + 1 , Ack = x+16,
A CK,
 TCP Threat: Disruption

• Normally, TCP finishes (“closes”) a connection by

each side sending a FIN control message
– Reliably delivered, since other side must ack
• But: if a TCP endpoint finds unable to continue
(process dies; info from other “peer” is inconsistent),
it abruptly terminates by sending a RST control
message
– Unilateral
– Takes effect immediately (no ack needed)
– Only accepted by peer if has correct* sequence number
Abrupt Termination
X
B

SYN A

ACK

RST
ACK
SYN

Data
CK

A
time

• A sends a TCP packet with RESET (RST) flag to B

– E.g., because app. process on A crashed
– (Could instead be that B sends a RST to A)
• Assuming that the sequence numbers in the RST fit with what B expects,
That’s It:
– B’s user-level process receives: ECONNRESET
– No further communication on connection is possible
 TCP Threat: Disruption

• Normally, TCP finishes (“closes”) a connection by

each side sending a FIN control message
– Reliably delivered, since other side must ack
• But: if a TCP endpoint finds unable to continue
(process dies; info from other “peer” is inconsistent),
it abruptly terminates by sending a RST control
message
– Unilateral
– Takes effect immediately (no ack needed)
– Only accepted by peer if has correct* sequence number
• So: if attacker knows ports & sequence numbers,
can disrupt any TCP connection
TCP RST Injection
Client (initiator) Server
IP address 1.2.1.2, port 3344 IP address 9.8.7.6, port 80

...
SrcA=1.2.1
.2, SrcP=33
ACK, Seq= 44, DstA=9
x +1 , A c k = .8.7.6, DstP
y+1, Data= =
“GET /login 80,
.html

Attacker
IP address 6.6.6.6, port N/A
SrcA=9.8.7.6, SrcP=80,
DstA=1.2.1.2, DstP=3344, Spoofed
RST, Seq = y+1, Ack = x+16

Client
dutifully
removes
connection
TCP RST Injection
Client (initiator) Server
IP address 1.2.1.2, port 3344 IP address 9.8.7.6, port 80

...
SrcA=1.2.1
.2, SrcP=33
ACK, Seq= 44, DstA=9
x +1 , A c k = .8.7.6, DstP
y+1, Data= =
“GET /login 80,
.html

Attacker
IP address 6.6.6.6, port N/A
SrcA=9.8.7.6, SrcP=80,
DstA=1.2.1.2, DstP=3344, Spoofed
RST, Seq = y+1, Ack = x+16

Client ,
= 1 .2 .1 .2 , DstP=3344
rejects since = 9 .8 .7 .6 , SrcP=80, D s tA
2 0 0 O K … <html> …”
Src A ta=“
no active q = y + 1 , A c k = x+16, Da
A C K , Se
connection X
TCP Threat: Data Injection

ta2
ta
SYN A

ACK

y Da

y Da
ACK
SYN

Data

Nast

Nast
CK

A
time

• What about inserting data rather than disrupting a connection?

– Again, all that’s required is attacker knows correct ports, seq. numbers
– Receiver B is none the wiser!
• Termed TCP connection hijacking (or “session hijacking”)
– A general means to take over an already-established connection!
• We are toast if an attacker can see our TCP traffic!
– Because then they immediately know the port & sequence numbers
TCP Data Injection
Client (initiator) Server
IP address 1.2.1.2, port 3344 IP address 9.8.7.6, port 80

...
SrcA=1.2.1
.2, SrcP=33
ACK, Seq= 44, DstA=9
x +1 , A c k = .8.7.6, DstP
y+1, Data= =
“GET /login 80,
.html

Attacker
IP address 6.6.6.6, port N/A
SrcA=9.8.7.6, SrcP=80,
DstA=1.2.1.2, DstP=3344,
ACK, Seq = y+1, Ack = x+16 Spoofed
Data=“200 OK … <poison> …”

Client
dutifully
processes
as server’s
response
TCP Data Injection
Client (initiator) Server
IP address 1.2.1.2, port 3344 IP address 9.8.7.6, port 80

...
SrcA=1.2.1
.2, SrcP=33
ACK, Seq= 44, DstA=9
x +1 , A c k = .8.7.6, DstP
y+1, Data= =
“GET /login 80,
.html

Attacker
IP address 6.6.6.6, port N/A
SrcA=9.8.7.6, SrcP=80,
DstA=1.2.1.2, DstP=3344,
ACK, Seq = y+1, Ack = x+16 Spoofed
Data=“200 OK … <poison> …”

Client
ignores
since already tA = 1 .2 .1 .2 , DstP=3344
,
SrcP=80, D s <html> …”
processed A = 9 .8 .7 .6 , 2 0 0 O K …
Src ta=“
q = y + 1 , A c k = x+16, Da
that part of A C K , Se
bytestream
TCP Threat: Blind Spoofing
• Is it possible for an attacker to inject into a TCP
connection even if they can’t see our traffic?
• YES: if somehow they can infer or guess the port
and sequence numbers
• Let’s look at a simpler related attack where the goal
of the attacker is to create a fake connection, rather
than inject into a real one
– Why?
– Perhaps to leverage a server’s trust of a given client as
identified by its IP address
– Perhaps to frame a given client so the attacker’s actions
during the connections can’t be traced back to the
attacker
 Spoofing an Entire TCP Connection
Alleged Client (not actual) Server
IP address 1.2.1.2, port N/A IP address 9.8.7.6, port 80

Blind Attacker
SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,
DstP=80, SYN, Seq = z

, SrcP=80,
SrcA=9.8.7.6 K , S e q = y, Ack = z+1
AC
.2 .1 .2 , D s tP =5566, SYN+
DstA = 1

Attacker’s goal:
SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,
DstP=80, ACK, Seq = z+1, ACK = y+1

SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,

DstP=80, ACK, Seq = z+1, ACK = y+1, Data =
“GET /transfer-money.html”
 Spoofing an Entire TCP Connection
Alleged Client (not actual) Server
IP address 1.2.1.2, port NA IP address 9.8.7.6, port 80

Blind Attacker
SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,
DstP=80, SYN, Seq = z

, SrcP=80,
SrcA=9.8.7.6 K , Se q = y, Ack = x+1
AC
.2 .1 .2 , D s tP =5566, SYN+
DstA = 1

Small Note #1: if client receives this, will be

confused ⇒ send a RST back to server …
… So attacker may need to hurry!
 Spoofing an Entire TCP Connection
Alleged Client (not actual) Server
IP address 1.2.1.2, port NA IP address 9.8.7.6, port 80

Blind Attacker
SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,
DstP=80, SYN, Seq = z

, SrcP=80,
SrcA=9.8.7.6 K , S e q = y, Ack = z+1
AC
.2 .1 .2 , D s tP =5566, SYN+
DstA = 1

Big Note #2: attacker doesn’t

get to see this packet!
 Spoofing an Entire TCP Connection
Alleged Client (not actual) Server
IP address 1.2.1.2, port N/A IP address 9.8.7.6, port 80

Blind Attacker
SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,
DstP=80, SYN, Seq = z

, SrcP=80,
SrcA=9.8.7.6 K , S e q = y, Ack = z+1
AC
.2 .1 .2 , D s tP =5566, SYN+
DstA = 1

So how can the attacker

figure out what value of y
to use for their ACK?
SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,
DstP=80, ACK, Seq = z+1, ACK = y+1

SrcA=1.2.1.2, SrcP=5566, DstA=9.8.7.6,

DstP=80, ACK, Seq = z+1, ACK = y+1, Data =
“GET /transfer-money.html”
Reminder: Establishing a TCP Connection
A B
SYN
Each host tells its Initial
CK
Sequence Number
SYN+A
(ISN) to the other host.
ACK
(Spec says to pick based on
Data a clock)
Data

Hmm, any way

for the attacker
to know this?
How Do We Fix This?

Use a (Pseudo)-Random Sure - make a non-spoofed

ISN connection first, and see what
server used for ISN y then!
 Summary of TCP Security Issues
• An attacker who can observe your TCP connection can
manipulate it:
– Forcefully terminate by forging a RST packet
– Inject (spoof) data into either direction by forging data packets
– Works because they can include in their spoofed traffic the correct
sequence numbers (both directions) and TCP ports
– Remains a major threat today
 Summary of TCP Security Issues
• An attacker who can observe your TCP connection can
manipulate it:
– Forcefully terminate by forging a RST packet
– Inject (spoof) data into either direction by forging data packets
– Works because they can include in their spoofed traffic the correct
sequence numbers (both directions) and TCP ports
– Remains a major threat today
• An attacker who can predict the ISN chosen by a server
can “blind spoof” a connection to the server
– Makes it appear that host ABC has connected, and has sent data of
the attacker’s choosing, when in fact it hasn’t
– Undermines any security based on trusting ABC’s IP address
– Allows attacker to “frame” ABC or otherwise avoid detection
– Fixed (mostly) today by choosing random ISNs
DNS: Operation & Threats
Host Names vs. IP addresses
• Host names
–Examples: www.cnn.com and bbc.co.uk
– Mnemonic name appreciated by humans
– Variable length, full alphabet of characters
– Provide little (if any) information about location
• IP addresses
–Examples: 64.236.16.20 and 212.58.224.131
– Numerical address appreciated by routers
– Fixed length, binary number
– Hierarchical, related to host location
Mapping Names to Addresses
• Domain Name System (DNS)
– Hierarchical name space divided into sub-trees (“zones”)
o E.g. .edu, .berkeley.edu, .eecs.berkeley.edu
– Zones distributed over collection of DNS name servers
• Hierarchy of DNS servers
– Root (hardwired into other servers)
– Top-level domain (TLD) servers
o E.g. .com, .org, .net, .uk, .biz
– “Authoritative” DNS servers (e.g. for facebook.com)
• End systems configured with IP address of a resolver
to contact for their lookups
DNS Lookups via a Resolver
root DNS server (‘.’)
Host at xyz.poly.edu
wants IP address for
2
gaia.cs.umass.edu 3
TLD DNS server (‘.edu’)
4
local DNS server
(resolver) 5
128.238.1.68

Caching heavily 7 6
1 8
used to minimize authoritative DNS server
lookups (‘umass.edu’, ‘cs.umass.edu’)
dns.cs.umass.edu

requesting host
xyz.poly.edu gaia.cs.umass.edu
DNS Threats
• DNS: path-critical for just about everything we do
– Maps hostnames ⇔ IP addresses
– Design only scales if we can minimize lookup traffic
o #1 way to do so: caching
o #2 way to do so: return not only answers to queries, but additional info
that will likely be needed shortly

• What if attacker eavesdrops on our DNS queries?

– Simple to then redirect us w/ spoofed misinformation
• Consider attackers who can’t eavesdrop - but still aim
to manipulate us via how the protocol functions
• Directly interacting w/ DNS: dig program on Unix
– Allows querying of DNS system
– Dumps each field in DNS responses
dig eecs.mit.edu A Use Unix “dig” utility to look up IP address (“A”)
for hostname eecs.mit.edu via DNS
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;eecs.mit.edu. IN A

;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6

;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.

;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;eecs.mit.edu. IN A

;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6

;; AUTHORITY SECTION:
mit.edu. 11088 This is dig identifying
IN NS its version and the
BITSY.mit.edu.
mit.edu. 11088 query it is attempting
IN NS to look up
W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.

;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;eecs.mit.edu. IN A

;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6

;; AUTHORITY SECTION:
mit.edu. 11088 Status values
IN NS returnedBITSY.mit.edu.
from the remote
mit.edu. 11088 name server
IN NSqueried by dig
W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.

;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;eecs.mit.edu. IN A

;; ANSWER SECTION:
eecs.mit.edu. 21600 Including
IN a 16-bit
A transaction identifier that
18.62.1.6
enables the DNS client (dig, in this case) to
;; AUTHORITY SECTION: match up the reply with its original request
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.

;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;eecs.mit.edu. IN A

;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6

;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.
The name server echoes back the question
that it is answering as the first part of its reply
;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: “Answer”
QUERY, tells
status:
us the NOERROR, id: 19901
IP address associated with
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
eecs.mit.edu is 18.62.1.6 and we can cache the
result for 21,600 seconds
;; QUESTION SECTION:
;eecs.mit.edu. IN A

;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6

;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.

;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;eecs.mit.edu. IN A

;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6

;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. In general,
11088 a single
IN Resource NS Record (RR) like this
STRAWB.mit.edu.
includes, left-to-right, a DNS name, a time-to-live, a
;; ADDITIONAL SECTION:family (IN for our purposes - ignore), a type (A here,
STRAWB.mit.edu. which stands for
126738 IN“Address”),
A and an 18.71.0.151
associated value
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer: “Authority” tells us the name servers responsible for the
;; ->>HEADER<<- opcode:answer.
QUERY,Each RR gives
status: the hostname
NOERROR, id: of19901
a different name
server1,
;; flags: qr rd ra; QUERY: (“NS”) for names
ANSWER: 1, inAUTHORITY:
mit.edu. We 3,
should cache each 3
ADDITIONAL:
record for 11,088 seconds.
;; QUESTION SECTION:
;eecs.mit.edu. If the “Answer”
IN had beenA empty, then the resolver’s next
step would be to send the original query to one of these
;; ANSWER SECTION: name servers.
eecs.mit.edu. 21600 IN A 18.62.1.6

;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.

;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;eecs.mit.edu. IN A
“Additional” provides extra information to save us from making
;; ANSWER SECTION:separate lookups for it, or helps with bootstrapping.
eecs.mit.edu. 21600 IN A 18.62.1.6
Here, it tells us the IP addresses for the hostnames of the name
servers. We add these to our cache.
;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.

;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160