TELCOM 2310: Applications of Networks

Lecture 3 (Part 1)
Web Caching and CDNs, and DNS
Kaushik P. Seshadreesan, Fall 2023
Partially adapted from Kurose & Ross slides: http://gaia.cs.umass.edu/kurose_ross/ppt.htm
Partially adapted from JHU Computer Networks course: https://github.com/xinjin/course-net

Department of Informatics and Networked Systems

School of Computing and Information
 Announcements
• Office Hours (Emailing us beforehand indicating attendance is
highly recommended for timely help.)
– Kaushik: Wednesdays, 2 - 3 PM
• Upon appointment (Just send me an email by noon same day).
• Remote only. Zoom link: https://pitt.zoom.us/j/8062337566

– Hanyu: Thursdays, Time TBD (will be updated on Canvas)

• Upon appointment (Just send me an email by noon same day).
• Remote only. Zoom link: https://pitt.zoom.us/j/9737949838

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 2

 Recap: Communication organization

L7
Applications Application

built on
L4
Reliable or unreliable transport Transport
built on
L3
Best-effort global packet delivery Network
built on
L2
Best-effort local packet delivery Data link
built on
L1
Physical transfer of bits Physical

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 3

 Recap: Layers and protocols

L7 Application Application L7

L4 Transport Transport L4
L3 Network Network L3
L2 Data link Data link L2
L1 Physical Physical L1

• Communication between peer layers on different systems is

defined by protocols
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 4
 Recap: What Gets Implemented Where?
• Lower three layers implemented everywhere
• Top two layers implemented only at hosts

Application Application
Transport Transport
Network Network Network
Datalink Datalink Datalink
Physical Physical Physical

End system Packet Switch End system

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 5
 Recap: Physical communication
• Communication goes down to physical network
• Then up to relevant layer

Application Application
Transport Transport
Network Network Network
Datalink Datalink Datalink
Physical Physical Physical

End system Switch End system

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 6
 Recap: Placing network functions
• Why only implement application and transport layers at end
systems?
• End-to-end arguments by Saltzer, Reed, and Clark
– Dumb network and smart end systems
– Functions that can be completely and correctly implemented only
with the knowledge of application end host, should not be pushed
into the network
– Sometimes necessary to break this for performance and policy
optimizations

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 7

 Recap: What is a network application?
• Two or more processes running in end systems that send messages
over a network to accomplish some goal
– Each process is a running instance of a program
– Programs can be written in any programming language (C, Java, Python,
Go, etc.)
– Programs use the socket API (Application Programming Interface) to send
messages
application application
socket controlled by
process process app developer

transport transport
network network controlled
link by OS
link Internet
physical physical

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 8

 Recap: What is a socket?
• Software interface between the application layer and the transport layer
• At a high level (we’ll try this out in 2 weeks):
– Program opens a socket, specifying which transport layer service it wants to use
– Can use send and receive functions on that socket
– Closes socket to release resources
application application
socket controlled by
process process app developer
From a programming
transport transport
perspective, similar to
network network controlled
APIs for file I/O link by OS
link Internet
physical physical

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 9

 Recap: How do we specify where to send data?
• A socket is identified by:
– Service: transport layer protocol (TCP vs UDP)
– IP address: 32-bit address that uniquely identifies the host
– Port: 16-bit number (between 0 and 65535) that identifies this socket (vs
all other network applications running on this host)
application application
In our letter analogy: socket controlled by
process process app developer
IP address -> building address
transport transport
Port -> office number
network network controlled
link by OS
link Internet
physical physical

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 10

 Recap: WWW Application
• Client-server architecture, with
TCP transport
• Web browsers (clients) request PC running
web pages from web servers Firefox browser

• HTTP (Hypertext transfer

protocol) defines the server running
Apache Web
communication protocol server
between web browsers and
iPhone running
servers Safari browser

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 11

 Recap: HTTP Performance (Single Request)

RTT (round trip time): time for a

packet to travel from client to
server and back initiate TCP
connection
HTTP response time (per object): RTT
▪ one RTT to initiate TCP connection
request file
▪ one RTT for HTTP request and first few
RTT time to
bytes of HTTP response to return transmit
▪ object/file transmission time file received
file

time time
HTTP response time = 2RTT+ file transmission time
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3
Application Layer: 2-12
 Recap: Issuing Multiple Requests
• Naïve approach: just repeat the process for each object
– Open TCP connection (incurs 1 RTT)
– Request and retrieve object (incurs 1 RTT + object transfer)
– incurs (at least) 2n RTT to retrieve all objects

• How to improve?
– Parallel connections
– Persistent connections (introduced in HTTP 1.1)
– Pipelining
– Note: can mix and match these techniques
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 13
 Recap: Non-Persistent HTTP (HTTP/1.0) in Parallel
• To reduce response
time, run separate
TCP connection per
initiate initiate initiate
object, but in connection connection connection
for obj 1 for obj 2 for obj 3
parallel

receive
But, 1) has OS overhead of obj 1
multiple TCP sessions; 2) receive
receive obj 3
can violate TCP congestion time
obj 2
time time time time time
control expectations
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 14
 Recap: Persistent HTTP (HTTP/1.1)
• Maintain TCP connection across Pipelined communication
pattern
multiple requests Client Server
– Avoid overhead of setting up and tearing
down many connections
– Better match TCP expectations: allow TCP to
learn RTT and bandwidth characteristics,
support fair bandwidth sharing
• Pipelining to further reduce response
time

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 15

 Recap: HTTP Performance
• How long does it take to retrieve n small objects?
– Since objects are small, assume transmission delay is negligible
– Propagation delay (RTT) dominates
• Non-persistent, serial: ~ 2𝑅𝑇𝑇 × 𝑛
𝑛
• Non-persistent, m parallel connections: ~2𝑅𝑇𝑇 × 𝑚
• Persistent (non-pipelined): ~ 1 + 𝑛 × 𝑅𝑇𝑇
• Persistent, pipelined: ~ 2 × 𝑅𝑇𝑇 for first set of requests, 𝑅𝑇𝑇
after connection established
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 16
 Recap: HTTP Performance
• What if the objects are large?
• Need to account for transmission delay
• Pipelining doesn’t help with transmission delay – we still need
to transfer all the data
– Let F = file size in bits, B = bandwidth in bits/sec, n = number of objects
𝑛𝐹
– Very best case; still need to request object and retrieve it: ~ 𝑅𝑇𝑇 +
𝐵
• To improve further, need to find a way to reduce RTT and/or
increase B (or reduce data size?)…

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 17

TELCOM 2310: Applications of Networks

Lecture 3 (Part 1)
Web Caching and CDNs, and DNS
Kaushik P. Seshadreesan, Fall 2023
Partially adapted from Kurose & Ross slides: http://gaia.cs.umass.edu/kurose_ross/ppt.htm
Partially adapted from JHU Computer Networks course: https://github.com/xinjin/course-net

Department of Informatics and Networked Systems

School of Computing and Information
 Web Caching and CDNs
Objectives

• Understand how caching and replication are used to improve

web performance

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 19

 Recall: HTTP Performance
• In the best case (connection already established, pipelined requests, no
𝑑𝑎𝑡𝑎_𝑠𝑖𝑧𝑒
queuing or processing delay), response time is about 𝑅𝑇𝑇 +
𝑏𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ
server
GET O4 GET O3 GET O2 GET O1
RTT

Object
transmission
time =
𝑑𝑎𝑡𝑎_𝑠𝑖𝑧𝑒
𝑏𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ
O1
O2
O3
O4

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 20

 Improving Performance: Caching
• To improve response times for frequently accessed data, we
can cache (temporarily store) results we’ve already retrieved
– Where to store? Simple option is for the browser (client) to do it
• Server doesn’t need to re-send if we already have the latest
copy of a resource

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 21

 Caching Mechanism: Conditional GET
Goal: don’t send object if cache has an up-to-date client server
cached version
▪ client: specify date of cached copy in HTTP HTTP request msg
request If-modified-since: <date>
object
If-modified-since: <date> not
▪ server: response contains no object if cached modified
HTTP response
copy is up-to-date: before
HTTP/1.1
HTTP/1.1 304 Not Modified 304 Not Modified <date>

Outcomes:
▪ no object transmission delay – reduce data size
▪ lower link utilization – increase free bandwidth HTTP request msg
for other requests If-modified-since: <date> object
▪ can also use cached copy without contacting modified
server – very fast (eliminates RTT), but risks HTTP response after
stale data HTTP/1.1 200 OK <date>
<data>
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3
22
 Caching beyond the browser: Proxy Servers
• ISPs (or institutions) can deploy proxy servers (web caches) in their networks
– Increases potential for cache hits compared with browser-only cache (many users access
the same content)
– Reduces network traffic for ISP
– Improves performance for users
Origin Server

Tier-1 ISP
Forward proxies
ISP-1 ISP-2

Clients
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 23
 Forward Proxy: Motivation
Scenario:
▪ access link rate: 15 Mbps origin
▪ LAN rate: 1 Gbps servers
▪ RTT from institutional router to server: 2 sec public
Internet
▪ Web object size: 1 Mbits
▪ Average request rate from browsers to origin
servers: 15/sec
15 Mbps
▪ average data rate to browsers: 15 Mbps access link
Performance: institutional
▪ LAN utilization: .015 network
1 Gbps LAN
▪ access link utilization = 1.0
▪ end-end delay = Internet delay +
access link delay + LAN delay
= 2 sec + unbounded delay (~minutes if not more!) + ~10s of ms
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3
24
 Option 1: Upgrade Access Link
Scenario: 150 Mbps
▪ access link rate: 15 Mbps, LAN rate: 1 Gbps origin
▪ RTT from institutional router to server: 2 sec servers
▪ Web object size: 1 Mbits public
Internet
▪ Average request rate from browsers to origin
servers: 15/sec
▪ avg data rate to browsers: 15 Mbps 150 Mbps
15 Mbps
Performance: access link

▪ LAN utilization: .015 institutional

network
▪ access link utilization = 1.0 .1 1 Gbps LAN

▪ end-end delay = Internet delay +

access link delay + LAN delay
= 2 sec + unbounded delay + 10s of msecs
Cost: faster access link (expensive!)
09/16/2023 msecs
TELCOM 2310 Fall 2024: Lecture 3
25
 Option 2: Install a Proxy
Scenario:
▪ access link rate: 15 Mbps, LAN rate: 1 Gbps origin
▪ RTT from institutional router to server: 2 sec servers
▪ Web object size: 1 Mbits public
Internet
▪ Average request rate from browsers to origin
servers: 15/sec
▪ average data rate to browsers: 15 Mbps
15 Mbps
Performance: access link

▪ LAN utilization: ?? institutional

network
▪ access link utilization = ?? 1 Gbps LAN

▪ end-end delay = ??
Cost: web cache (cheap!) local web cache

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

26
 Option 2: Install a Proxy
Calculating access link utilization, end-
end delay with cache: origin
▪ suppose cache hit rate is 0.4: 40% requests servers
satisfied at cache, 60% requests satisfied at public
Internet
origin
▪ access link: 60% of requests use access link
▪ data rate to browsers over access link
15 Mbps
= 0.6 * 15 Mbps = 9 Mbps access link
▪ utilization = 9/15 = .6 institutional
network
▪ average end-end delay 1 Gbps LAN
= 0.6 * (delay from origin servers)
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs local web cache

lower average end-end delay than

09/16/2023 with
TELCOM 150
2310 Fall 2024:Mbps
Lecture 3 link (and cheaper too!)
27
 Caching beyond the browser: Proxy Servers
• Content providers can also deploy proxy servers in their networks
– Reduces server load for content provider
– Improves performance for users (reduce queuing at server processing level)
Origin Server
Reverse proxies

Tier-1 ISP
Forward proxies
ISP-1 ISP-2

Clients
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 28
 Content Distribution Networks (CDNs)
• Caching and replication by content providers
– May be private CDN built by content provider (e.g. Google, Netflix)
– May be third-party CDN that serves many content providers (e.g. Akamai, Limelight)
• Aim to get content closer to users – servers distributed across the globe and
placed in or close to access ISPs
– Reduce propagation delay
– Reduce number of links traversed (reduce chance of encountering congested
“bottleneck link”)
– Reduce backbone traffic (and lower content provider cost)
– Improve fault tolerance
• Can combine reactive caching and proactive replication
– Pull: Cache content requested by clients
– Push: Proactively replicate content expected to have high access rates

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 29

 Content Distribution Networks (CDNs)
▪ CDN: stores copies of content at CDN nodes
• e.g. Netflix stores copies of One Piece
▪ subscriber requests content from CDN
• directed to nearby copy, retrieves content
• may choose different copy if network path congested

server IP address
where’s One Piece?

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

30
 Summary
• Caching and replication improve web performance
– Move content closer to clients
• Reduce RTT (assuming content served directly from cache/replica)
• Reduce chance to encounter bottleneck link
– Avoid transferring the same data over the same part of the network
multiple times
• Reduce overall network traffic

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 31

TELCOM 2310: Applications of Networks

DNS

Partially adapted from Kurose & Ross slides: http://gaia.cs.umass.edu/kurose_ross/ppt.htm

Partially adapted from JHU Computer Networks course: https://github.com/xinjin/course-net

Department of Informatics and Networked Systems

School of Computing and Information
 Objectives
• Understand how DNS (Domain Name Service) is used to map
host names to IP addresses

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 33

 Internet names & addresses
• IP addresses: e.g. 136.142.156.132
– Router-usable labels for machines
– Conforms to network structure (the “where”)
• Hostnames: e.g. sci.pitt.edu
– Human-usable labels for machines
– Conforms to organizational structure (the “who”)
• The Domain Name System (DNS) is how we map from one to
the other
– A directory service

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 34

 Why do we need DNS?
• Convenience
– Much easier to remember www.sci.pitt.edu than 136.142.156.132

• Flexibility – Decoupling names from addresses allows:

– Seamless address changes
• e.g. move www.sci.pitt.edu to new machine with IP 136.142.156.133
– Multiple names per IP address
• different webpages on same machine (e.g. www.facultydiversity.pitt.edu hosted on same
machine as www.sci.pitt.edu)
• different services on same machine (mail, web)
• aliasing, e.g. ewi-vip-20.cssd.pitt.edu = www.sci.pitt.edu = sci.pitt.edu
– Multiple IP addresses per name
• Load distribution, Redirection to CDN infrastructure
• Mail server aliasing (mail and web servers on different machines can share hostname)

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 35

 DNS: History
• Initially all host-address mappings were in a hosts.txt file (in
/etc/hosts):
– Maintained by the Stanford Research Institute (SRI)
– Changes were submitted to SRI by email
– New versions of hosts.txt periodically FTP’d from SRI
• As the Internet grew this system broke down…
– SRI couldn’t handle the load
– Names were not unique
– Hosts had inaccurate copies of hosts.txt
– Single point of failure
• The Domain Name System (DNS) was invented to fix this

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 36

 DNS: Design Goals
• Fix the problems of hosts.txt solution…

• Scalable
• Easy to maintain
• Highly available
• No single point of failure
• Fast lookups

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 37

 DNS: Overview
• Distributed database of hostname-IP address mappings
– Partitioned across many name servers
• Organized hierarchically
– Simplifies maintenance

• Provides a critical service for the Internet, but is implemented

as an application level protocol (end-to-end argument)
– Runs over UDP on port 53, client-server architecture

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 38

 DNS: Hierarchical Organization
• Namespace is organized hierarchically
root

edu com gov mil org net uk fr …

• “Top Level Domains” are at the top

pitt umass • Domains are subtrees
– e.g., .edu, pitt.edu, sci.pitt.edu
• Name is leaf-to-root path
sci as engineering
– sci.pitt.edu
• Depth of tree is arbitrary (limit 128)
• Name collisions trivially avoided
– Each domain is responsible
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 39
 DNS: Hierarchical Organization
Root DNS Servers Root
… …
.com DNS servers .org DNS servers .edu DNS servers Top Level Domain
… … … …
yahoo.com amazon.com pbs.org pitt.edu umass.edu
DNS servers DNS servers DNS servers DNS servers DNS servers Authoritative

Servers are also organized hierarchically

Client wants IP address for www.pitt.edu; 1st approximation:
▪ client queries root server to find .edu DNS server
▪ client queries .edu DNS server to get pitt.edu DNS server
▪ client queries pitt.edu DNS server to get IP address for www.pitt.edu
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3
40
 Root Name Servers
▪ ICANN (Internet Corporation for Assigned Names and Numbers) manages root DNS domain
▪ 13 logical root name “servers” worldwide each “server” replicated many times
(over 1000 total instances)
• https://root-servers.org/ A Verisign, Dulles, VA
C Cogent, Herndon, VA
D U Maryland College Park, MD
G US DoD Vienna, VA K RIPE London
H ARL Aberdeen, MD
J Verisign I Autonomica, Stockholm
E NASA Mt View, CA
F Internet Software
Consortium M WIDE Tokyo
Palo Alto, CA

B USC-ISI Marina del Rey, CA

L ICANN Los Angeles, CA

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

41
 Root Name Servers
▪ ICANN (Internet Corporation for Assigned Names and Numbers) manages root DNS domain
▪ 12 logical root name “servers” worldwide each “server” replicated many times
(over 1000 total instances)
• https://root-servers.org/

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

42
 Top-Level Domain Servers

Top-Level Domain (TLD) servers:

▪ responsible for .com, .org, .net, .edu, .aero, .jobs, .museums, and all
top-level country domains, e.g.: .cn, .uk, .fr, .ca, .jp
▪ Verisign Global Registry Services: authoritative registry for .com,
.net TLD
▪ After acquisition of Network Solutions, which originally served this role
▪ Educause: .edu TLD

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

43
 Authoritative DNS Servers

Authoritative DNS servers:

▪ organization’s own DNS server(s), providing authoritative hostname
to IP mappings for organization’s named hosts
▪ can be maintained by organization or service provider

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

44
 Local DNS name servers

▪ Not part of hierarchy

• Not “in charge” of any part of the name space
▪ Acts as proxy: when host makes DNS query, query is sent to its
local DNS server
• Local DNS server forwards query into hierarchy
▪ each ISP (residential ISP, company, university) has one
• also called “default name server”

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

45
 DNS name resolution: iterated query
root DNS server
Example: host at sci.pitt.edu wants IP
address for gaia.cs.umass.edu 2
3
TLD DNS server
Iterated query: 1 4

▪ contacted server replies 8 5

with name of server to requesting host at local DNS server
contact sci.pitt.edu dns.pitt.edu
gaia.cs.umass.edu
▪ “I don’t know this name, 7 6
but ask this server”
▪ In this example, all authoritative DNS server
requests other than 1 dns.cs.umass.edu

are iterated
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3
46
 DNS name resolution: recursive query
root DNS server
Example: host at sci.pitt.edu wants IP
address for gaia.cs.umass.edu 2 3

7 6
Recursive query: 1 TLD DNS server
▪ puts burden of name
resolution on contacted 8
name server requesting host at local DNS server
5 4
▪ All the queries can be sci.pitt.edu sci.pitt.edu
gaia.cs.umass.edu
recursive (not common)
▪ Usually the query from the
host to the local server is authoritative DNS server
recursive and all the rest dns.cs.umass.edu
iterative (like previous
example)
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3
47
 DNS Caching
▪ How DNS caching works
• DNS servers (at every level) cache responses to queries
• Responses include a “time to live” (TTL) field
• Server deletes cached entry after TTL expires
▪ Caching can greatly reduce overhead
• The top-level servers very rarely change
• Popular sites visited often
• Local DNS server often has the information cached
▪ But, cached entries may be out-of-date (best-effort name-to-address
translation)
• if host changes its IP address, may not be known Internet-wide until all TTLs
expire

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

48
 DNS Records
DNS: distributed database storing resource records (RR)
RR format: (name, value, type, ttl)
type=A type=CNAME
▪ name is hostname ▪ name is alias name for some “canonical”
▪ value is IP address (the real) name
▪ www.ibm.com is really servereast.backup2.ibm.com
type=NS ▪ value is canonical name
▪ name is domain (e.g., foo.com)
▪ value is hostname of an
type=MX
authoritative name server for ▪ value is name of mailserver
this domain associated with name

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

49
 DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes

message header: identification flags

▪ identification: 16 bit # for query, # questions # answer RRs

reply to query uses same # # authority RRs # additional RRs
▪ flags:
• query or reply questions (variable # of questions)

• recursion desired
answers (variable # of RRs)
• recursion available
• reply is authoritative authority (variable # of RRs)

additional info (variable # of RRs)

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

50
 DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

name, type fields for a query questions (variable # of questions)

RRs in response to query answers (variable # of RRs)

records for authoritative servers authority (variable # of RRs)

additional “ helpful” info that may additional info (variable # of RRs)

be used
09/16/2023 TELCOM 2310 Fall 2024: Lecture 3
51
 Adding New Records to DNS
Example: new startup “Network Utopia”
▪ register name networkuptopia.com at DNS registrar (e.g., Network
Solutions, GoDaddy)
• provide names, IP addresses of authoritative name server (primary and
secondary)
• registrar inserts NS, A RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
▪ create authoritative server locally with IP address 212.212.212.1
• type A record for www.networkuptopia.com
• type MX record for networkutopia.com (if it’s also a mail server)

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3

52
 Summary
• DNS translates hostnames to IP addresses
– provides convenience and flexibility
• Critical Internet service, implemented as application-level
protocol
• Scalability and ease of maintenance achieved through
hierarchical organization

09/16/2023 TELCOM 2310 Fall 2024: Lecture 3 53