DNS: Domain Name System
Identificazione Persone:

Cod.Fiscale , nome,
Passaporto
Internet hosts, routers:


indirizzo IP (32 bit) used for indirizzamento
datagrams (pacchetti)
“nome simbolico”,
cclii.dis.uniroma1.it usato da utenti
Corrispondenza indirizzo
IP e nome
Domain Name System:
 database distribuito
(gerarchic.) implementato su
molti name servers
 protocollo strato application
host, routers, name servers
communicano per risolvere
(resolve) nomi (traduzione
address/name)
 Funzione Internet critica
realizzata come protocollo
application-layer
2: Application Layer
1
DNS name servers
DNS- Perche’ distribuito?
 robusto a guasti
 minor traffico
 mantenimento
local name servers: nessun
server conosce tutte le
corrispondenze nomiindirizzi


ogni ISP, ha local (default)
name server
un host prima effettua una
DNS query first al local
name server
Soprattutto: non si adatta a
authoritative name server:
aggiornamenti (“non
 per un host: memorizza il
scala”)!
suo indirizzo

effettua traduzione per
quell’host
2: Application Layer
2
Root name servers
root name server
 contattato dal local name
server che non puo’
tradurre il nome
 root name server:
 contatta authoritative
name server se non
conosce l’indirizzo
 prende l’indirizzo
 lo comunica al local
name server
 ~ decine di root name
servers (nel mondo)
2
4
5
local name server
dns.uniroma1.it
1
3
authorititive name server
dns.umass.edu
6
richiesta
gaia.cs.umass.edu
uniroma1.it
2: Application Layer
3
Root name servers (cont.)
Root name server:
6
2
 potrebbe non sapere
authoratiative name
server
 puo’ sapere
intermediate name
server: chi sa dov’e’
authoritative name
server
root name server
7
local name server
dns.uniroma1.it
1
8
3
intermediate name server
dns.umass.edu
4
5
authoritative name server
dns.cs.umass.edu
requesting host
uniroma1.it
gaia.cs.umass.edu
2: Application Layer
4
DNS: query iterata
root name server
query ricorsiva:
2
 il name server
3
contattato si fa
carico della richiesta
 heavy load?
query iterata:
 il name server
contattato risponde
“non so la risposta, ma
prova a chiedere a…”
query iterata
4
7
local name server
dns.uniroma1.it
1
8
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
requesting host
surf. uniroma1.it
gaia.cs.umass.edu
2: Application Layer
5
DNS: caching e aggiornamento dati
 quando un name server conosce un qualunque
nome mette in cache la traduzione (entrate
cache hanno un time out)
 meccanismo di aggiornamento in corso di
progetto

RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
2: Application Layer
6
DNS records:Resource Record (RR)
Resource Record (RR) record base dati distribuita
RR formato:
(nome, valore, tipo,ttl)
 Tipo=A
 name e’ hostname
 value e’ indirizzo IP
 Tipo =NS
 nome e’ dominio (e.g.
foo.com)
 valore e’ indirizzo
IP del server
authoritative name
server per il dominio
 Tipo=CNAME
 nome e’ un alias (nome
canonico)
 valore e’ nome
canonico
 Tipo=MX
 valore e’ hostname del
mailserver associato a
 name
2: Application Layer
7
Protocollo DNS: messaggi
Protocollo DNS : query e reply- stesso formato
header messaggio
 identificazione: 16 bit #
per query, reply a query usa
stessa sequenza
 flags:
 query o reply
 ricorsione richiesta
 ricorsione disponibile
 reply e’ “authoritative”
2: Application Layer
8
Protocollo DNS: messaggi
Corpo messaggio
Nome, campi tipo
di una query
RRs di risposta
alla query
records per
authoritative servers
additional “helpful”
info that may be used
2: Application Layer
9
Socket programming
Come realizzare applicazioni client/server che
comunicano usando i sockets
Socket API
 introdotti in BSD4.1 UNIX,
1981
 creati, usati, rilasciati da
applicazioni
 paradigma client/server
 due tipi di trasporto con
socket API:
 datagrammi non affidab.
 flusso affidabile di byte
socket
un’interfaccia host-local,
creata e gestita
dall’applicazione,
controllata dal SO
una “porta” in cui il
processo applicativo puo’
spedire e ricevere
messaggi
a/da un altro processo
applicativo (remoto)
2: Application Layer
10
Programmazione socket con TCP
Socket: un aporta tra processo applicazione e endend-protocollo trasporto (UDP o TCP)
TCP service: trasferimento di byte affidabile da un
processo ad un altro
controllato da
applicazione
controllato da
sistema operativo
processo
processo
socket
TCP con
buffers,
variabili
host o
server
internet
socket
TCP con
buffers,
variabili
controllato da
applicazione
controllato da
sistema operativo
host o
server
2: Application Layer
11
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
2: Application Layer
12
Programmazione socket con TCP
Esempio client-server app:
 cliente legge linea da
standard input (inFromUser
stream), e la manda la server
via socket (outToServer
stream)
 server legge linea dal socket
 server converte la linea in
caratteri maiuscoli e la manda
indietro al client
 client legge e stampa linea
modificata dal socket
(inFromServer stream)
Input stream: sequenza di
bytes nel processo
Output stream: sequenza di
bytes fuori dal processo
client socket
2: Application Layer
13
Interazione Client/server socket
Server (eseguito su
Client
hostid)
crea socket,
porta=x, per
incoming request:
welcomeSocket =
ServerSocket()
realizzazione
aspetta per richiesta
connessione
di connessione
connectionSocket =
welcomeSocket.accept()
leggi richiesta da
connectionSocket
scrivi risposta a
connectionSocket
chiudi
connectionSocket
TCP
crea socket,
connesso a hostid, porta=x
clientSocket =
Socket()
manda richiesta usando
clientSocket
leggi risposta da
clientSocket
chiudi
clientSocket
2: Application Layer
14
Strato Applicativo: conclusioni
 requisiti strato
applicativo:

affidabilita’, banda,
ritardo
 servizio di trasporto
 affidabile e orientato
alla connessione: TCP
 non affidabile
datagrammi: UDP
 protocolli specifici:
 http
 smtp
 dns
 paradigma client-server
 programmazione socket
2: Application Layer
15
Strato Applicativo: conclusioni
protocolli
 scambio di messaggi
tipo richiesta/risposta


cliente fa richiesta
server risponde con
dati, codici stato
 formato messaggi:
 headers: danno info su
dati
 dati: info communicata
 mess. controllo vs.
mess. dati
 stateless vs. stateful
 affidabile vs. non
affidabile
 sicurezza:
autenticazione
2: Application Layer
16