CPS 472/572 Computer Networking

Lecture 6: Email, FTP, DNS

Applications

Dr. Jennifer Seitzer

Motivation:

The Domain Name System is a distributed database that performs the binding of alphanumeric symbolic names to IP addresses. Because protocols of layers 3, 4, and 5 of the TCP/IP protocol stack use IP addresses (not domain names), this utility is used ubiquitously - many times unbeknownst to the user.

Tonight, we discuss this commonly used utility that exemplifies the client server paradigm. We study the structure of the Domain Name System as well as the structure of domain names. We discuss how resolution takes place between host application and DNS server, and how, at times, the DNS server becomes a client to a higher level DNS server.

Readings: Chapter 2

ftp: the file transfer protocol

r transfer file to/from remote host

r client/server model

m client: side that initiates transfer (either to/from remote)

m server: remote host

r ftp: RFC 959

r ftp server: port 21

ftp: separate control, data connections

r ftp client contacts ftp server at port 21, specifying TCP as transport protocol

r two parallel TCP connections opened:

m control: exchange commands, responses between client, server.

“out of band control”

m data: file data to/from server

r ftp server maintains “state”: current directory, earlier authentication

ftp commands, responses

Sample commands:

r sent as ASCII text over control channel

r USER username

r PASS password

r LIST return list of file in current directory

r RETR filename retrieves (gets) file

r STOR filename stores (puts) file onto remote host

Sample return codes

r status code and phrase (as in http)

r 331 Username OK, password required

r 125 data connection already open; transfer starting

r 425 Can’t open data connection

r 452 Error writing file

Electronic Mail

Three major components:

r user agents

r mail servers

r simple mail transfer protocol: smtp

User Agent

r a.k.a. “mail reader”

r composing, editing, reading mail messages

r e.g., Eudora, Outlook, elm, Netscape Messenger

r outgoing, incoming messages stored on server

Electronic Mail: mail servers

Mail Servers

r mailbox contains incoming messages (yet to be read) for user

r message queue of outgoing (to be sent) mail messages

r smtp protocol between mail servers to send email messages

m client: sending mail server

m “server”: receiving mail server

Electronic Mail: smtp [RFC 821]

r uses tcp to reliably transfer email msg from client to server, port 25

r direct transfer: sending server to receiving server

r three phases of transfer

m handshaking (greeting)

m transfer of messages

m closure

r command/response interaction

m commands: ASCII text

m response: status code and phrase

r messages must be in 7-bit ASCII

Sample smtp interaction

try smtp interaction for yourself:

r telnet servername 25

r see 220 reply from server

r enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands

above lets you send email without using email client (reader)

smtp: final words

r smtp uses persistent connections

r smtp requires that message (header & body) be in 7-bit ascii

r certain character strings are not permitted in message (e.g., CRLF.CRLF). Thus message has to be encoded (usually into either base-64 or quoted printable)

r smtp server uses CRLF.CRLF to determine end of message

Comparison with http

r http: pull

r email: push

r both have ASCII command/response interaction, status codes

r http: each object is encapsulated in its own response message

r smtp: multiple objects message sent in a multipart message

Mail message format

smtp: protocol for exchanging email msgs

RFC 822: standard for text message format:

r header lines, e.g.,

m To:

m From:

m Subject:

different from smtp commands!

r body

m the “message”, ASCII characters only

Message format: multimedia extensions

r MIME: multimedia mail extension, RFC 2045, 2056

r additional lines in msg header declare MIME content type

MIME types
Content-Type: type/subtype; parameters

Text

r example subtypes: plain, html

Image

r example subtypes: jpeg, gif

Audio

r exampe subtypes: basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding)

Video

r example subtypes: mpeg, quicktime

Application

r other data that must be processed by reader before “viewable”

r example subtypes: msword, octet-stream

Multipart Type

Mail access protocols

r SMTP: delivery/storage to receiver’s server

r Mail access protocol: retrieval from server

m POP: Post Office Protocol [RFC 1939]

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

m IMAP: Internet Mail Access Protocol [RFC 1730]

• more features (more complex)

• manipulation of stored msgs on server

m HTTP: Hotmail , Yahoo! Mail, etc.

POP3 protocol

authorization phase

r client commands:

m user: declare username

m pass: password

r server responses

m +OK

m -ERR

transaction phase, client:

r list: list message numbers

r retr: retrieve message by number

r dele: delete

r quit

Domain Name System

r IP - assigns 32-bit addresses to hosts (NIC’s)

r Binary addresses - easy for computers to manage

r protocols - all protocol software from layer 3 and up uses the IP address, not the symbolic name

r applications - use IP addresses through the TCP/IP protocol software

r Difficult for humans to remember:

% telnet 134.82.11.70

r The Domain Name System (DNS) - provides translation between symbolic names and IP addresses

Structure of DNS names

r Domain name - consists of a sequence of alphanumeric components separated by periods (dots)

r Examples:

m www.udayton.edu

m homepages.udayton.edu/~seitzer/cps472

m leonardo.cs.purdue.edu

r hierarchical - Names are hierarchical, with most-significant component on the right

r Left-most component is computer name

DNS naming structure

Top level domains (right-most components; also known as TLDs) defined by global authority

IAHC

r International Ad-hoc committee formed to pursue enhancements in the administration and use of the "international" Top Level Domain name space (iTLD).

r The IAHC has developed recommendations for enhancement to "generic" Top Level Domains (gTLDs) administration and operation

r TLDs .com, .org, and .net are currently referred to as "international" but are more appropriately called "generic”

r (gTLDs); only .int represents a truly international portion of the name space.

r Current difficulties with gTLDs are highly exacerbated by inadequate use of the .us TLD and the IAHC requests that scaleable and functional Second-Level Domains (SLDs) for .us be defined and used, in the spirit of those that already exist for many other ISO 3166-based TLDs.

ICANN

Internet Corporation for Assigned Names and Numbers

r New organization: just started 1998

r Private, non-profit organization

r Responsible for

m Protocol parameter assignement

m Domain name system

m Root server system

m IP address allocation

DNS naming structure

r Organizations apply for names in a top-level domain:

• udayton.edu

• macdonalds.com

r Organizations determine own internal structure

• cps.udayton.edu

• cs.purdue.edu

Geographic structure

r Top-level domains are US-centric

r Geographic TLDs used for organizations in other countries (gTLD’s are also expanded as ‘generic TLDs’

• TLD Country

.uk United Kingdom

.fr France

.ch Switzerland

.in India

r Countries define their own internal hierarchy: ac.uk and .edu.au are used for academic organizations in the United Kingdom and Australia

Organizational Domain Names

r Organizations can create any internal DNS hierarchy

r Uniqueness of TLD and organization name guarantee uniqueness of any internal name (much like file names in your directories)

r All but the left-most component of a domain name is called the domain for that name:

titan.cps.udayton.edu

homepages.udayton.edu

regulus.eg.bucknell.edu

lab113.netlab

Organizational Domain Names

r Authority for creating new subdomains is delegated to each domain

r Administrator of udayton.edu has authority to create cps.udayton.edu and need not contact any central naming authority

DNS names and physical location

r DNS domains are logical concepts and need not correspond to physical location of organizations

r DNS domain for an organization can span multiple networks

r udayton.edu covers all networks at the University of Dayton

r www.netbook.cs.purdue.edu is housed in Pennsylvania at Bucknell University

r laptop.cps.udayton.edu could be connected to a network in California

DNS and client-server computing

r DNS names are managed by a hierarchy of DNS servers

r Hierarchy is related to DNS domain hierarchy

r Root server at top of tree knows about next level servers

r Next level servers, in turn, know about lower level servers

Choosing DNS server architecture

r Small organizations can use a single server

• Easy to administer

• Inexpensive

• BUT-- may get lots of traffic

r Large organizations often use multiple servers

• Reliability through redundancy

• Improved response time through load-sharing

• Delegation of naming authority

r Locality of reference applies - users will most often look up names of computers within same organization (spatial locality of reference) AND will tend to access the same node more than once in given time period (temporal)… CACHING is used

Name Resolution

r Name resolution - the process of binding an alphanumeric name to an IP address

r Resolver software typically available as library procedures

m Implement DNS application protocol

m Configured for local servers

m Example - UNIX gethostbyname

r Resource Record - the entity stored in DNS databases and returned in DNS responses

Resource Records

r 5-tuple:

(domain name, TTL, class, Type, Value)

Name Resolution - 2 types

r Authoritative record - comes form the authority that manages the record (the DNS parent of a node)

r Cached record - a previously acquired authoritative record which may be out of date

Name Resolution messages

r DNS request contains name to be resolved

r DNS reply contains IP address for the name in the request

Name Resolution - 2 forms

r Iterative Resolution - if query fails locally, the query fails and the name of the next server along the path to try is returned.

r Recursive Resolution - if query fails locally, the originator is not notified and the hierarchy of DNS servers is traversed in a recursive manner.

DNS servers

r Each DNS server is the authoritative server for the names it manages

r If request contains name managed by receiving server, that server replies directly

r Otherwise, request must be forwarded to the appropriate authoritative server

Using DNS servers

r DNS request is forwarded to root server, which points at next server to use

r Eventually, authoritative server is located and IP address is returned

r DNS server hierarchy traversal is called iterative resolution

r Applications use recursive iteration and ask DNS server to handle traversal so they do not have to perform the series of requests

Recursive Name Resolution

r Calling program is client

m Constructs DNS protocol message - a DNS request

m Sends message to local DNS server

r DNS server resolves name

m Constructs DNS protocol message - a DNS reply

m Sends message to client program and waits for next request

r if request is for a name not in the server, the DNS server becomes a client to a root server.

m Root server - becomes the client of the at the next level down

m repeats until authoritative answer is received by the local DNS server, which then forwards to host.

Iterative Name Resolution

r Calling program is client

m Constructs DNS protocol message - a DNS request

m Sends message to local DNS server

r DNS server resolves name

m Constructs DNS protocol message - a DNS reply

m Sends message to client program and waits for next request

r if request is for a name not in the server, the DNS server becomes a client to a root server.

m Root server - returns a response containing the address of the next level down server

m client then sends a request to this one

m repeats until authoritative answer is received.

DNS caching

r DNS resolution can be very inefficient

m Every host referenced by name triggers a DNS request

m Every DNS request for the address of a host in a

m different organization goes through the root server

r Servers and hosts use caching to reduce the number of DNS requests

m Cache is a list of recently resolved names and IP addresses

m Authoritative server include time-to-live with each reply

Types of DNS entries

r DNS can hold several types of records

r Each record includes

• Domain name

• Record type

• Data value

r record type - specifies how the value is to be interpreted.

r Type A record maps from domain name to IP address

• Domain name - regulus

• Record type - A

• Data value - 134.82.11.70

Types of DNS entries

r Other types:

m MX (Mail eXchanger) - maps domain name used as e-mail destination to IP address

m CNAME - alias from one domain name to another

r Result - name that works with one application may not work with another!

r More than one entry - a host may have more than one entry

CNAME Entries

r Alias

r very useful

r analogous to a symbolic link in a file system

r CNAME entry - provides an alias for another DNS entry.

r Popular CNAME entry - www.<orgname> .suffix

r permits an organization to change the computer used for a particular service without changing the names or addresses of the computers.

Example: CNAME

r CNAME - alias from one domain name to another

r RECALL---- 5-tuple schema:
(domain name, TTL, class, Type, Value)

r (www.mit.edu 86400 IN CNAME lcs.mit.edu)

r Web requests sent to www.mit.edu will be sent to lcs.mit.edu

Types of DNS entries: MX

r specifies the name of the host prepared to accept email for a specified domain

r sample scenario: An entrepreneur starts an e-business, but does not support a mail server and uses her old university’s.

r RECALL---- 5-tuple schema:
(domain name, TTL, class, Type, Value)

(electrobrain.com, 86400, IN, MX, mailserver.cs.ucla.edu)

Abbreviations

r May be convenient to use abbreviations for local computers; e.g. titan for titan.cps.udayton.edu

m Abbreviations are handled in the resolver; DNS servers only know full-qualified domain names (FQDNs)

m Local resolver is configured with list of suffixes to append

m Suffixes are tried sequentially until match found

DNS: Domain Name System

People: many identifiers:

m SSN, name, Passport #

Internet hosts, routers:

m IP address (32 bit) - used for addressing datagrams

m “name”, e.g., gaia.cs.umass.edu - used by humans

Q: map between IP addresses and name ?

r distributed database implemented in hierarchy of many name servers

r application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation)

m note: core Internet function implemented as application-layer protocol

m complexity at network’s “edge”

DNS name servers

r no server has all name-to-IP address mappings

local name servers:

m each ISP, company has local (default) name server

m host DNS query first goes to local name server

authoritative name server:

m for a host: stores that host’s IP address, name

m can perform name/address translation for that host’s name

Why not centralize DNS?

r single point of failure

r traffic volume

r distant centralized database

r maintenance

doesn’t scale!

DNS: Root name servers

r contacted by local name server that can not resolve name

r root name server:

m contacts authoritative name server if name mapping not known

m gets mapping

m returns mapping to local name server

r ~ dozen root name servers worldwide

Simple DNS example

host surf.eurecom.fr wants IP address of gaia.cs.umass.edu

1. Contacts its local DNS server, dns.eurecom.fr

2. dns.eurecom.fr contacts root name server, if necessary

3. root name server contacts authoritative name server, dns.umass.edu, if necessary

DNS example

Root name server:

r may not know authoratiative name server

r may know intermediate name server: who to contact to find authoritative name server