1

DNS: Domain Name System

People: many identifiers: SSN, name, Passport #

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 ?

Domain Name System: distributed database

implemented in hierarchy of many name servers

application-layer protocol 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”

2

DNS name servers

no server has all name-to-IP address mappings

local name servers: each ISP, company has

local (default) name server host DNS query first goes

to local name server

authoritative name server: for a host: stores that

host’s IP address, name can perform name/address

translation for that host’s name

Why not centralize DNS? single point of failure traffic volume distant centralized

database Maintenance DoS attacks?

doesn’t scale!

3

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

4

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

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

authorititive name serverdns.umass.edu

local name serverdns.eurecom.fr

1

23

4

5

6

5

DNS example

Root name server: may not know

authoratiative name server

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

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

local name serverdns.eurecom.fr

1

23

4 5

6

authoritative name serverdns.cs.umass.edu

intermediate name serverdns.umass.edu

7

8

6

DNS: iterated queries

recursive query: puts burden of

name resolution on contacted name server

heavy load?

iterated query: contacted server

replies with name of server to contact

“I don’t know this name, but ask this server”

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

local name serverdns.eurecom.fr

1

23

4

5 6

authoritative name serverdns.cs.umass.edu

intermediate name serverdns.umass.edu

7

8

iterated query

7

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

8

DNS records

DNS: distributed db storing resource records (RR)

Type=NS name is domain (e.g.

foo.com) value is IP address of

authoritative name server for this domain

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

Type=A name is hostname value is IP address

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

9

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)

10

DNS protocol, messagesDNS 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

11

DNS protocol, messages

Name, type fields for a query

RRs in reponseto query

records forauthoritative servers

additional “helpful”info that may be used

Try nslookup?

12

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

13

Socket programming

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 stream-

oriented

a host-local, application-created/own

ed, OS-controlled interface (a “door”) into which

application process can both send and

receive messages to/from another (remote

or local) application

process

socket

Goal: learn how to build client/server application that communicate using sockets

14

Socket-programming using TCP

Socket: a door between application process and end-end-transport protocol (UCP or TCP)

TCP service: reliable transfer of bytes from one process to another

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperating

system

host orserver

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperatingsystem

host orserver

internet

15

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

TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server

application viewpoint

16

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

inFromUser outToServer

iinFromServer

17

Client/server socket interaction: TCP

wait for incomingconnection requestint cs =accept(s,….)

create socket,port=x, forincoming request:

int s = socket(…); bind(s,…) listen(s,5);

create socket,connect to hostid, port=x

int cli_socket = socket(..);connect(s,…);

closecs

read reply fromcli_socket

closecli_socket

Server (running on hostid) Client

send request usingcli_socketread request from

cs

write reply tocs

TCP connection setup

18

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

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);}

Create client socket,

connect to server

19

Example: C++ server (TCP)//include header files #define PORT 6789int 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);}

20

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 single-Client 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!

21

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

UDP: transmitted data may be received out of order, or lost

application viewpoint

UDP provides unreliable transfer of groups of bytes (“datagrams”)

between client and server

22

Summary

application service requirements: reliability, bandwidth,

delay

client-server paradigm Internet transport

service model connection-oriented,

reliable: TCP unreliable, datagrams:

UDP

Our study of network apps now complete!

specific protocols: http ftp smtp, pop3 dns

socket programming client/server

implementation using tcp, udp sockets

23

Summary

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

Most importantly: learned about protocols

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