PROGRAMMIAMO
Internet - Protocollo DNS
La richiesta di una pagina web

Esaminiamo ora nuovamente un problema che abbiamo già più volte affrontato in passato e cioè quello di descrivere ciò che accade "dietro le quinte" quando un browser richiede una pagina web a un server. Adesso però cercheremo di affrontare la questione dal punto di vista dei protocolli e della suddivisione in livelli.

Iniziamo con un URL digitato sulla barra degli indirizzi di un browser:

Il browser analizza l'URL e la divide in tre parti:

  1. Il protocollo: http (spesso viene sottinteso, cioè non si scrive http://www.majorana.gov.it per intero)
  2. Il nome del server host: www.majorana.gov.it
  3. Il path (percorso) per il file richiesto: i-corsi.html
Richiesta indirizzo a un server DNS: struttura del messaggio di richiesta

Il primo passo è la richiesta di un indirizzo IP al server DNS. Il sistema operativo conosce l'indirizzo di un server DNS poiché questo compare fra i dati di configurazione della scheda di rete. Supponiamo per esempio che tale indirizzo sia 8.8.8.8

Dunque il browser (client) deve inviare una richiesta DNS verso il server DNS di indirizzo 8.8.8.8. Affinché tale richiesta venga correttamente riconosciuta e processata dal server DNS, essa deve essere strutturata secondo le regole del protocollo DNS.

Occorre subito risolvere una possibile confusione terminologica: DNS sta per Domain Name System e questo è il nome utilizzato sia per indicare la rete di server DNS utilizzata per risolvere le URL in indirizzi IP, sia il protocollo utilizzato in tale risoluzione. In questo contesto ci riferiamo ovviamente al protocollo.

Il protocollo DNS opera al livello più alto nello stack di protocolli TCP/IP e cioè al livello di applicazione. Esso regola la comunicazione fra un client DNS (es. il browser) e un server DNS (un altro processo in esecuzione su un host remoto) allo scopo di tradurre un URL in un indirizzo IP.

Fatte queste premesse, vediamo la struttura generale di un messaggio (tecnicamente una PDU) da un client DNS (il browser) a un server DNS:

PDU DNS

La struttura generale è abbastanza tipica: abbiamo un'intestazione (header) con una dimensione fissa (12 byte in questo caso) e quindi una parte di dati (detta data o body) di dimensione variabile. Per essere ancora più specifici, nel nostro caso la richiesta (query) assume la seguente forma nel dettaglio:

Domain Name System (query)
    [Response In: 1852]
    Transaction ID: 0x241a
    Flags: 0x0100 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0

    Queries
        www.majorana.gov.it: type A, class IN
            Name: www.majorana.gov.it
            Type: A (Host address)
            Class: IN (0x0001)

Osserviamo anzitutto che l'header comprende tutta la parte colorata in rosso, mentre la parte in nero è la sezione dati (o body) del messaggio. Il campo Questions dell'header indica che il messaggio contiene una sola domanda e il campo Answer RSS indica che il messaggio non contiene risposte (si tratta infatti di una query, cioè di una interrogazione al server remoto).

Il campo dati (indicato con Queries qui sopra) contiene invece l'URL richiesta più qualche altra informazione aggiuntiva che non andiamo ad approfondire. In realtà le cose sono un po' più complesse di quanto qui esposto, dal momento che il messaggio non è in formato testuale ma binario, ma direi che possiamo tralasciare anche questi dettagli.

La PDU viene passata al livello sottostante (protocollo UDP)

Un altro modo per interpretare i campi header e body è quello data è pensare al primo come l'intestazione scritta su una busta (da spedire) e al secondo come il contenuto della busta stessa:

A questo punto il messaggio precedente viene passato al livello sottostante e in particolare al protocollo UDP (anche se è possibile usare in alternativa il TCP).  Per effettuare la spedizione, lo strato UDP ha bisogno di alcune informazioni aggiuntive e cioè:

L'indicazione della porta è importante in quanto all'indirizzo IP del server (8.8.8.8) potrebbero corrispondere diversi servizi (es. un server DNS, un server HTTP, un server di posta elettronica etc.). In parole più precise, sull'host remoto potrebbero esserci più processi (programmi in esecuzione) in attesa di richieste dalla rete. Il numero di porta serve appunto per distinguere questi servizi l'uno dall'altro. In particolare 53 è un numero di porta standard che indica che si sta inviando il messaggio a un server DNS. Come sappiamo, alcune porte standard (well known port) sono riservate a processi server di rete (es. la porta 80 per il server HTTP, 53 per il server DNS), mentre altri numeri di porta (detti anche dinamici) sono assegnati in maniera automatica ai vari processi. In generale il numero di porta insieme all'indirizzo IP (la coppia dei due viene talvolta detta anche socket) serve per identificare una particolare macchina (l'indirizzo IP) e un particolare processo in esecuzione su di essa (il numero di porta).

In modo corrispondente viene anche assegnata una porta al processo mittente (semplificando un po', nel nostro caso il browser). Si tratta di un numero di porta dinamico (cioè generato automaticamente dal sistema operativo) che è necessario perché il messaggio di risposta venga consegnato correttamente. Infatti ci potrebbero essere più richieste di server DNS attive (es. due browser diversi o anche due schede aperte sullo stesso browser) e senza un numero di identificazione, il sottostante livello UDP non saprebbe a chi consegnare la risposta.

Sempre usando la metafora della lettera da spedire, la busta precedente viene passata a UDP con un piccolo memo (post-it) aggiuntivo, dove vengono scritte le informazioni qui sopra.

Da questo punto in avanti sarà lo strato inferiore che si occuperà dei dettagli della trasmissione e della consegna del messaggio.

Il browser riceve una risposta dal server DNS

Se tutto va bene, trascorso un certo tempo il browser riceverà una risposta dal server DNS. Tale risposta viene recapitata dal livello sottostante (UDP nel nostro caso) e possiamo pensarla come ad un'altra lettera, anche essa composta di un header (intestazione sulla busta) e di una parte di dati (contenuto).

Il livello UDP sarà in grado di recapitare la risposta al processo corretto (per esempio il browser) utilizzando il numero di porta (generato casualmente, 42982 nel nostro esempio) associato a tale processo. Questa risposta potrebbe essere fatta in questo modo:

Domain Name System (response)
    [Request In: 1851]
    [Time: 0.000125000 seconds]
    Transaction ID: 0x241a
    Flags: 0x8180 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0

    Queries
        www.majorana.gov.it: type A, class IN
            Name: www.majorana.gov.it
            Type: A (Host address)
            Class: IN (0x0001)
    Answers
	www.majorana.gov.it: type A, class IN
            Name: www.majorana.gov.it
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 3 minutes, 47 seconds
            Data length: 6
	    Addr 62.149.142.190

Si osservi che l'header è cambiato (ora il campo Flags indica che si tratta di una risposta). Inoltre il campo Answer RRs ora mostra che c'è una risposta che è costituita dal campo Addr. in fondo alla parte dati. Questo è l'indirizzo IP che il server DNS ci restituisce: 62.149.142.190

Osserviamo anche come tutta l'elaborazione svolta dai livelli sottostanti è trasparente (cioè non viene vista): è come se il browser avesse uno scambio di messaggi (secondo le regole del protocollo DNS) direttamente col server remoto. Si tratta, come sappiamo, in realtà di una comunicazione puramente logica (ovvero virtuale), in quanto la comunicazione fisica avviene tra i livelli adiacenti (nel nostro esempio fra il browser e il sottostante livello UDP).

Mr Browser e Mr Server

 

 

precedente - successiva

Sito realizzato in base al template offerto da

http://www.graphixmania.it