Lo strato applicativo di Internet
Come discusso precedentemente, un aspetto chiave del funzionamento di Internet è la stratificazione degli indirizzi, ed i meccanismi per passare dagli uni agli altri. In questo capitolo, ci occuppiamo di come gli indirizzi di livello applicativo (del tipo www.qualcheserver.it) vengano messi in corrispondenza con gli indirizzi IP. Inoltre, ci occupiamo di alcuni casi applicativi particolari, e che prendono parte a meccanismi più articolati come il Service Discovery, il VoIP, ed il controllo dello Spam.
Abbiamo già osservato come un programma applicativo possa invocare la chiamata di sistema
| struct hostent *gethostbyname(const char *name); |
che, a partire da un nome di dominio, restituisce la struttura dati hostent che contiene, tra le altre cose, il corrispondente indirizzo IP. Questa chiamata fa il paio con l'altra
| struct hostent *gethostbyaddr(const void *addr, int len, int type); |
che permette di popolare la medesima struttura dati, a partire stavolta dall'indirizzo IP a 32 bit x.y.w.z. Nei primi tempi dello sviluppo di Internet, queste funzioni usavano un file presente in ogni computer connesso alla rete, per l'esattezza /etc/hosts, contenente le corrispondenze tra i nomi e gli indirizzi di tutti gli altri, e che doveva essere ri-distribuito a tutti i computer ogni volta che interveniva un cambiamento. Un esempio di /etc/hosts è fornito appresso: notiamo che a fianco di ogni indirizzo, sono presenti due diversi nomi per uno stesso computer, essendo entrambi validi. Inoltre, viene fornita la corrispondenza standard tra 127.0.0.1 e localhost.
| # # Necessario per il "loopback" IPv4. # 127.0.0.1 localhost.localdomain localhost # # Indirizzi IPv4. # 192.168.1.1 dinkel.brot.dg dinkel 192.168.1.2 roggen.brot.dg roggen # 192.168.2.1 weizen.mehl.dg weizen |
Ben presto però, con il successo e l'espansione di Arpanet, nel 1983 viene pubblicata la RFC 882 (successivamente modificata dalle RFC 1034 e 1035), in cui si definisce un meccanismo, chiamato DNS, atto a delocalizzare questa tabella in tutta la rete, e tale da permettere di delegare alle singole organizzazioni la manutenzione e l'aggiornamento della propria parte di spazio di indirizzamento.
L'invocazione delle chiamate a gethostbyname() e gethostbyaddr() su riportate, rappresenta essenzialmente una domanda, od un problema, che deve essere risolto in qualche modo: per questo motivo, il sistema operativo invoca a sua volta i servizi offerti da un componente detto resolver (risolutore), che provvede ad interrogare prima i files locali, poi la propria cache, e quindi il sistema dei DNS esterni:
| Local Host | Foreign | +---------+ user queries +----------+ | +--------+ | |-------------->| | queries | | | | User | gethostby... | |---------|->| Foreign| | Program | | Resolver | | | Name | | |<--------------| |<--------|--| Server | | | user responses| |responses| | | +---------+ +----------+ | +--------+ | A | cache additions | | references | V | | +----------+ | | cache | | +----------+ | |
La figura che segue illustra più in dettaglio la sequenza di attività che intercorrono tra quando un programma applicativo effettua la chiamata alla resolver library, e quando effettivamente riesce ad accedere al computer remoto.
Il comportamento del resolver è definito da un file di configurazione, che tradizionalmente era /etc/host.conf, e che dalla versione 6 di glibc, è invece /etc/nsswitch.conf, in cui tra le altre cose, troviamo la linea
| hosts: files dns mdns4 |
che impone al resolver di provare prima (files)
la risoluzione offerta da /etc/hosts,
quindi (dns) di rivolgersi al
DNS, ed infine (mdns4) a Zeroconf. Il file locale /etc/hosts
può ad esempio servire per indirizzare i computer interni ad una stessa
LAN, ed eventualmente dotati di un IP privato, senza che questi debbano
avere un nome "pubblico", oppure per poterli raggiungere anche nel caso in
cui il DNS esterno non sia raggiungibile: l'unica condizione, in questo
caso, è che i computer conservino sempre il loro stesso indirizzo, cosa
che invece non avviene, nel caso in cui vengano configurati mediante un server DHCP.
Se /etc/hosts non contiene nessuna corrispondenza, allora occorre interrogare un server dei nomi esterno, e quindi occorre conoscerne l'indirizzo IP, che (per fortuna!) è appunto riportato nel file /etc/resolv.conf, e che nel mio caso contiene
| nameserver 193.70.152.15 nameserver 193.70.152.25 |
corrispondenti alle impostazioni relative al provider Libero. Oltre alla direttiva nameserver, possono anche essere presenti (ma non contemporaneamente) le direttive
| domain ing.uniroma1.it search ing.uniroma1.it uniroma1.it it |
che individuano uno o più suffissi da aggiungere al nome di computer, per ri-tentare l'interrogazione al DNS nel caso in cui la prima richiesta abbia determinato un esito negativo.
Il Sistema dei Nomi a Dominio (DNS) è
costituito da tutti i nameserver
che cooperano (come vedremo) al processo di traduzione descritto. D'altra
parte, è invalso l'uso di indicare ogni singolo nameserver
anche con l'appellativo più generale di DNS,
per cui nel seguito useremo i due termini in modo intercambiabile.
Quando una applicazione sul nostro computer deve risolvere un nome a dominio, essa invia un pacchetto UDP verso la porta 53 del computer indicato dal file /etc/resolv.conf come nameserver, codificando all'interno del pacchetto una richiesta dal senso "qual'è l'indirizzo IP del computer pippo.topolinia.com ?". Per tale nameserver, si può verificare una delle tre possibilità:
Nel primo caso, l'autorevolezza è stata conferita al DNS in questione mediante una delega emanata dal nameserver autorevole per il dominio di livello superiore .com, e quest'ultimo a sua volta, è stato delegato da uno dei DNS autorevoli per il root domain. Prima di addentrarci nella spiegazione di come si svolgono i passi 2 e 3, approfondiamo questi concetti.
Un nome a dominio è costituito da una serie di stringhe separate da punti, ad esempio it.wikipedia.org. A differenza degli indirizzi IP, dove la parte più generica del numero è quella che parte da sinistra, in un nome DNS la parte più generica è la prima partendo da destra, detta dominio di primo livello (o TLD, Top Level Domain), come ad esempio .org o .it.
Il numero di elementi, separati da un punto, di cui è composto
un nome a dominio, determina il suo livello.
Ad es. un dominio di secondo livello
consiste di due parti, come wikipedia.org,
e così via. Ogni ulteriore elemento specifica un'ulteriore suddivisione.
Quando un dominio di secondo livello viene registrato
all'assegnatario, quest'ultimo è autorizzato a usare i nomi di dominio
relativi ai successivi livelli come it.wikipedia.org
(dominio di terzo livello) e altri come some.other.stuff.wikipedia.org
(dominio di quinto livello) e così via.
Un nome a dominio completo viene anche indicato come Fully Qualified Domain Name (FQDN), a per ognuno dei punti che si incontrano (partendo da destra) all'interno di un FQDN, si scende di un livello nella gerarchia dei nomi, che in effetti è organizzata ad albero: da ogni livello possono dipartirsi più sotto livelli, fino ad arrivare alle foglie, ed il percorso attraversato costituisce il nome dei computer veri e propri.
Un DNS autorevole per il penultimo livello dell'albero, conosce unicamente i nomi dei computer che definiscono l'ultimo livello, mentre i DNS autorevoli per i livelli superiori, oltre a poter risolvere indirizzi di host con un nome a dominio più corto, delegano l'autorità delle zone associate ai livelli inferiori ad altri DNS. I DNS associati al dominio "." (punto e basta) sono detti root name server, che in effetti tengono assieme internet, sono (originariamente) 13, sono messi a disposizione da diverse organizzazioni sparse per il mondo, in origine principalmente negli USA, e sono coordinati dall'ICANN. Alcuni di essi adottano tecniche anycast per distribuire il carico a livello mondiale.
Il dominio per cui un DNS è autorevole viene denominato zona di autorità (su cui, appunto, esercita il dominio), costituita da tutti i possibili nomi a dominio di livello inferiore a quello associato al nameserver. La composizione di questo insieme è definito da uno o più files, detti files di zona, le cui righe sono denominate Resource Record (Registrazione della Risorsa, o RR), e descrivono varie informazioni relative ai possibili nomi di quel dominio.
Un DNS può quindi delegare l'autorevolezza di una sottto-zona della propria zona di autorità, mediante un meccanismo di delega basato sulla presenza (nei propri file di zona) di un RR di tipo NS (Name Server), che indica appunto il DNS delegato come autorevole per il livello immediatamente inferiore.
Per ogni file di zona, la corrispondenza tra nome ed indirizzo IP è codificata mediante il RR A (address).
Tutti i root name server condividono una medesima tabella di RR, che individua i name server autorevoli per i top level domain (.com, .org, .net, .it, .de, .uk...). Per il County Code dell'Italia ad esempio, la delega spetta ad un istituto del CNR di Pisa, presso il quale ci si rivolge (direttamente o per il tramite di un rivenditore di hosting), per registrare il proprio dominio.
Un server DNS può essere configurato come:
Lo schema sottostante è disegnato dal punto di vista di un DNS configurato come autorevole per la zona che gestisce, ed allo stesso tempo recursivo o forwarder per il resto dei nomi a dominio. Viene quindi mostrato come, in veste di DNS autorevole, il nameserver legga da un insieme di master files, i Resource Records che definiscono la sua zona, in modo da poter rispondere alle richieste che gli pervengono da un resolver esterno. Allo stesso tempo, il nostro DNS inoltra verso un diverso nameserver le queries a cui non sa fornire direttamente risposta.
| Local Host | Foreign | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | A |maintenance | +--------+ | +------------|->| | | queries | | Foreign| | | | Name | +------------------|--| Server | maintenance responses | +--------+ |
Se un DNS non è autorevole per il nome a dominio richiesto, e non trova la risposta nella sua cache, allora deve effettuare una recursione:
Le risposte ricevute da un DNS durante il processo di risoluzione recursiva contengono anche un valore di Time To Live (TTL), che indica la durata di validità delle risposte stesse. Finchè la risposta non è scaduta, se il DNS riceve nuovamente la stessa richiesta, non la inoltra, ma risponde fornendo il valore presente in cache, risparmiando il tempo necessario ad inoltrare la richiesta ed attendere risposta, almeno pari alla somma dei RTT relativi ai DNS coinvolti, anche un nameserver chaching-only, non autorevole su nulla, ha comunque un ruolo molto utile nel velocizzare la navigazione (da cui il vantaggio a configurarne uno a casa propria).
Più tempo il DNS resta in funzione, e più ricca sarà la cache, eliminando via via quasi del tutto, il bisogno di chiedere all'esterno la risoluzione dei suffissi ricorrenti. In tal modo si realizza quindi una forma di bilanciamento del carico, riducendo enormemente il traffico di richieste dirette verso i DNS gerarchicamente superiori.
Può aver senso (ed in effetti lo ha) voler effettuare la risoluzione inversa rispetto a quanto fatto finora, e cioè determinare il fqdn di un host a partire dal suo indirizzo IP. Dato che si tratta sempre degli stessi dati, sembra logico voler affidare questo compito ancora una volta al DNS; quindi, come un particolare DNS è autorevole per i nomi degli host localizzati nell'ambito della zona per la quale il DNS è delegato, così è anche autorevole per quanto riguarda il lotto di indirizzi IP a disposizione del provider che ospita il DNS, mettendoli in corrispondenza con i propri nomi a dominio, mediante il RR di tipo PTR (pointer).
C'è però da notare un particolare: mentre per i nomi a dominio il livello
più elevato è quello scritto più a destra, e
quindi l'albero delle deleghe procede aggiungendo i prefissi di livello
inferiore in testa, per gli indirizzi IP la
parte più generale è quella scritta a sinistra,
e le sottoreti più specifiche si ottengono aggiungendo i byte in
coda. Dato che però il DNS, per come è fatto, aggiunge i
sotto-livelli (più specifici) in testa, allora si è scelto di scrivere gli
indirizzi IP presenti nei RR PTR al
contrario, e di pensarli come sotto-dominio di un TLD radice
fittizio, chiamato in-addr.arpa.
Pertanto, nel chiedere la risoluzione inversa dell'indirizzo IP (ad es.) 151.100.122.144, la query sarà inoltrata per il nome 144.122.100.151.in-addr.arpa. Questo stratagemma permette di distribuire anche l'autorevolezza delle risoluzioni inverse mediante zone organizzate gerarchicamente: il name server autorevole per in-addr.arpa delega l'autorità per il primo byte dell'indirizzo (nell'esempio, 151) ad un DNS gestito dall'organizzazione a cui è assegnato il lotto di indirizzi 151.0.0./8; questo, delega l'autorità a risolvere il secondo byte dell'indirizzo IP, ai DNS a cui questo è intestato (nell'esempio, il lotto 151.100.0.0/16), e così via.
L'assegnazione di blocchi di indirizzi IP agli ISP che ne facciano richiesta viene coordinata da cinque organizzazioni denominate Registri Internet Regionali (RIR), ovvero uno per continente, a cui lo IANA delega il compito di applicare delle politiche locali. Inoltre, i RIR provvedono anche all'assegnazione dei numeri di Sistema Autonomo (AS). Un metodo semplice per scoprire l'intestatario di un lotto di indirizzi si basa sull'uso del comando whois. Esempio: mediante whois scopriamo che in-addr.arpa è registrato a nome dello IANA.
L'implementazione più diffusa di un server DNS è BIND, sviluppato fin dal 1988 presso l'Università di Berkeley, ed ora mantenuto da ISC (che gestisce anche uno dei root ns). Il processo che viene lanciato ha nome named (la d sta per daemon, e ricorre spesso, nel caso di processi che sono eseguiti in background), e determina il tipo di risposte che potrà fornire in base al contenuto del file /etc/bind/named.conf, di cui forniamo un esempio che fornisce una guida passo-passo alla configurazione di BIND:
| named.conf |
|
|
|||||
| file di zona |
|
|
|||||
| risoluzioni inverse |
|
|
La sintassi generale dei files di zona, è illustrata qui di seguito. Per ora osserviamo che in named.conf si dichiara che:
Prima di analizzare cosa viene descritto in questi files, illustriamo la sintassi e la tipologia dei possibili Resource Records (RR) che vi possono comparire.
I file di zona sono essenzialmente costituiti da un elenco di registrazioni di risorse (Resource Records, o RR), che rappresentano tutte le informazioni su cui il DNS è autorevole. Questi RR hanno un formato comune, del tipo
| [nome] [TTL] [classe] tipo dati_della_risorsa |
in cui i termini tra parentesi quadre, se assenti, assumono lo stesso valore presente nel RR precedente. Prendendo come esempio un file di zona di nome brot.dg (a centro tabella), il significato dei campi è il seguente:
| Tipo | Descrizione | Dati |
| SOA | Start Of Authority - è il primo RR che compare nel file di zona, e definisce un insieme di parametri comuni a tutti i RR della stessa zona | in questo caso la sintassi è piuttosto strutturata,
del tipo nameserver email ( numero_seriale refresh retry expire minTTL ) in cui sono indicati, nell'ordine, il CNAME del nameserver primario e autorevole per la zona (ossia l'host presso cui risiedono questi stessi master file), l'email del suo amministratore (ma al posto della @, si usa un punto, per non creare confusione con il meta-simbolo @ illustrato sopra), un numero seriale che si incrementa ad ogni modifica del file, tre valori in secondi (refresh, retry e expire) che determinano la frequenza degli aggiornamenti da parte dei secondari, e (minTTL) il TTL di default per i RR che non lo dichiarano |
| NS | Name Server - indica il DNS autorevole per il nome del RR, e costituisce il meccanismo con cui un dominio di un certo livello delega l'autorevolezza per un sottodominio ad un altro DNS. Per uno stesso sottodominio possono essere presenti più record NS, ad indicare che il carico deve essere ripartito su più macchine | il FQDN dell'host reso autorevole per il dominio delegato. Generalmente nello stesso file di zona, è presente anche un RR di tipo A, che ne risolve il nome nel suo indirizzo IP (vedi anche la definizione di glue records) |
| A | Address - effettua la traduzione vera e propria tra un nome a dominio, ed il suo indirizzo IP. | l'indirizzo IP nella sua forma dotted decimal x.y.w.z. Ci possono essere più RR di tipo A, relativi a nomi diversi, e che vengono risolti con un medesimo indirizzo IP. |
| CNAME | Canonical Name - qualora ad uno stesso indirizzo IP siano associati più nomi, il RR CNAME specifica quale di questi è canonico, e restituito dal processo di risoluzione inversa, mentre gli altri sono detti alias. Se invece il nome-chiave non possiede un RR di tipo A, allora CNAME lo rende direttamente alias del nome_dato | il FQDN del nome canonico associato al nome relativo a
questo RR. Es: weizen.brot.dg. A 192.168.0.1 dinkel.brot.dg. A 192.168.0.1 weizen.brot.dg. CNAME dinkel.brot.dg pippo.brot.dg CNAME dinkel.brot.dg in questo caso, il Cname di weizen è dinkel, mentre pippo ne è un alias |
| PTR | Pointer - è presente nelle zone con suffisso in-addr.arpa, e permette la risoluzione inversa da indirizzo IP, a FQDN. Nel campo nome a dominio di questo RR è presente la parte di indirizzo IP sottostante al nome della zona .in-addr.arpa, scritta da destra a sinistra. | il FQDN del nome canonico dell'host a cui è stato assegnato questo indirizzo. E' infatti possibile inserire un unico RR di tipo PTR, per uno stesso indirizzo IP. |
| MX | Mail Exchanger - indica un host incaricato di ricevere la posta elettronica (via SMTP) indirizzata verso gli utenti del dominio espresso dalla parte nome del RR. Possono essere presenti più RR MX per lo stesso dominio, ognuno con una associata priorità, per garantire il servizio anche quando un host è in manutenzione | compaiono due campi, con il formato priorità FDQN in cui priorità è un numero, e se ci sono più RR MX, viene provato per primo l'MX con priorità numericamente inferiore. FQDN identifica quindi il server SMTP da utilizzare per l'email destinata al nome a dominio del RR.. |
Per un elenco più completo dei tipi, si consulti il sito di ISC. Alcuni altri tipi usati sono:
| HINFO | descrive la CPU ed il SO usato da un host |
| AAAA | descrive un indirizzo IPv6 |
| LOC | memorizza i dati geografici GPS del DNS (RFC 1876) |
| NAPTR | name authority pointer (RFC 2915) |
| SRV | permette di scoprire chi eroga i servizi di rete (RFC 2782) |
Un programma in linguaggio c che voglia interrogare il DNS per conoscere un RR particolare, anziché invocare gethostbyname(), dovrà usare la chiamata a res_query().
Siamo finalmente in grado di commentare i files di zona forniti nell'esempio:
Notiamo che i files di zona /etc/bind/dg
e /etc/bind/brot.dg
contengono sia nomi assoluti nella forma di FQDN, sia relativi
composti senza punti intermedi: in questo secondo caso, vengono
automaticamente estesi con il valore di @.
In particolare, questo processo di estensione può avvenire anche nel campo
dati del RR. L'uso di nomi non FQDN
facilita il riuso dei files di zona, qualora lo stesso blocco di indirizzi
venga ri-assegnato ad un diverso nome di dominio. Viceversa, nel file di
risoluzione inversa (/etc/bind/192.168)
non è possibile usare i nomi corti per il campo dati,
perché in tal caso il valore di @ non è più pari al suffisso di dominio,
ma è invece pari a 168.192.in-addr.arpa.
Notiamo infine che, dato che i file di zona indicano in dinkel il DNS autorevole per le zone dg e brot.dg, e che questi files dunque, devono risiedere fisicamente proprio su dinkel, allora... il computer che ospita il DNS, non può che essere dinkel!
L'esempio fornito, vede lo stesso DNS autorevole sia per dg, che per brot.dg. Ma cosa sarebbe successo, se le due zone fossero state ospitate su server diversi? Immaginiamo questo scenario:
Per ovviare a questa situazione di stallo, è previsto che nel punto di delega sia aggiunto un RR non autorevole di tipo A (nel nostro caso, si avrebbe ad es. dinkel.brot.dg IN A 192.168.1.3), in modo da permettere al DNS di livello superiore, di fornire la risoluzione dell'indirizzo IP del DNS autorevole per la zona di livello inferiore. Questo caso particolare di risoluzione di un IP per un computer esterno alla propria zona (ma interno ad un sottodominio delegato) prende il nome di Glue Record (o collante) in quanto permette, appunto, di tenere assieme due zone. Tornando all'esempio, si avrebbe:
| presso il DNS autorevole per .dg: 192.168.1.1 = dg |
presso il DNS autorevole per brot.dg: 192.168.1.3 = dinkel.brot.dg |
||
|
|
Nella sezione apposita delle esercitazioni, illustriamo il funzionamento di alcuni strumenti di indagine relativi alla configurazione dei DNS, come whois, host, dig, nslookup.
Catturando con Wireshark il
traffico diretto verso la porta 53, possiamo osservare il formato dei
pacchetti diretti verso il DNS, e le risposte associate. Il formato di
domande e risposte è simile, ed è definito alla sezione 4 della RFC
1035: entrambe contengono il medesimo identificatore;
inoltre nelle risposte sono riportate anche le domande a cui rispondono, citate nello spazio delle questions.
Il campo authority riporta gli estremi della
fonte autorevole da cui la risposta ha origine, mentre le informazioni
addizionali riferiscono, ad esempio, il RR di tipo A di un MX il cui nome
canonico è presente nel campo di risposta. Infine, il campo flags
è composto dai 16 bit
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
in cui
L'associazione diretta ed inversa tra nome di computer e suo indirizzo IP, è a rigor di logica possibile solo nel caso in cui questa non si modifichi nel tempo, ovvero l'host disponga di un cosiddetto indirizzo IP statico. Al contrario, molto spesso l'indirizzo IP viene assegnato dinamicamente poco dopo l'accensione del computer (ad es. via DHCP o PPP), ed in quel caso, esistono dei meccanismi (il DDNS) per riconfigurare opportunamente il DNS. Allo stesso tempo, i computer di una stessa rete locale, dovrebbero poter comunicare anche in assenza di un DNS centralizzato ed amministrato da qualcuno: a tale scopo, è nata l'iniziativa di Zeroconf.
Il DHCP, definito nella RFC 2131 come evoluzione di BOOTP, è un protocollo usato nell'ambito di una LAN per assegnare indirizzi dinamici ai computer che vi accedono in modo temporaneo: affidare la configurazione di una rete ad un meccanismo dinamico ed automatico è una grande comodità, alla luce della frequenza con cui i computer della rete entrano/escono e sono sostituiti.
Il protocollo opera sulla porta 67 e 68 (dal lato server e
client rispettivamente) di UDP, e mediante i passaggi illustrati in
figura, affitta (lease)
gli indirizzi di cui dispone, ai client che ne fanno richiesta.
Il processo continua con il client che periodicamente, prima che termini il periodo di affitto, ne effettua una rinnovo mediante un messaggio di REQUEST, finché il suo funzionamento termina, ed allora emette un messaggio di RELEASE. Il comportamento del client può essere rappresentato da un diagramma di transizione, che evidenza i passaggi di stato che avvengono:
Tenendo aperto il capture di Wireshark, e contemporaneamente
disabilitando/riabilitando l'interfaccia di rete, si possono osservare i
passaggi discussi. Nel caso preso
in esame però, manca la fase di DISCOVERY,
dato che il computer in questione tenta di riusare l'IP che gli era stato
assegnato precedentemente (192.168.0.215),
ed il messaggio di REQUEST
viene visualizzato come "SSL".
La RFC 2132 elenca tutta una serie di ulteriori parametri che anche possono essere specificati tramite i messaggi DHCP, come ad esempio (nelle richieste DHCP) il nome dell'host, e (nelle risposte) il dominio che quest'ultimo deve aggiungere nelle sue richieste al DNS, qualora queste non si riferiscano ad un fqdn.
Lo standard RFC 2136
definisce un nuovo tipo di messaggio per le richieste al DNS, mediante un
Opcode di tipo UPDATE,
ed in cui i restanti campi, anziché contenere una richiesta, contengono
gli estremi di un RR da aggiungere o modificare. In questo modo, un server
DHCP può comunicare al DNS l'indirizzo associato ai lease
assegnati, ed associarlo al nome che l'host gli ha comunicato. Inoltre, la
RFC 2845 definisce un
metodo di autenticazione di
questi messaggi, basato su di un segreto
condiviso. A conclusione dell'A.A 2006-2007, si è svolta una
tesina che ha affrontato l'argomento.
Queste tecniche prendono il nome di DDNS (Dynamic DNS appunto), e lo stesso acronimo viene utilizzato anche da parte di fornitori di servizio DDNS, ossia soggetti noti come DDNS provider, che permettono anche agli utenti dial-up a cui viene assegnato un IP dinamico, di poter essere raggiunti dal resto di Internet mediante un FQDN. In generale, il TTL dei RR risolti da un provider DDNS è piuttosto ridotto, dell'ordine della decina di minuti, per permettere alla gerarchia dei DNS di aggiornare frequentemente le proprie cache, e propagare in fretta i RR modificati più di recente.
E' l'acronimo di Point to Point Protocol e si è sviluppato nell'ambito della connessione dial-up verso un ISP, con il compito di svolgere in pratica le stesse funzioni del DHCP (assegnazione di indirizzo IP, netmask, DG e DNS) ma al di fuori della LAN di appartenenza. Si è poi esteso all'uso su linee ADSL come PPPoE e PPPoATM, ove assolve anche a compiti di fatturazione e configurazione di ulteriori parametri.
La figura (tratta da un whitepaper) mostra le diverse fasi attraversate dal protocollo, che inizialmente dialoga con il Broadband Remote Access Server (BRAS) individuato mediante la Active Discovery operata con uno scambio simile a quello con il DHCP. Quindi è svolta la fase di autenticazione con l'ausilio di un servizio di Authentication, Authorization and Accounting (AAA), che provvede anche ad assegnare l'indirizzo IP ed altri parametri. L'associazione viene mantenuta e monitorata per mezzo di appositi messaggi di controllo, con i quali gestire anche la terminazione della comunicazione. Una buona descrizione dell'architettura nel suo insieme può essere trovata presso [Kitz].
Si tratta di un metodo di configurazione dinamica delle risorse di una rete locale, basato sul protocollo IP, e che non dipende da altri elementi architetturali, nè da pianificazioni ed accordi con altre parti. In altre parole, un computer in area locale deve semplicemente essere in grado di interoperare con altri computer li presenti, senza dipendere da nulla di esterno, un pò come per la corrente elettrica: nessuna lampadina va configurata prima di accenderla! E' un pò ciò che avveniva con la rete Appletalk e che avviene con la rete Windows, con la differenza che usando direttamente IP, uno sviluppatore può sfruttare lo stack TCP/IP anche per le applicazioni di rete che si svolgono tutte in area locale, e che è disponibile nativamente nelle diverse architetture di calcolo. Zeroconf è stato principalmente sviluppato da un impiegato di APPLE, come evoluzione di AppleTalk (video). Per raggiungere gli obiettivi illustrati, occorre che
Sebbene non ancora completamente definito dagli standard, zeroconf viene già utilizzato per accedere, ad esempio, alle stampanti di rete. Illustriamo ora meglio, i tre aspetti sopra evidenziati:
I dispositivi che aderiscono a Zeroconf, tentano di auto-assegnarsi un indirizzo link-local di tipo 169.254.*.*, che la RFC 3927 stabilisce possano essere usati nell'ambito di una LAN, e ri-usati su qualunque altra LAN, in quanto non devono essere instradati dai router, e neanche accettati dai dispositivi NAT. La definizione delle modalità con cui avviene questa auto-assegnazione è il frutto del lavoro di un WG IETF, ora chiuso. Il risultato, è che ogni host tenta di attribuirsi (e difendere) l'uso (per se) di uno di questi indirizzi. Se però un server DHCP effettivamente risponde, ed assegna all'host un indirizzo instradabile, viene usato quest'ultimo.
L'idea è di far uso di un DNS che risponda a richieste pubbliche, ossia multicast (detto mDNS). Ogni computer che intenda offrire servizi accessibili mediante indirizzi link-local, ospita un suo mDNS che risponde, presso la porta UDP 5353, alle richieste indirizzate verso l'indirizzo multicast 224.0.0.251 (questo indirizzo, non viene inoltrato dai router). Inoltre, è stato proposto l'uso di uno speciale top level domain, di nome .local, in modo che le richieste di nomi del tipo computer.local vengano dirette, anziché verso il DNS configurato di default, verso l'indirizzo multicast dove ascolta l'mDNS. Una applicazione client che richieda la risoluzione del nome sally.local quindi, riceverà la risposta direttamente dall'mDNS in esecuzione presso la macchina sally.
Al fine di evitare collisioni di nomi, non appena mDNS si attiva, prova a
verificare se non ci sia già qualcun altro che rivendica le stesse
risorse.
Mentre per mDNS esistono già diverse realizzazioni funzionanti, il WG DNSEXT di IETF ha standardizzato una soluzione diversa allo stesso problema, nota come Link-local Multicast Name Resolution (o LLMNR) (RFC 4795), nata in casa Microsoft, e che sebbene funzioni in modo del tutto simile a mDNS, permette di usare anche nomi di tld esistenti, con un possibile effetto di disorientamento.
Con questo termine si intende una funzione basilare necessaria per accedere ad una qualunque risorsa o servizio disponibile in rete. E' chiaro che noi umani possiamo venire a conoscenza di un particolare indirizzo perché qualcuno ce ne parla, oppure perché questo viene pubblicizzato su giornali, TV, siti web, ed email. Al contrario, un computer in rete utilizza un protocollo di comunicazione, particolarmente progettato per individuare i servizi offerti, descriverne le caratteristiche (o attributi), ed illustrarne le modalità di fruizione, fornendone l'indirizzo (URL). Illustriamo ora tre diverse alternative: SLP, DNS-SD, e SSDP.
Un caso piuttosto classico è quello delle stampanti, che possono comparire "magicamente", quando desideriamo stampare qualcosa. Il WG SVRLOC di IETF ha elaborato a tale proposito la RFC 2608 che definisce il Service Location Protocol (SLP), che si basa sulla definizione di tre entità, un client, un server ed un director, sebbene quest'ultimo sia presente solo su reti di grosse dimensioni. Anche se lo standard è definito in modo generico, e non orientato unicamente alle stampanti, è abbastanza comune che queste ultime implementino l'entità SLP server. In linea generale, quando un SPL client ha bisogno di un servizio, invia in multicast una richiesta SLP relativa a quel tipo di servizio, e tutti i server che lo offrono, rispondono.
Il DNS Service Discovery (DNS-SD) permette la scoperta dei servizi basandosi sull'uso dei RR SRV del DNS, e per questo funziona particolarmente bene in congiunzione con il mDNS, anche se non ne dipende, nel senso che può essere usato anche con un DNS normale. La sua definizione è frutto dello stesso autore della definizione degli indirizzi Link-Local e del mDNS, e quindi si integra perfettamente con la suite definita da Zeroconf, per la quale sono disponibili varie implementazioni, come ad esempio Bonjour e Avahi (video). Nella sezione degli esercizi, sono svolti alcuni esperimenti con Avahi.
SSDP è un protocollo UPnP, usato da Windows XP ma considerato più complesso di DNS-SD, ed il cui processo di standardizzazione si è arrestato nel 2000.
Sviluppatosi a partire dal 2004, DLNA opera con il supporto di numerose aziende di dispositivi per realizzare l'interoperabilità casalinga tra dispositivi multimediali di tipo sia player che server, ed a sua volta sfrutta lo UPnP per la scoperta ed il controllo dei dispositivi. Prende inoltre in considerazione i formati ed il trasporto per i contenuti da riprodurre, nonché la loro gestione, compresa quella dei diritti digitali (vedi descrizione).
Con Voice over IP (VoIP) si intende la possibiità di effettuare conversazioni audio mediante Internet, e l'approfondimento di queste tecniche è oggetto di una sezione del corso specifica. Sebbene la maggior parte degli utenti di Internet identifichi il VoIP con Skype, esso si basa su protocolli proprietari e non pubblici; invece, esiste una valida alternativa, il Session Initiation Protocol (SIP), che è definito da IEFT mediante documenti pubblici. SIP individua gli utenti per mezzo di URI dal formato simile a quello delle email, ossia
| sip:alef@ing.uniroma1.it |
e, quando un computer connesso ad Internet genera una chiamata SIP diretta a questa destinazione, si tenta di individuare il server SIP incaricato di localizzare l'utente alef presso il dominio ing.uniroma1.it, mediante l'interrogazione del DNS a riguardo dei RR di tipo NAPTR e SRV, come dettagliato nella RFC 3263. Se invece di un utente connesso ad Internet, la chiamata deve partire da, o raggiungere, un normale utente telefonico connesso alla rete telefonica PSTN, allora sorge il problema di dover trattare anche semplici numeri, cosidetti E.164. La traduzione da numero E.164 ad indirizzo SIP, avviene ancora una volta per mezzo del DNS, facendo uso dei RR NAPTR, in accordo alle raccomandazioni ENUM. Ma andiamo con ordine.
Il Resource Record di tipo SRV (SeRVice) è definito nella RFC 2782, e viene effettivamente usato da applicazioni come il VoIP (protocollo SIP) e la messaggistica (protocollo XMPP, RFC 3920). Esso realizza una funzione di Service Location basata sul DNS, e permette di scoprire quali computer offrano, presso un certo dominio, un determinato servizio applicativo, usando il trasporto specificato. Il risultato di questa query indicherà
Queste caratteristiche ne rendono l'utilizzo simile a quello del RR MX (che permette di scoprire, ad esempio, che il server email di alice.it è smtp.aliceposta.it (provare host -t MX alice.it)); in più, il RR SRV permette anche di svincolarsi dalla necessità di usare le porte ben note, potendo infatti offrire il servizio su di una porta qualsiasi, che viene scoperta dal client solo al momento del suo utilizzo effettivo. Il formato dei RR di tipo SRV è
| _sip._tcp.example.com. 86400 IN SRV 0 5 5060
sipserver.example.com. --+- --+- ----+------ --+-- + -+- | | | ---------+------------ | | | | | | | | | | serv proto domain TTL class TYP pri wei port target |
i cui campi sono descritti al seguente modo:
Poniamo che il DNS autorevole per il dominio example.com,
ospiti il RR dell'esempio: un resolver che esegua una query chiedendo il
RR di tipo SRV associato a _sip._tcp.example.com,
vuol conoscere quale sia, e su che porta TCP risponda, il SIP Server del
dominio example.com. In
analogia con il caso dei RR MX, la query può restituire più RR di tipo
SRV, con diversi target, contraddistinti da
diverse priorità e pesi, in modo da poter distribuire
il carico su più target, ed offrire ridondanza.
Nel caso in cui i RR SRV siano erogati da un mDNS, questi possono essere generati dagli stessi applicativi in esecuzione sull'host su cui gira il mDNS, facendo venir meno l'esigenza di immetterli manualmente, in accordo al principio di Zeroconf.
L'acronimo NAPTR sta per Naming Authority Pointer, come definito nella RFC 2915 e successive, ed ha lo scopo di incorporare nel DNS un insieme di regole tali da permettere alle informazioni di delega, di essere ulteriormente ri-delegate. In altri termini, viene resa possibile la risoluzione di un nome a dominio, in un nuovo nome a dominio, in una URI, o (nello specifico) in un indirizzo VoIP. Un RR di tipo NAPTR aderisce ad una sintassi dalla forma
| Domain TTL Class Type Order Preference Flags Service Regexp Replacement |
ed il significato di alcuni dei suoi campi può apparire notevolmente involuto, a causa della estrema genericità che si è voluta dare a questo tipo di RR. In tutti i modi
Nel caso di una applicazione VoIP, i RR di tipo NAPTR intervengono in almeno tre circostanze:
La RFC 3263 specifica che, prima di chiamare una URI SIP, si dovrebbe intraprendere un processo di risoluzione in due passi, che prevede
Ad esempio, volendo chiamare sip:user@example.com, il primo passo potrebbe restituire
| ; order pref flags service regexp
replacement example.com IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. example.com IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com. example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. |
indicando che il dominio example.com supporta SIP sia su UDP che su TCP, e SIP su TLS. Nei tre casi, la parte RS del campo service assume il significato di Domain to UDP e Domain to TCP. Come indicato dal flag pari ad s, il risultato delle query è individuato dal campo replacement, e deve essere seguito da una richiesta dei RR di tipo SRV. Nel caso in cui il chiamante (ad es.) non supporti SIPS, tenterà di determinare il computer e la porta da chiamare effettivamente per il trasporto TCP e UDP, mediante una successiva interrogazione dei RR di tipo SRV associati ai dominii ricevuti come replacement:
| ;
Priority Weight Port Target _sip._tcp.example.com IN SRV 0 1 5060 server1.example.com. _sip._udp.example.com IN SRV 0 2 5060 server2.example.com. |
a cui farà poi seguito una normale
interrogazione al DNS, per conoscere i RR di tipo A, ed individuare
finalmente l'IP da contattare.
Notiamo che nelle due risoluzioni su riportate, i domini di partenza e di
arrivo non devono necessariamente coincidere, offrendo una opportunità di
URI portability, potendo infatti accasare
una URI SIP in cui compare un certo dominio, presso i server di un altro
provider VoIP.
Infine, nel caso in cui il primo passo fallisca (come conseguenza del
fatto che non esistono RR NAPTR per il dominio indicato), si può procedere
direttamente al secondo, costruendo le query con il prefisso dei trasporti
desiderati. Nel caso in cui fallisca il secondo, si assumerà di chiamare
direttamente l'host associato al nome di dominio della URI, ed usare il
trasporto UDP sulla porta ben nota 5060.
Come anticipato, quando la destinazione da chiamare non è data nella forma di una URI sip, ma di un normale numero di telefono E.164, allora vengono applicate le regole di riscrittura del numero indicate come ENUM, ed il DNS viene utilizzato prima di tutto per tentare di convertire il numero E.164 in una URI SIP. In questo caso, i RR rilevanti avranno sempre il Flag pari ad U, ed il campo Replacement sarà assente (ma sostituito da un punto). Pertanto, poniamo che la query dei RR NAPTR che ENUM associa al numero E.164 (es. +12025332600) da chiamare, sia soddisfatta da un file di zona contenente
| $ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!" . |
in cui il dominio espresso nella $ORIGIN è il risultato delle regole di riscrittura definite da ENUM, per il numero E.164 +12025332600. Le regexp che troviamo sono cosiddette greedy, e sono composte da due campi, delimimitati dai tre punti esclamativi. La prima parte ^.*$ significa (letteralmente) qualsiasi cosa, e quindi la chiave-dominio espressa dalla $ORIGIN, corrisponde. Pertanto, quando il client che ha chiesto la risoluzione riceve questa risposta, applica la sostituzione indicata dal secondo campo della Regexp, che nei due casi di Servizio E2U+sip e E2U+mailto, corrisponde rispettivamente a sip:user@example.com e mailto:info@example.com. In altre parole, la query con chiave E.164 ha fornito come risoluzione a priorità migliore una URI SIP, e se questa chiamata VoIP dovesse fallire, viene proposta come seconda risoluzione, l'invio di una email. Nella figura che segue, un esempio di utilizzo delle alternative di reperibilità.
L'applicazione di questa metodologia prevede che il legittimo
intestatario di un numero telefonico richieda al provider VoIP che
gestisce il DNS delegato a risolvere il proprio numero in formato ENUM,
l'inserimento nel DNS di tanti RR di tipo NAPTR, quanti sono i diversi
recapiti che vuole associare a questo numero. In tal modo, anzichè dover
comunicare ai suoi conoscenti tutti i diversi indirizzi a cui può essere
raggiunto, può comunicare loro un unico numero.
In effetti, dopo una risoluzione ENUM, possono ancora essere necessarie le due risoluzioni previste al punto precedente, più ovviamente, l'individuazione dell'indirizzo IP associato al dominio finale.
L'acronimo ENUM
sta per Electronic Number Mapping System, è
descritto dalla RFC 6116,
è implementato in accordo alle linee guida indicate nella RFC
3824, e definisce il metodo per utilizzare il DNS per la risoluzione
dei numeri E.164 in URI. Si basa sulla trasformazione dei numeri
telefonici in Domini Internet, attuata
ri-scrivendo il numero da destra a sinistra, con la cifra più
significativa a destra, intercalando le cifre con dei punti, ed
aggiungendo (a destra) il suffisso e164.arpa.
Ad esempio, al numero telefonico E.164 +39.081.7507.1
è associato il nome a dominio: 1.7.0.5.7.1.8.0.9.3.e164.arpa.
In questo modo, si definisce un meccanismo di delega dei sotto-domini,
coerente con la struttura gerarchica della numerazione telefonica, in modo
del tutto simile a quanto avviene per la risoluzione inversa degli
indirizzi IP.
Dato che sembrano esserci ostacoli sia di natura burocratica che politica alla delega delle numerazioni nazionali sotto il suffisso e164.arpa, sono state proposte diverse radici alternative (ossia, suffissi) per la risoluzione ENUM, come l'iniziativa europea nrenum.net, servita per il prefisso +39 dell'Italia dal GARR, e e164.org, che permette gratuitamente ai singoli individui possessori di un qualunque numero telefonico, di associarvi un indirizzo VoIP. Dato che, noto un numero E.164, non è più ben chiaro sotto che radice debba essere indirizzata l'interrogazione al DNS, i proxy SIP possono interrogare in sequenza più alberi ENUM.
L'Internet Engineering Task Force sviluppa e promuove gli standard di Internet, in collaborazione con W3C e ISO/IEC, ed è costituita da volontari, senza necessità di appartenenza formale. E' organizzata in un gran numero di Gruppi di Lavoro (WG), il cui funzionamento è definito dalla RFC 2418, ognuno relativo ad un argomento specifico, e commissionati a portare a termine un lavoro, e quindi ad essere chiusi. Ogni gruppo è diretto da uno o più chairman, e gli obiettivi sono definiti da un charter. Più gruppi sono riuniti all'interno di una stessa area sulla base degli argomenti, ed ogni area supervisionata da un direttore d'area, che nomina i chair dei WG. I direttori d'area assieme al chair dello IETF, compongono l'Internet Engineering Steering Group (IESG), responsabile dell'attività complessiva dello IETF. Ancora, IETF è formalmente una attività svolta sotto l'ombrello della Internet Society (ISOC), mentre è supervisionata dall'Internet Architecture Board (IAB).
I gruppi di lavoro si riuniscono fisicamente tre volte l'anno, e negli intervalli, svolgono il lavoro discutendo per via posta elettronica, costituendo così un luminoso esempio di comunicazione telematica. Le decisioni vengo prese senza bisogno di votazioni, ma in base al principio del consenso approssimato. Le mailing list sono ad accesso pubblico, e chiunque vi può intervenire.
Quando la discussione raggiunge un livello di maturità sufficiente,
oppure per chiarire meglio un punto di vista od un approccio, vengono
prodotti dei documenti detti draft,
che sono lasciati in visione sui server pubblici per un periodo massimo di
sei mesi, dopodiché se non è stata prodotta una nuova versione del draft,
contenente gli emendamenti risultanti dalla discussione intercorsa nel
frattempo, vengono ritirati.
Quando il Draft raggiunge uno stato stabile, sempreché abbia ricevuto il consenso, questo evolve allo stadio di Request for Comments (RFC), ma anche in questo caso, ci sono da fare alcuni distinguo, e precisamente:
Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade
dietro le quinte di Internet, completo di cattura del traffico.
Scopri
come effettuare il download,
ricevere gli aggiornamenti,
e contribuire!
