COMP 445

Data Communication And

Computer Networks
Fall 2023
Dr. Abdelhak Bentaleb

1
 Lecture 6
Application Layer (Part 3)

2
Application layer: overview
▪ Principles of network ▪ P2P applications
applications ▪ socket programming with
• video streaming and UDP and TCP
content distribution
networks
▪ Web and HTTP
▪ E-mail, SMTP, IMAP
▪ The Domain Name System
DNS

3
E-mail user
agent
Three major components: mail user
server
▪ user agents agent

▪ mail servers SMTP mail user

server agent
▪ simple mail transport protocol: SMTP SMTP
SMTP user
User Agent mail agent
▪ a.k.a. “mail reader” server
user
▪ composing, editing, reading mail messages agent
user
▪ e.g., Outlook, iPhone mail client agent
outgoing
▪ outgoing, incoming messages stored on message queue
server user mailbox

4
E-mail: mail servers user
agent
mail servers: mail user
server agent
▪ mailbox contains incoming
messages for user SMTP mail user
server agent
▪ message queue of outgoing (to be SMTP
sent) mail messages user
SMTP agent
SMTP protocol between mail mail
server
servers to send email messages user
agent
▪ client: sending mail server user
▪ “server”: receiving mail server agent
outgoing
message queue
user mailbox

5
Scenario: Alice sends e-mail to Bob
1) Alice uses UA to compose e-mail 4) SMTP client sends Alice’s message
message “to” bob@someschool.edu over the TCP connection to Bob's
mail server
2) Alice’s UA sends message to her
mail server using SMTP; message 5) Bob's mail server places the message
placed in message queue in Bob's mailbox
3) client side of SMTP at mail server 6) Bob's invokes his user agent to read
opens TCP connection with Bob’s mail Alice's message
server

1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
6
SMTP RFC (5321) “client”
SMTP server
“server”
SMTP server

▪ uses TCP to reliably transfer email message

initiate TCP
from client (mail server initiating connection
connection) to server, port 25 RTT
TCP connection 220
▪ direct transfer: sending server (acting like client) initiated
to receiving server HELO
SMTP
▪ three phases of transfer handshaking 250 Hello
• SMTP handshaking (greeting)
• SMTP transfer of messages SMTP
transfers
• SMTP closure
▪ command/response interaction (like HTTP) time
• commands: ASCII text •
•
220 — SMTP Service ready. ...
221 — Service closing. ...
• response: status code and phrase •
•
250 — Requested action taken and completed. ...
354 — Start message input and end with … ...
• 421 — The service is not available, and the connection
will be closed. 7
Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... 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
8
SMTP: observations
comparison with HTTP: ▪ SMTP uses persistent
connections
▪ HTTP: client pull
▪ SMTP server uses
▪ SMTP: client push CRLF.CRLF to determine
▪ both have ASCII command/response end of message
interaction, status codes
▪ HTTP: each object encapsulated in its
own response message
▪ SMTP: multiple objects sent in
multipart message

9
Mail message format
SMTP: protocol for exchanging e-mail messages, defined in RFC 5321
(like RFC 7231 defines HTTP)
RFC 2822 defines syntax for e-mail message itself (like HTML defines
syntax for web documents)
▪ header lines, e.g., header
blank
• To: line
• From:
• Subject:
these lines, within the body of the email body
message area different from SMTP MAIL FROM:,
RCPT TO: commands!
▪ Body: the “message” , ASCII characters only
10
 Retrieving email: mail access protocols
user
e-mail access user
SMTP SMTP protocol
agent agent
(e.g., IMAP,
HTTP)

sender’s e-mail receiver’s e-mail

server server

▪ SMTP: delivery/storage of e-mail messages to receiver’s server

▪ mail access protocol: retrieval from server
• IMAP: Internet Mail Access Protocol [RFC 3501]: messages stored on server, IMAP
provides retrieval, deletion, folders of stored messages on server
▪ HTTP: gmail, Hotmail, Yahoo!Mail, etc. provides web-based interface on
top of STMP (to send), IMAP (or POP) to retrieve e-mail messages
11
Application Layer: Overview
▪ Principles of network ▪ P2P applications
applications
▪ socket programming with
• video streaming and UDP and TCP
content distribution
networks
▪ Web and HTTP
▪ E-mail, SMTP, IMAP
▪ The Domain Name System
DNS

12
DNS: Domain Name System
people: many identifiers: Domain Name System (DNS):
• SSN, name, passport # ▪ distributed database implemented in
Internet hosts, routers: hierarchy of many name servers
• IP address (32 bit) - used for ▪ application-layer protocol: hosts, DNS
addressing datagrams servers communicate to resolve
• “name”, e.g., cs.umass.edu - names (address/name translation)
used by humans
• note: core Internet function,
Q: how to map between IP implemented as application-layer
address and name, and vice protocol
versa ?
• complexity at network’s “edge”

13
 DNS: services, structure
DNS services: Q: Why not centralize DNS?
▪ hostname-to-IP-address translation ▪ single point of failure
▪ host aliasing ▪ traffic volume
▪ mail server aliasing ▪ distant centralized database
▪ load distribution ▪ maintenance
• replicated web servers: many IP
addresses correspond to one name
A: doesn‘t scale!
▪ Comcast DNS servers alone:
600B DNS queries/day
▪ Akamai DNS servers alone:
2.2T DNS queries/day

14
Thinking about the DNS
humongous distributed database:
▪ ~ billion records, each simple
handle many trillions of queries/day:
▪ many more reads than writes.
▪ performance matters: almost every
Internet communication interaction
with DNS - msecs count!
organizationally , physically decentralized:
▪ millions of different organizations
responsible for their records

“bulletproof”: reliability, security

15
 DNS: a distributed, hierarchical database
Root DNS Servers Root
… …
.com DNS servers .org DNS servers .edu DNS servers Top Level Domain
… … … …
yahoo.com amazon.com pbs.org nyu.edu umass.edu
DNS servers DNS servers DNS servers DNS servers DNS servers Authoritative

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

▪ client queries 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
16
DNS: root name servers
▪ official, contact-of-last-resort by
name servers that can not
resolve name

17
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 it!
• DNSSEC – provides security
(authentication, message integrity)
▪ ICANN (Internet Corporation for
Assigned Names and Numbers)
manages root DNS domain

18
Top-Level Domain, and 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

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

19
Local DNS name servers
• when host makes DNS query, its sent to its local DNS server
• Local DNS server returns reply, answering:
- form its local cache of recent name-to-address translation pair (possible
out of data)
- forwarding request into DNS hierarchy for resolution

• Why Local DNS server: reduce response time

• each ISP has local DNS name server; to find yours:

- MacOS: scutil --dns
• Windows: >ipconfig /all

20
DNS name resolution: iterated query
root DNS server
Example: host at engineering.nyu.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 engineering.nyu.edu dns.nyu.edu
gaia.cs.umass.edu
▪ “I don’t know this name, 7 6
but ask this server”
authoritative DNS server
dns.cs.umass.edu

21
DNS name resolution: recursive query
root DNS server
Example: host at engineering.nyu.edu
wants IP address for gaia.cs.umass.edu 2 3

7 6
Recursive query: 1 TLD DNS server
▪ puts burden of name 8
resolution on requesting host at local DNS server
5 4
engineering.nyu.edu dns.nyu.edu
contacted name gaia.cs.umass.edu

server
▪ heavy load at upper authoritative DNS server
levels of hierarchy? dns.cs.umass.edu

22
Caching DNS Information (Local DNS Servers)
▪ Once local name server learns mapping, it caches mapping,
and immediately returns a cached mapping in response to a
query
• caching improves response time
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers. To avoid passing by root
server → which we should protect.
▪ cached entries may be out-of-date
• if named host changes IP address, may not be known Internet-wide until all
TTLs expire!
• best-effort name-to-address translation! -→ Just TTL, there is no
costly/complicated mechanism to delete out-of-the-date entries from caches.
23
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
▪ value is IP address “canonical” (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)
type=MX
• value is hostname of
authoritative name ▪ value is name of mailserver
server for this domain associated with name

24
An example (DNS record)
▪ Root Server
• .com: [IP address of .com TLD server], A • .com: 162.11.144.15, A
• .org: [IP address of .org TLD server], A • .org: 170.33.17.28, A
• .net: [IP address of .net TLD server], A • etc
• .jp: [IP address of .jp TLD server], A
• .ca: [IP address of .ca TLD server], A

▪ TDL Server
• example1.com: [authoritative name server], NS • concordia.ca: dns1.concordia.ca, NS
• example2.com: [authoritative name server], NS • www.concordia.ca: dns1.concordia.ca, NS
• mail.example.com: [authoritative name server], NS • mail.concordia.ca: dns2.concordia.ca, NS
• dns1.example.com: [authoritative name server IP address], A • dns1.concordia.ca: 172.186.5.4, A
• dns2.example2.com: [authoritative name server IP address], A • dns2.concordia.ca: 172.186.5.5, A

25
An example (DNS record)
▪ Authoritative Server
• concordia.ca: 111.13.188.87, A
• example1.com: [IP address of hostname], A
• mail.concordia.ca: 111.13.188.88, A
• example2.com: [IP address of hostname], A
• etc
• example3.com: [mail server name], MX • concordia3.ca: mail.concordia.ca, MX
• example4.com: [mail server name], MX • concordia4.ca: mail.concordia.ca, MX

• example5.com: [canonical name], CNAM

• example6.com: [canonical name], CNAM • concordia.encs.ca: rely1.west.concrodia.encs.ca, CNAM

▪ Local Cache: (all entries for Root, TLD and Authoritative)

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

27
 See it in action during the
LAB using Wireshark
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
28
 Example of a DNS DNS Response Message:
1.Header Section:

query and response 1. Transaction ID: Same as in the query.

2. Flags: Response (QR = 1), Recursion Desired (RD = 1),
Recursion Available (RA = 1)
3. Response Code: No Error (0)
4. Questions: Number of queries in this message (1)
DNS Query Message: 5. Answer RRs: Number of resource records in the Answer
1.Header Section: Section (1 in this case)
1. Transaction ID: Randomly generated identifier for this query. 6. Authority RRs: Number of resource records in the Authority
2. Flags: Query (QR = 0), Recursion Desired (RD = 1) Section (0)
3. Questions: Number of queries in this message (1 in this case) 7. Additional RRs: Number of resource records in the Additional
4. Answer RRs, Authority RRs, Additional RRs: Set to 0 in queries. Section (0)
2.Question Section: 2.Question Section:
1. Name: "www.example.com" 1. Copied from the query.
2. Type: A (IPv4 address record) 3.Answer Section:
3. Class: IN (Internet) 1. Name: "www.example.com"
2. Type: A
3. Class: IN
4. TTL (Time to Live): A numerical value representing how long
this answer can be cached.
5. Data Length: Length of the data field (usually 4 bytes for IPv4
Wireshark example: https://cabulous.medium.com/dns- addresses).
message-how-to-read-query-and-response-message- 6. IPv4 Address: The actual IP address associated with
cfebcb4fe817 "www.example.com" (e.g., 192.168.1.1).
 Getting your info into the 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 two RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

▪ create authoritative server type A record for www.networkuptopia.com;

type MX record for networkutopia.com

30
 DNS security
DDoS attacks redirect attacks
▪ bombard root servers with traffic ▪ man-in-middle
• not successful to date • Intercept queries
• traffic filtering ▪ DNS poisoning
• local DNS servers cache IPs of TLD ▪ Send bogus relies to DNS server,
servers, allowing root server bypass which caches
▪ bombard TLD servers exploit DNS for DDoS
• potentially more dangerous ▪ send queries with spoofed
source address: target IP
▪ requires amplification

31