2: Application Layer

1
 2: Application Layer

 2.1 Principles of network  2.6 P2P file sharing

applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP  2.9 Building a Web server
 2.5 DNS

2
 2: Application Layer

 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P

3
 2: Application Layer

server:
 always-on host
 permanent IP address
 server farms for scaling
clients:
 communicate with server
 may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
directly with each other

4
 2: Application Layer

 no always-on server
 arbitrary end systems
directly communicate
 peers are intermittently
connected and change IP
addresses
 example: Gnutella

Highly scalable but difficult to

manage

5
 2: Application Layer

Skype
 Internet telephony app
 Finding address of remote party: centralized server(s)
 Client-client connection is direct (not through server)
Instant messaging
 Chatting between two users is P2P
 Presence detection/location centralized:
 User registers its IP address with central server when it comes online
 User contacts central server to find IP addresses of buddies

6
 2: Application Layer

Process: program running Client process: process that

within a host. initiates communication
 within same host, two Server process: process that
processes communicate waits to be contacted
using inter-process
communication (defined by
OS).
 processes in different hosts  Note: applications with
communicate by P2P architectures have
exchanging messages client processes &
server processes

7
 2: Application Layer

host or host or
 process sends/receives server server
messages to/from its socket
controlled by
 socket analogous to door app developer
process process
 sending process shoves(push)
message out door socket socket
 sending process relies on TCP with TCP with
buffers, Internet buffers,
transport infrastructure on other
variables variables
side of door which brings
message to socket at receiving
process controlled
by OS

 API: (1) choice of transport protocol; (2) ability to fix

a few parameters (lots more on this later)
8
 2: Application Layer

 to receive messages,
process must have
identifier
 host device has unique32-
bit IP address
 Q: does IP address of host
on which process runs
suffice for identifying the
process?

9
 2: Application Layer

 to receive messages,  identifier includes both IP

process must have address and port numbers
identifier associated with process on
 host device has unique32- host.
bit IP address  Example port numbers:
 Q: does IP address of host  HTTP server: 80
on which process runs  Mail server: 25
suffice for identifying the  to send HTTP message to
process? gaia.cs.umass.edu web
 Answer: NO, many server:
processes can be running on  IP address: 128.119.245.12
same host  Port number: 80
 more shortly…
10
 2: Application Layer

 Types of messages Public-domain protocols:

exchanged,  defined in RFCs
 e.g., request, response  allows for interoperability
 Message syntax:  e.g., HTTP, SMTP
 what fields in messages &
how fields are delineated Proprietary protocols:
 e.g., KaZaA
 Message semantics
 meaning of information in
fields
 Rules for when and how
processes send & respond
to messages
11
 2: Application Layer

Data loss Bandwidth

 some apps (e.g., audio) can
 some apps (e.g.,
tolerate some loss multimedia) require
 other apps (e.g., file transfer,
minimum amount of
telnet) require 100% reliable bandwidth to be
data transfer “effective”
 other apps (“elastic
Timing
apps”) make use of
 some apps (e.g., Internet
whatever bandwidth
telephony, interactive
they get
games) require low delay
to be “effective”

12
 2: Application Layer

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
instant messaging no loss elastic yes and no

13
 2: Application Layer

TCP service: UDP service:

 connection-oriented: setup  unreliable data transfer
required between client and server between sending and
processes receiving process
 reliable transport between  does not provide: connection
sending and receiving process setup, reliability, flow control,
 flow control: sender won’t congestion control, timing, or
overwhelm receiver bandwidth guarantee
 congestion control: throttle sender
when network overloaded Q: why bother? Why is there a
 does not provide: timing, UDP?
minimum bandwidth guarantees

14
 2: Application Layer

Application Underlying
Application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia proprietary TCP or UDP
(e.g. RealNetworks)
Internet telephony proprietary
(e.g., Vonage,Dialpad) typically UDP

15
 2: Application Layer

 2.1 Principles of network  2.6 P2P file sharing

applications  2.7 Socket programming
 app architectures with TCP
 app requirements  2.8 Socket programming
 2.2 Web and HTTP with UDP
 2.4 Electronic Mail  2.9 Building a Web server
 SMTP, POP3, IMAP
 2.5 DNS

16
 2: Application Layer

First some jargon

 Web page consists of objects

 Object can be HTML file, JPEG image, Java applet, audio file,…

 Web page consists of base HTML-file which includes several

referenced objects
 Each object is addressable by a URL

 Example URL:

www.someschool.edu/someDept/pic.gif

host name path name

17
 2: Application Layer

HTTP: hypertext transfer

protocol HT
TP
req
 Web’s application layer protocol PC running HT ues
TP t
Explorer re sp
 client/server model ons
e
 client: browser that requests,

receives, “displays” Web st

que
objects e
TPr on se Server
 server: Web server sends HT r es
p running
TP Apache Web
objects in response to requests HT
server
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2068 Mac running
Navigator

18
 2: Application Layer

Uses TCP: HTTP is “stateless”

 client initiates TCP connection  server maintains no
(creates socket) to server, port 80 information about past
 server accepts TCP connection client requests
from client
aside
 HTTP messages (application- Protocols that maintain
layer protocol messages) “state” are complex!
exchanged between browser  past history (state) must
(HTTP client) and Web server be maintained
(HTTP server)  if server/client crashes,
 TCP connection closed their views of “state” may
be inconsistent, must be
reconciled

19
 2: Application Layer

Nonpersistent HTTP Persistent HTTP

 At most one object is sent  Multiple objects can be sent

over a TCP connection. over single TCP connection

 HTTP/1.0 uses nonpersistent between client and server.
HTTP  HTTP/1.1 uses persistent

connections in default mode

20
 2: Application Layer

(contains text,
Suppose user enters URL www.someSchool.edu/someDepartment/home.index
references to 10
jpeg images)

1a. HTTP client initiates TCP

connection to HTTP server (process)
at www.someSchool.edu on port
1b. HTTP server at host
www.someSchool.edu waiting
80
for TCP connection at port 80.
“accepts” connection,
notifying client
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection 3. HTTP server receives request
socket. Message indicates message, forms response
that client wants object message containing requested
someDepartment/home.index object, and sends message
into its socket

time
21
 2: Application Layer

4. HTTP server closes TCP

connection.
5. HTTP client receives response
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

time 6. Steps 1-4 repeated for each

of 10 jpeg objects

22
 2: Application Layer

Definition of RTT: time to send

a small packet to travel from
client to server and back.
initiate TCP
Response time: connection
 one RTT to initiate TCP RTT
connection request
file
 one RTT for HTTP request time to
RTT
transmit
and first few bytes of HTTP file
response to return file
received
 file transmission time

total = 2RTT+transmit time time time

23
 2: Application Layer

Nonpersistent HTTP issues: Persistent without pipelining:

 requires 2 RTTs per object  client issues new request only
 OS overhead for each TCP when previous response has
connection been received
 browsers often open parallel
 one RTT for each referenced
TCP connections to fetch object
referenced objects Persistent with pipelining:
Persistent HTTP  default in HTTP/1.1
 server leaves connection open  client sends requests as soon as
after sending response it encounters a referenced
 subsequent HTTP messages object
between same client/server sent  as little as one RTT for all the
over open connection referenced objects

24
 2: Application Layer

 two types of HTTP messages: request, response

 HTTP request message:
 ASCII (human-readable format)

request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return,
line feed (extra carriage return, line feed)
indicates end
of message
25
2: Application Layer

26
 2: Application Layer

Post method: URL method:

 Web page often includes  Uses GET method
form input  Input is uploaded in URL
 Input is uploaded to server in
field of request line:
entity body

www.somesite.com/animalsearch?monkeys&banana

27
 2: Application Layer

The first line of an HTTP request message is called the

request line; the subsequent lines are called the header
lines. The request line has three fields: the method
field, the URL field, and the HTTP version field.

HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD

 POST  PUT

 HEAD
 uploads file in entity body to path
specified in URL field
 asks server to leave requested
object out of response
 DELETE
 deletes file specified in the URL
field
28
 2: Application Layer

 The GET method is used when the browser requests an

object, with the requested object identified in the URL field.
 An HTTP client often uses the POST method when the
user fills out a form—for example, when a user provides
search words to a search engine.
 With a POST message, the user is still requesting a Web
page from the server, but the specific contents of the Web
page depend on what the user entered into the form fields.

29
 2: Application Layer

 The HEAD method is similar to the GET method. When a

server receives a request with the HEAD method, it
responds with an HTTP message but it leaves out the
requested object. Application developers often use the
HEAD method for debugging.
 The PUT method is often used in conjunction with Web
publishing tools. It allows a user to upload an object to a
specific path (directory) on a specific Web server.
 The PUT method is also used by applications that need to
upload objects to Web servers.
 The DELETE method allows a user, or an application, to
delete an object on a Web server.
30
 2: Application Layer

status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
header Server: Apache/1.3.0 (Unix)
lines Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html

data, e.g., data data data data data ...

requested
HTML file

31
 2: Application Layer

In first line in server->client response message.

A few sample codes:
200 OK
 request succeeded, requested object later in this message
301 Moved Permanently
 requested object moved, new location specified later in this message
(Location:)
400 Bad Request
 request message not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported
32
 2: Application Layer

1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 Opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu

2. Type in a GET HTTP request:

GET /~ross/ HTTP/1.1 By typing this in (hit carriage
Host: cis.poly.edu return twice), you send
this minimal (but complete)
GET request to HTTP server

3. Look at response message sent by HTTP server!

33
 2: Application Layer

Many major Web sites use Example:

cookies  Susan access Internet always
Four components: from same PC
 She visits a specific e-commerce
1) cookie header line of HTTP
site for first time
response message
 When initial HTTP requests
2) cookie header line in HTTP
arrives at site, site creates a
request message
unique ID and creates an entry in
3) cookie file kept on user’s host, backend database for ID
managed by user’s browser
4) back-end database at Web site

34
 2: Application Layer

client server
Cookie file usual http request msg server ne
da try i
ta b n b
usual http response + creates ID as ac
e ke
ebay: 8734 Set-cookie: 1678 1678 for user nd

Cookie file
usual http request msg
amazon: 1678 cookie: 1678 cookie- s s
ebay: 8734 specific acce
usual http response msg action

s
one week later:

s
ce
ac
usual http request msg
Cookie file cookie-
cookie: 1678
amazon: 1678 spectific
ebay: 8734 usual http response msg action

35
 2: Application Layer

aside
What cookies can bring: Cookies and privacy:
 authorization  cookies permit sites to
 shopping carts learn a lot about you
 recommendations  you may supply name
 user session state (Web e-mail) and e-mail to sites

How to keep “state”:

 Protocol endpoints:
maintain state at
sender/receiver over
multiple transactions
 cookies: http messages
carry state
36
 2: Application Layer

Goal: satisfy client request without involving origin server

 user sets browser: Web origin
accesses via cache server
 browser sends all HTTP HT Proxy
requests to cache TP
req server ques t
H u P re
T
client TP e st T T on se
 object in cache: cache H p
res
pon P res
returns object se H TT
e st
 else cache requests object u
P req n se
from origin server, then T p o
HT res
returns object to client TP
HT

client
origin
server

37
 2: Application Layer

 Cache acts as both client and server Why Web caching?

 Typically cache is installed by ISP  Reduce response time for client
(university, company, residential request.
ISP)  Reduce traffic on an institution’s
access link.
 Internet dense with caches: enables
“poor” content providers to
effectively deliver content

38
 2: Application Layer

Assumptions origin
 average object size = 100,000 bits servers
 avg. request rate from institution’s
public
browsers to origin servers = 15/sec
Internet
 delay from access link router to any origin
server and back to router = 2 sec
Consequences
 Utilization or traffic intensity, I=∆β, where 1.5 Mbps
β is an average arrival rate, ∆ is an average access link
transmission time which is L/R. institutional
 utilization on LAN = 15% and utilization network
10 Mbps LAN
on access link = 100%
 total delay = Internet delay + access delay
+ LAN delay
 Average delay=∆/(1-I),
= 2 sec + minutes + milliseconds

39
 2: Application Layer

origin
Possible solution
servers
 increase bandwidth of access link
public
to, say, 10 Mbps
Internet
Consequences
 utilization on LAN = 15%
 utilization on access link = 15%
10 Mbps
 Total delay = Internet delay + access access link
delay + LAN delay
institutional
= 2 sec + msecs + msecs network
10 Mbps LAN
 often a costly upgrade

40
 2: Application Layer

origin
Install cache servers
 suppose hit rate is .4 public
Consequence Internet
 40% requests will be satisfied
almost immediately
 60% requests satisfied by origin
server 10 Mbps
access link
 utilization of access link reduced
to 60%, resulting in negligible institutional
delays (say 10 msec) network
10 Mbps LAN
 total avg delay = Internet delay
+ access delay + LAN delay
= .6*(2.01) secs
+ .4*milliseconds = 1.21 secs
institutional
cache

41
 2: Application Layer

 Goal: don’t send object if cache cache server

has up-to-date cached version HTTP request msg
 cache: specify date of cached If-modified-since:
object
<date>
copy in HTTP request not
If-modified-since:
HTTP response modified
<date>
HTTP/1.0
 server: response contains no 304 Not Modified
object if cached copy is up-to-
date:
HTTP request msg
HTTP/1.0 304 Not If-modified-since:
Modified <date> object
modified
HTTP response
HTTP/1.0 200 OK
<data>
42
 2: Application Layer

 2.1 Principles of network  2.6 P2P file sharing

applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP  2.9 Building a Web server
 2.5 DNS

43
 2: Application Layer

FTP file transfer

FTP FTP
user client server
interface
user
at host local file remote file
system system

 transfer file to/from remote host

 client/server model
 client: side that initiates transfer (either to/from remote)

 server: remote host

 ftp: RFC 959

 ftp server: port 21

44
 2: Application Layer

TCP control connection

 FTP client contacts FTP server at port 21
port 21, specifying TCP as
transport protocol
TCP data connection
 Client obtains authorization over FTP port 20 FTP
control connection client server
 Client browses remote directory
 Server opens another TCP
by sending commands over
control connection. data connection to transfer
another file.
 When server receives file transfer
 Control connection: “out of
command, server opens 2nd TCP
connection (for file) to client band”
 FTP server maintains “state”:
 After transferring one file, server
closes data connection. current directory, earlier
authentication

45
 2: Application Layer

Sample commands: Sample return codes

 sent as ASCII text over control  status code and phrase (as in HTTP)
channel  331 Username OK, password
 USER username required
 PASS password  125 data connection
 LIST return list of file in current already open; transfer
directory starting
 425 Can’t open data
 RETR filename retrieves (gets)
connection
file  452 Error writing file
 STOR filename stores (puts)
file onto remote host

46
 2: Application Layer

 2.1 Principles of network  2.6 P2P file sharing

applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP  2.9 Building a Web server
 2.5 DNS

47
 2: Application Layer

outgoing
message queue
user mailbox
user
Three major components: agent
 user agents mail
user
 mail servers server
agent
 simple mail transfer protocol: SMTP mail
SMTP server user

User Agent
SMTP agent

 a.k.a. “mail reader” SMTP

mail user
 composing, editing, reading mail agent
server
messages
 e.g., Eudora, Outlook, elm, user
Netscape Messenger agent
 outgoing, incoming messages user
agent
stored on server
48
 2: Application Layer

user
Mail Servers agent
 mailbox contains incoming mail
user
messages for user server
agent
 message queue of outgoing (to
SMTP mail
be sent) mail messages
server user
 SMTP protocol between mail
servers to send email messages
SMTP agent

 client: sending mail server

SMTP
 “server”: receiving mail mail user
server agent
server
user
agent
user
agent

49
 2: Application Layer

 uses TCP to reliably transfer email message from client to server,

port 25
 direct transfer: sending server to receiving server
 three phases of transfer
 handshaking (greeting)

 transfer of messages

 closure

 command/response interaction
 commands: ASCII text

 response: status code and phrase

 messages must be in 7-bit ASCII

50
 2: Application Layer

1) Alice uses UA to compose 4) SMTP client sends Alice’s

message and “to” message over the TCP
[email protected] connection
2) Alice’s UA sends message to 5) Bob’s mail server places the
her mail server; message placed message in Bob’s mailbox
in message queue 6) Bob invokes his user agent to
3) Client side of SMTP opens TCP read message
connection with Bob’s mail
server

1 mail
mail
server user
user server
2 agent
agent 3 6
4 5

51
 2: Application Layer

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

52
 2: Application Layer

 telnet servername 25
 see 220 reply from server

enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands
above lets you send email without using email client (reader)

53
 2: Application Layer

 SMTP uses persistent connections Comparison with HTTP:

 SMTP requires message (header &  HTTP: pull
body) to be in 7-bit ASCII
 SMTP: push
 SMTP server uses CRLF.CRLF to
determine end of message  both have ASCII command/response
 Pull Protocol: Someone loads interaction, status codes
information on a Web server and
users use HTTP to pull the
 HTTP: each object encapsulated in
information from the server at their its own response message.
convenience (receive file).  SMTP: multiple objects sent in
 Push Protocol: The sending mail multipart message.
server pushes the file to the
receiving mail server (send file)

54
 2: Application Layer

SMTP: protocol for exchanging email

msgs header
blank
RFC 822: standard for text message
line
format:
 header lines, e.g.,
To: body


 From:

 Subject:

different from SMTP commands!

 body
 the “message”, ASCII characters
only

55
 2: Application Layer

 MIME: multimedia mail extension, RFC 2045, 2056

 additional lines in msg header declare MIME content type

From: [email protected]
MIME version To: [email protected]
Subject: Picture of yummy crepe.
method used MIME-Version: 1.0
to encode data Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
type, subtype, base64 encoded data .....
parameter declaration .........................
......base64 encoded data
encoded data

56
 2: Application Layer

SMTP SMTP access user

user
agent protocol agent

sender’s mail receiver’s mail

server server
 SMTP: delivery/storage to receiver’s server
 Mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]

 authorization (agent <-->server) and download

 IMAP: Internet Mail Access Protocol [RFC 1730]

 more features (more complex)

 manipulation of stored msgs on server

 HTTP: Hotmail , Yahoo! Mail, etc.

57
 2: Application Layer

S: +OK POP3 server ready

C: user bob
authorization phase S: +OK
C: pass hungry
 client commands: S: +OK user successfully logged on
 user: declare username
C: list
 pass: password
S: 1 498
 server responses S: 2 912
 +OK S: .
C: retr 1
 -ERR
S: <message 1 contents>
transaction phase, client: S: .
C: dele 1
 list: list message numbers
C: retr 2
 retr: retrieve message by S: <message 1 contents>
number S: .
 dele: delete C: dele 2
 C: quit
quit
S: +OK POP3 server signing off
58
 2: Application Layer

More about POP3 IMAP

 Previous example uses  Keep all messages in one
“download and delete” place: the server
mode.  Allows user to organize
 Bob cannot re-read e-mail
messages in folders
if he changes client  IMAP keeps user state
 “Download-and-keep”:
across sessions:
copies of messages on  names of folders and
different clients mappings between message
 POP3 is stateless across IDs and folder name

sessions

59
 2: Application Layer

 2.1 Principles of network  2.6 P2P file sharing

applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP  2.9 Building a Web server
 2.5 DNS

60
 2: Application Layer

People: many identifiers: Domain Name System:

 SSN, name, passport #  distributed database implemented
Internet hosts, routers: in hierarchy of many name servers
 application-layer protocol host,
 IP address (32 bit) - used for
routers, name servers to
addressing datagrams
communicate to resolve names
 “name”, e.g., ww.yahoo.com - (address/name translation)
used by humans  note: core Internet function,
Q: map between IP addresses implemented as application-
and name ? layer protocol
 complexity at network’s

“edge”

61
 2: Application Layer

DNS services Why not centralize DNS?

 Hostname to IP address  single point of failure

translation  traffic volume

 Host aliasing  distant centralized database

 Canonical and alias names  maintenance
 Mail server aliasing
 Load distribution doesn’t scale!
 Replicated Web servers: set
of IP addresses for one
canonical name

62
 2: Application Layer

Root DNS Servers

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

Client wants IP for www.amazon.com; 1st approx:

 Client queries a root server to find com DNS server
 Client queries com DNS server to get amazon.com DNS
server
 Client queries amazon.com DNS server to get IP address
for www.amazon.com

63
 2: Application Layer

 contacted by local name server that can not resolve name

 root name server:
 contacts authoritative name server if name mapping not known

 gets mapping

 returns mapping to local name server

a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD k RIPE London (also Amsterdam,
g US DoD Vienna, VA Frankfurt)
h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3
j Verisign, ( 11 locations) other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)

13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

64
 2: Application Layer

 Top-level domain (TLD) servers: responsible for

com, org, net, edu, etc, and all top-level country
domains uk, fr, ca, jp.
 Network solutions maintains servers for com TLD
 Educause for edu TLD
 Authoritative DNS servers: organization’s DNS
servers, providing authoritative hostname to IP
mappings for organization’s servers (e.g., Web
and mail).
 Can be maintained by organization or service
provider
65
 2: Application Layer

 Does not strictly belong to hierarchy

 Each ISP (residential ISP, company, university)
has one.
 Also called “default name server”
 When a host makes a DNS query, query is sent to
its local DNS server
 Acts as a proxy, forwards query into hierarchy.

66
 2: Application Layer

root DNS server

 Host at cis.poly.edu wants 2

3
IP address for TLD DNS server
4
gaia.cs.umass.edu
5
 iterated query:
local DNS server
 contacted server replies with dns.poly.edu
name of server to contact 7 6
1 8
 “I don’t know this name,
but ask this server”
authoritative DNS server
dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

67
 2: Application Layer

root DNS server

recursive query: 2 3
 puts burden of name
resolution on 7 6
contacted name TLD DNS server
server
 heavy load?
local DNS server
dns.poly.edu 5 4

1 8

authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

68
 2: Application Layer

 once (any) name server learns mapping, it caches

mapping
 cache entries timeout (disappear) after some time

 TLD servers typically cached in local name servers

 Thus root name servers not often visited
 update/notify mechanisms under design by IETF
 RFC 2136
 http://www.ietf.org/html.charters/dnsind-charter.html

69
 2: Application Layer

DNS: distributed db storing resource records (RR)

RR format: (name, value, type, ttl)

 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. foo.com)
 value is canonical name
 value is hostname of
authoritative name server for 
this domain Type=MX
 value is name of mailserver
associated with name

70
 2: Application Layer

DNS protocol : query and reply messages, both with same message format

msg header
 identification: 16 bit #
for query, reply to query
uses same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative

71
 2: Application Layer

Name, type fields

for a query

RRs in response
to query

records for
authoritative servers

additional “helpful”
info that may be used

72
 2: Application Layer

 Example: just created startup “Network Utopia”

 Register name networkuptopia.com at a registrar (e.g.,
Network Solutions)
 Need to provide registrar with names and IP addresses of your
authoritative name server (primary and secondary)
 Registrar inserts two RRs into the com TLD server:

(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)

 Put in authoritative server Type A record for

www.networkuptopia.com and Type MX record for
networkutopia.com
 How do people get the IP address of your Web site?

73
2: Application Layer

74