Transcript Part I: Introduction

DNS: Domain Name System
People: many identifiers:

SSN, name, Passport #
Domain Name System:

distributed database

application-layer protocol
Internet hosts, routers:


IP address (32 bit) used for addressing
datagrams
“name”, e.g.,
gaia.cs.umass.edu - used
by humans
Q: map between IP
addresses and name ?
implemented in hierarchy of
many name servers
host, routers, name servers to
communicate to resolve names
(address/name translation)
 note: core Internet
function implemented as
application-layer protocol
 complexity at network’s
“edge”
1
DNS name servers
Why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized
database
 Maintenance
 DoS attacks?
 no server has all name-
to-IP address mappings
local name servers:


local (default) name server
host DNS query first goes
to local name server
authoritative name server:

doesn’t scale!
each ISP, company has

for a host: stores that
host’s IP address, name
can perform name/address
translation for that host’s
name
2
DNS: Root name servers
 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
~ dozen root name servers
worldwide
13 root DNS servers:
replication for security and
reliability
Top-level DNS server: org,
edu, com, jp,cn, fr, uk
3
Simple DNS example
root name server
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
2
4
5
local name server
dns.eurecom.fr
1
3
authorititive name server
dns.umass.edu
6
requesting host
gaia.cs.umass.edu
surf.eurecom.fr
4
DNS example
root name server
Root name server:
 may not know
7
authoratiative name
server
 may know
intermediate name
server: who to
contact to find
authoritative name
server
6
2
local name server
dns.eurecom.fr
1
8
3
intermediate name server
dns.umass.edu
4
5
authoritative name server
dns.cs.umass.edu
requesting host
surf.eurecom.fr
gaia.cs.umass.edu
5
DNS: iterated queries
recursive query:
iterated query:
 contacted server
replies with name of
server to contact
 “I don’t know this
name, but ask this
server”
iterated query
2
 puts burden of name
resolution on
contacted name
server
 heavy load?
root name server
3
4
7
local name server
dns.eurecom.fr
1
8
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
requesting host
surf.eurecom.fr
gaia.cs.umass.edu
6
DNS: caching and updating records
 once (any) name server learns mapping, it
caches
mapping
 cache entries timeout (disappear) after some
time
 update/notify mechanisms under design by IETF

RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
7
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name,
 Type=A
 name is hostname
 value is IP address
 Type=NS
 name is domain (e.g.
foo.com)
 value is IP address of
authoritative name
server for this domain
value, type,ttl)
 Type=CNAME
 name is an alias name
for some “cannonical”
(the real) name
 value is cannonical
name
 Type=MX
 value is hostname of
mailserver associated with
name
8
DNS records
For a particular hostname
 If a DNS server is authoritative, it contains

a Type A record for the hostname
 Otherwise
 Maybe a Type A record for the hostname in cache
 a Type NS record for the domain of the hostname
 a Type A record for the DNS server for that
domain
 Host: gaia.cs.umass.edu
 (umass.edu, dns.umass.edu, NS)
 (dns.umass.edu, 128.119.40.111, A)
9
DNS protocol, messages
DNS protocol : query and repy messages, both with
same message format
msg header
 identification: 16 bit # for
query, repy to query uses
same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative
10
DNS protocol, messages
Name, type fields
for a query
RRs in reponse
to query
records for
authoritative servers
additional “helpful”
info that may be used
Try nslookup?
11
Mystery: How to set up your DNS
server?
 You setup a company: mynet.com
 Step 1: register your domain name with a registrar
 Provide name and IP address mapping
 Primary authoritative DNS server: dns1.mynet.com,
212.212.212.1
 Optional: secondary DNS server: dns.mynet.com,
212.212.212.2
 Registrar will insert type NS and A records for you
 (mynet.com, dns1.mynet.com, NS)
 (dn1.mynet.com, 212.212.212.1, A)
 Step 2: insert records into your DNS server
 For web server (www.mynet.com, 212.212.212.3,A)
 For mail sever (mail.mynet.com, 212.212.212.4, MX)
 Then, others can access your web server and send emails
12
Socket programming
Goal: learn how to build client/server application that
communicate using sockets
Socket API
 introduced in BSD4.1 UNIX,
1981
 explicitly created, used,
released by apps
 client/server paradigm
 two types of transport
service via socket API:
 unreliable datagram
 reliable, byte streamoriented
socket
a host-local, applicationcreated/owned,
OS-controlled interface
(a “door”) into which
application process can
both send and
receive messages to/from
another (remote or
local) application process
13
Socket-programming using TCP
Socket: a door between application process and endend-transport protocol (UCP or TCP)
TCP service: reliable transfer of bytes from one
process to another
controlled by
application
developer
controlled by
operating
system
process
process
socket
TCP with
buffers,
variables
host or
server
internet
socket
TCP with
buffers,
variables
controlled by
application
developer
controlled by
operating
system
host or
server
14
Socket programming with TCP
Client must contact server
 server process must first
be running
 server must have created
socket (door) that
welcomes client’s contact
Client contacts server by:
 creating client-local TCP
socket
 specifying IP address, port
number of server process
 When client creates socket:
client TCP establishes
connection to server TCP
 When contacted by client,
server TCP creates new
socket for server process to
communicate with client
 allows server to talk with
multiple clients
application viewpoint
TCP provides reliable, in-order
transfer of bytes (“pipe”)
between client and server
15
Socket programming with TCP
Example client-server app:
 client reads line from
standard input, sends to
server via socket server
reads line from socket
 server converts line to
uppercase, sends back to
client
 client reads, prints modified
line from socket
Input stream: sequence of
bytes into process
Output stream: sequence of
bytes out of process
client socket
16
Client/server socket interaction: TCP
Server (running on hostid)
Client
create socket,
port=x, for
incoming request:
int s = socket(…); bind(s,…)
listen(s,5);
wait for incoming
connection request
int cs =
accept(s,….)
read request from
cs
write reply to
cs
close
cs
TCP
connection
create socket,
setup connect to hostid, port=x
int cli_socket = socket(..);
connect(s,…);
send request using
cli_socket
read reply from
cli_socket
close
cli_socket
17
Example: C++ client (TCP)
#include <stdio.h> /* Basic I/O routines */
#include <sys/types.h> /* standard system types */
#include <netinet/in.h> /* Internet address structures */
#include <sys/socket.h> /* socket interface functions */
#include <netdb.h> /* host to IP resolution */
int main(int argc, char *argv[]) {
/* Address resolution stage */
struct hostent* hen = gethostbyname(argv[1]);
if (!hen) {
perror("couldn't resolve host name");
}
struct sockaddr_in sa;
memset(&sa, 0, sizeof(sa);
sa.sin_family = AF_INET;
sa.sin_port = htons(PORT); //server port number
memcpy(&sa.sin_addr.s_addr, hen->h_addr_list[0], hen->h_length);
Create
client socket,
connect to server
}
int cli_socket = socket(AF_INET, SOCK_STREAM, 0);
assert(cli_socket >= 0); //I am just lazy here!!
connect(s, (struct sockaddr *)&sa, sizeof(sa));
write(s, argv[2], strlen(argv[2])); //send it to server
char buf[BUFLEN];
int rc;
memset(buf, 0, BUFLEN);
char* pc = buf;
while(rc = read(cli_socket, pc, BUFLEN – (pc - buf)))
pc += rc;
write(1, buf, strlen(buf));
close(cli_socket);
18
Example: C++ server (TCP)
//include header files
#define PORT 6789
int main(int argc, char* argv[]) {
struct sockaddr_in sa, csa;
memset(&sa, 0, sizeof(sa);
sa.sin_family = AF_INET;
sa.sin_port = htons(PORT);
sa.sin_addr.s_addr = INADDR_ANY; //any IP addr. Is accepted
int s = socket(AF_INET,SOCK_STREAM, 0);
assert( s>=0);
int rc = bind(s, (struct sockaddr *)& sa, sizeof(sa)); //hook s with port
rc = listen(s, 5);
int cs_socket = accept(s, (struct sockaddr*)&csa, sizeof(csa));
char buf[BUFLEN];
}
memset(buf, 0, BUFLEN);
char* pc = buf;
while(rc = read(cs_socket, pc, BUFLEN – (pc - buf)))
pc += rc;
upper_case(buf); // covert it into upper case
write(cs_socket, buf, strlen(buf));
close(cs_socket);
close(s);
19
Multi-Clients Servers
 Two main approaches to designing such servers.
 Approach 1.
 The first approach is using one process that awaits new
connections, and one more process (or thread) for each
Client already connected. This approach makes design quite
easy, cause then the main process does not need to differ
between servers, and the sub-processes are each a singleClient server process, hence, easier to implement.
 However, this approach wastes too many system resources
(if child processes are used), and complicates inter-Client
communication: If one Client wants to send a message to
another through the server, this will require communication
between two processes on the server, or locking mechanisms,
if using multiple threads.
 See tutor for details!
20
Socket programming with UDP
UDP: no “connection” between
client and server
 no handshaking
 sender explicitly attaches
IP address and port of
destination
 server must extract IP
address, port of sender
from received datagram
application viewpoint
UDP provides unreliable transfer
of groups of bytes (“datagrams”)
between client and server
UDP: transmitted data may be
received out of order, or
lost
21
Summary
Our study of network apps now complete!
 application service
requirements:

reliability, bandwidth,
delay
 client-server paradigm
 Internet transport
service model


connection-oriented,
reliable: TCP
unreliable, datagrams:
UDP
 specific protocols:
 http
 ftp
 smtp, pop3
 dns
 socket programming
 client/server
implementation
 using tcp, udp sockets
22
Summary
Most importantly: learned about protocols
 typical request/reply
message exchange:


client requests info or
service
server responds with
data, status code
 message formats:
 headers: fields giving
info about data
 data: info being
communicated
 control vs. data msgs
in-based, out-of-band
centralized vs. decentralized
stateless vs. stateful
reliable vs. unreliable msg
transfer
“complexity at network
edge”
security: authentication






23