4.Application_Part2
4.Application_Part2
2
DNS: Domain Name System
people: many identifiers: Domain Name System:
• TFN, name, passport # § distributed database
Internet hosts, routers: implemented in hierarchy of
• IP address (32 bit) - used for many name servers
addressing datagrams § application-layer protocol: hosts,
• “name”, e.g., cs.umass.edu - name servers communicate to
used by humans resolve names (address/name
Q: how to map between IP translation)
address and name, and vice • note: core Internet function,
versa ? implemented as application-
layer protocol
• complexity at network’s “edge”
3
DNS: History
v 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
§ An administrator could pick names at their discretion
http://www.wired.com/2012/10/joe-postel/
4
DNS: services, structure
DNS services Q: Why not centralize DNS?
§ hostname to IP address § single point of failure
translation § traffic volume
§ host aliasing § distant centralized database
• canonical, alias names
§ maintenance
§ mail server aliasing A: doesn‘t scale!
§ load distribution § Comcast DNS servers
• replicated Web servers: alone: 600B DNS queries
many IP addresses per day
correspond to one name
5
Goals
v No naming conflicts (uniqueness)
v Scalable
§ many names
§ (secondary) frequent updates
v Distributed, autonomous administration
§ Ability to update my own (domains’) names
§ Don’t have to track everybody’s updates
v Highly available
v Lookups should be fast
6
Key idea: Hierarchy
Three intertwined hierarchies
§ Hierarchical namespace
• As opposed to original flat namespace
§ Hierarchically administered
• As opposed to centralised
7
Hierarchical Namespace
root
8
Hierarchical Administration
root
eecs sims
§ A zone corresponds to a distinct contiguous portion of the
DNS name space that is managed by an administrative authority
instr
§ E.g., UCB controls names: *.berkeley.edu and *.sims.berkeley.edu
10
Server Hierarchy
v Each server stores a (small!) subset of the total DNS database
v Each server can discover the server(s) that are responsible for
the other portions of the hierarchy
§ Every server knows the root server(s)
§ Root server(s) knows about all top-level domains
11
Credits: Prof David Wetherall, UoW
pk au
Authoritative NS
edu
unsw
cse
Local NS
Titanium
robot.cs.washington.edu.
washington.edu
.edu
12
DNS: root name servers
§ official, contact-of-last-resort
by name servers that can not 13 logical root name “servers”
worldwide each “server” replicated
resolve name many times (~200 servers in US)
§ incredibly important Internet
function
• Internet couldn’t function without
root servers
• DNSSEC – provides security
(authentication and message
integrity)
§ ICANN (Internet Corporation for
Assigned Names and Numbers)
manages root DNS domain
13
DNS: root name servers
www.root-servers.org
14
TLD: authoritative 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
§ Network Solutions: authoritative registry for .com, .net
TLD
§ Educause: .edu TLD
15
Local DNS name servers
§ does not strictly belong to hierarchy
§ each ISP (residential ISP, company, university) has one
• also called “default name server”
§ Hosts learn about the local DNS server via a host configuration
protocol (e.g., DHCP)
§ Client application
• Obtain hostname (e.g., from URL)
• Do gethostbyname() to trigger DNS request to its local DNS server
§ when host makes DNS query, query is sent to its local DNS server
• has local cache of recent name-to-address translation pairs (but may be
out of date!)
• acts as proxy, forwards query into hierarchy
16
DNS name resolution: iterated query
root DNS server
Example: host at
engineering.nyu.edu wants IP
2
address for gaia.cs.umass.edu 3
TLD DNS server
Iterated query: 1 4
§ contacted server 8 5
17
DNS name resolution: recursive query
root DNS server
Example: host at
engineering.nyu.edu wants IP 3
2
address for gaia.cs.umass.edu 7 6
Recursive query: 1 TLD DNS server
§ puts burden of 8
name resolution on requesting host at
engineering.nyu.edu
local DNS server
dns.nyu.edu 5 4
contacted name gaia.cs.umass.edu
server
§ heavy load at authoritative DNS server
dns.cs.umass.edu
upper levels of
hierarchy?
18
Caching, Updating DNS Records
§ once (any) name server learns mapping, it caches mapping
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
• thus root name servers not often visited
type=A type=CNAME
§ name is hostname § name is alias name for some
§ value is IP address “canonical” (the real) name
§ www.ibm.com is really
type=NS servereast.backup2.ibm.com
§ name is domain (e.g., § value is canonical name
foo.com)
§ value is hostname of type=MX
authoritative name server § value is name of mailserver
for this domain associated with name
20
DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes
identification flags
message header:
# questions # answer RRs
§ identification: 16 bit # for query,
reply to query uses same # # authority RRs # additional RRs
21
DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes
identification flags
23
Inserting records into DNS
Example: new startup “Network Utopia”
§ register name networkuptopia.com at DNS registrar (e.g.,
Network Solutions)
• 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
• Containing type A record for www.networkuptopia.com
• Containing type MX record for networkutopia.com
24
Updating DNS records
v Remember that old records may be cached in other
DNS servers (for up to TTL)
v General guidelines
§ Record the current TTL value of the record
§ Lower the TTL of the record to a low value (e.g., 30
seconds)
§ Wait the length of the previous TTL
§ Update the record
§ Wait for some time (e.g., 1 hour)
§ Change the TTL back to your previous time
25
Reliability
v DNS servers are replicated (primary/secondary)
§ Name service available if at least one replica is up
§ Queries can be load-balanced between replicas
v Usually, UDP used for queries
§ Need reliability: must implement this on top of UDP
§ Spec supports TCP too, but not always implemented
v DNS uses port 53
v Try alternate servers on timeout
§ Exponential backoff when retrying same server
v Same identifier for all queries
§ Don’t care which server responds
26
CDN example (more later)
27
Do you trust your DNS server?
v Censorship
https://wikileaks.org/wiki/Alternative_DNS
v Logging
§ IP address, websites visited, geolocation data and more
§ E.g., Google DNS:
https://developers.google.com/speed/public-dns/privacy
29
DNS security
DDoS attacks Redirect attacks
§ bombard root servers with § man-in-middle
traffic • intercept DNS queries
• not successful to date § DNS poisoning
• traffic filtering • send bogus relies to DNS
• local DNS servers cache IPs server, which caches DNSSEC
of TLD servers, allowing root Exploit DNS for DDoS [RFC 4033]
server bypass
§ send queries with spoofed
§ bombard TLD servers source address: target IP
• potentially more dangerous § requires amplification
30
DNS Cache Poisoning
v Suppose you are a bad guy and you control the name server
for drevil.com. Your name server receives a request to resolve
www.drevil.com. and it responds as follows:
;; QUESTION SECTION:
;www.drevil.com. IN A
;; ANSWER SECTION:
www.drevil.com 300 IN A 129.45.212.42
;; AUTHORITY SECTION:
drevil.com 86400 IN NS dns1.drevil.com.
drevil.com 86400 IN NS google.com
A drevil.com machine, not google.com
;; ADDITIONAL SECTION:
google.com 600 IN A 129.45.212.222
33
Quiz: DNS (2)
34
Quiz: DNS (3)
a) A
Answer:
b) NS
c) CNAME
d) MX
e) All of the above
35
Quiz: DNS (4)
A. 0
Answer:
B. 1
C. 2
D. 3
E. 42
36
2. Application Layer: outline
2.1 principles of network applications 2.5 P2P applications
2.2 Web and HTTP 2.6 video streaming and content
2.3 electronic mail distribution networks (CDNs)
§ SMTP 2.7 socket programming with
2.4 DNS UDP and TCP
37
Peer-to-peer (P2P) architecture
§ no always-on server mobile network
communicate
§ peers request service from other
peers, provide service in return to
other peers local or
regional
• self scalability – new peers bring new ISP
service capacity, and new service demands home network content
• complex management
§ examples: P2P file sharing (BitTorrent), enterprise
network
streaming (KanKan), VoIP (Skype),
Cryptocurrency (Bitcoin) 38
File distribution: client-server vs P2P
Q: how much time to distribute file (size F) from one
server to N peers?
• peer upload/download capacity is limited resource
u s: server
upload capacity
d i: peer i
file, size F us
u1 d1 u2 d2
download capacity
server
di
uN network (with abundant
bandwidth) ui
dN
u i: peer i upload
capacity
39
File distribution time: client-server
§ server transmission: must
sequentially send (upload) N file
copies: F
us
• time to send one copy: F/us
di
• time to send N copies: NF/us network
ui
§ client: each client must download
file copy
• dmin = min client download rate
• slowest client download time: F/dmin
time to distribute F
to N clients using Dc-s > max{NF/us,,F/dmin}
client-server approach
increases linearly in N 40
File distribution time: P2P
§ server transmission: must upload
at least one copy:
F
• time to send one copy: F/us us
1.5
0.5
0
0 5 10 15 20 25 30 35
N
42
P2P file distribution: BitTorrent
§ file divided into 256KB chunks
§ peers in torrent send/receive file chunks
tracker: tracks peers torrent: group of peers
participating in torrent exchanging chunks of a
file
Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent
43
P2P file distribution: BitTorrent
§ peer joining torrent:
• has no chunks, but will accumulate
them over time from other peers
• registers with tracker to get list of
peers, connects to subset of peers
(“neighbors”)
§ while downloading, peer uploads chunks to other peers
§ peer may change peers with whom it exchanges chunks
§ churn: peers may come and go
§ once peer has entire file, it may (selfishly) leave or
(altruistically) remain in torrent
44
BitTorrent: requesting, sending file chunks
Requesting chunks: Sending chunks: tit-for-tat
§ at any given time, § Alice sends chunks to those
different peers have four peers currently sending
different subsets of file her chunks at highest rate
chunks
• other peers are choked by Alice
§ periodically, Alice asks (do not receive chunks from her)
each peer for list of • re-evaluate top 4 every10 secs
chunks that they have
§ every 30 secs: randomly
§ Alice requests missing
chunks from peers, select another peer, starts
rarest first (why?) sending chunks
• “optimistically unchoke” this peer
• newly chosen peer may join top 4
45
BitTorrent: tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers
46
Quiz: BitTorrent
Answer:
v BitTorrent uses tit-for-tat in each round to
47
Video Streaming and CDNs: context
§ stream video traffic: major consumer of Internet
bandwidth
• Netflix, YouTube, Amazon Prime: 80% of residential ISP
traffic (2020)
§ challenge: scale - how to reach ~1B users?
• single mega-video server won’t work (why?)
§ challenge: heterogeneity
§ different users have different capabilities (e.g., wired
versus mobile; bandwidth rich versus bandwidth poor)
§ solution: distributed, application-level infrastructure
48
Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
§ video: sequence of images
number of repeated values (N)
49
Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
50
Streaming multimedia: DASH
§ DASH: Dynamic, Adaptive Streaming over HTTP
§ server:
• divides video file into multiple chunks
• each chunk stored, encoded at different rates
• manifest file: provides URLs for different chunks Internet
§ client: client
51
Streaming multimedia: DASH
§ “intelligence” at client: client
determines
• when to request chunk (so that buffer
starvation, or overflow does not occur)
• what encoding rate to request (higher
quality when more bandwidth available)
55
DNS protocol messages
DNS query and reply messages, both have same format:
2 bytes 2 bytes
identification flags
57
Content distribution networks (CDNs)
§ CDN: stores copies of content at CDN nodes
• e.g., Netflix stores copies of MadMen
§ subscriber requests content from CDN
• directed to nearby copy, retrieves content
• may choose different copy if network path congested
… …
…
manifest file
…
where’s Madmen?
… …
58
Content distribution networks (CDNs)
… …
Internet host-host communication as a service
…
OTT challenges: coping with a congested Internet
…
netcinema’s
authoratative DNS KingCDN
KingCDN.com
authoritative DNS
60
Case study: Netflix
Amazon cloud upload copies of
multiple versions of
video to CDN servers
CDN
server
Netflix registration,
accounting servers
Bob browses
Netflix video Manifest CDN
2 server
file,
1 3 requested
Bob manages returned for
Netflix account
specific CDN
video 4 server
DASH server
selected,
contacted,
streaming begins 61
Quiz: CDN
Answer:
62
2. Application Layer: outline
2.1 principles of network applications 2.5 P2P applications
2.2 Web and HTTP 2.6 video streaming and content
2.3 electronic mail distribution networks (CDNs)
§ SMTP 2.7 socket programming with
2.4 DNS UDP and TCP
63
Socket programming
goal: learn how to build client/server applications that
communicate using sockets
socket: door between application process and end-end-
transport protocol
application application
socket controlled by
process process app developer
transport transport
network network controlled
link
by OS
link Internet
physical physical
-64
Socket programming with UDP
UDP: no “connection” between client & server
v no handshaking before sending data
v sender explicitly attaches IP destination address and port # to each
packet
v receiver extracts sender IP address and port# from received
packet
UDP: transmitted data may be lost or received out-of-order
Application viewpoint:
vUDP provides unreliable transfer of groups of bytes (“segments”)
between client and server
65
Pseudo code UDP client
v Create socket
v Loop
§ (Send UDP segment to known port and IP addr of server)
66
Pseudo code UDP server
v Create socket
v Bind socket to a specific port where clients can contact
you
v Loop
§ (Receive UDP segment from client X)
Note: The IP address and port number of the client must be extracted from the client’s message
67
Socket programming with TCP
Client must contact server § when contacted by client, server
v server process must first be TCP creates new socket for server
running process to communicate with that
v server must have created socket particular client
(door) that welcomes client’s • allows server to talk with multiple
contact clients
• source port numbers used to
Client contacts server by:
distinguish clients (more when we
v Creating TCP socket, specifying IP study TCP)
address, port number of server
process Application viewpoint
v when client creates socket: client TCP provides reliable, in-order
TCP establishes connection to byte-stream transfer (“pipe”)
server TCP between client and server
68
TCP Sockets
69
Pseudo code TCP client
v Create socket (ConnectionSocket)
v Do an active connect specifying the IP address and port
number of server
v Read and write data into ConnectionSocket to
communicate with client
v Close ConnectionSocket
70
Pseudo code TCP server
v Create socket (WelcomingSocket)
v Bind socket to a specific port where clients can contact
you
v Register with the OS your willingness to listen on that
socket for clients to contact you
v Loop
§ Accept new connection(ConnectionSocket)
§ Read and write data into ConnectionSocket to communicate
with client
§ Close ConnectionSocket
v Close WelcomingSocket
71
Summary
our study of network apps now complete!
§ application architectures § specific protocols:
• client-server • HTTP
• P2P
• SMTP, IMAP
§ application service requirements:
• DNS
• reliability, bandwidth, delay
§ Internet transport service model • P2P: BitTorrent, DHT
• connection-oriented, reliable: § video streaming, CDNs
TCP § socket programming:
• unreliable, datagrams: UDP TCP, UDP sockets
72