DNS, DHCP e HTTP: come funzionano i protocolli del livello applicazione

Se sei in quinta in un istituto tecnico a indirizzo informatico, o alle scienze applicate, Sistemi e reti (o Informatica) sta lavorando su ISO/OSI, TCP/IP e protocolli. Il livello applicativo, cioè DNS, DHCP, HTTP e posta, si spiega di solito tra ottobre e novembre; l’interrogazione o la verifica scritta arriva fra dicembre e gennaio, cioè fra sei e dieci settimane da oggi. Conviene portarsi avanti di un passo rispetto al professore: questi tre protocolli sono quelli che tornano di continuo, nelle domande teoriche e poi nel progetto di rete della maturità.

Il modello a livelli lo trovi in ISO/OSI e TCP/IP: i livelli spiegati, il subnetting in Indirizzi IP e subnetting. Qui faccio l’altra metà: cosa dicono davvero i protocolli quando apri un sito, nell’ordine in cui lo dicono.

Cosa succede quando digiti un URL

Accendi un PC e digiti https://www.esempio.it/. In ordine:

1. DHCP: il PC non ha ancora un indirizzo IP, quindi ne chiede uno (con maschera, gateway e server DNS).
2. ARP: per mandare un pacchetto fuori dalla sottorete serve il MAC del gateway. È livello 2, non IP; ne parlo in Ethernet, switch e indirizzi MAC.
3. DNS: il PC traduce www.esempio.it in un indirizzo IP.
4. TCP: handshake a tre vie con quell’indirizzo, sulla porta 443 (80 per HTTP in chiaro).
5. HTTPS: negoziazione TLS, poi richiesta HTTP e risposta.

Il motivo dell’ordine è logico: senza IP non parli con nessuno, senza nome risolto non sai a chi, senza connessione TCP non puoi mandare HTTP.

DNS: dal nome all’indirizzo

Le persone ricordano i nomi, le reti usano gli indirizzi. Il DNS (Domain Name System) è un database distribuito che li collega, con struttura gerarchica ad albero:

• radice (il punto finale: www.esempio.it.);
• TLD (top level domain), come .it o .com;
• dominio, come esempio.it, gestito da un server autorevole che conosce i suoi record.

Il PC chiede a un risolutore (resolver), quello del provider o della scuola, indicato dal DHCP. Il resolver, se non ha la risposta, interroga la radice, che lo manda al server del .it, che lo manda al server autorevole di esempio.it, che risponde. Poi ricorda la risposta.

I record principali:

Nel record MX il numero più basso vince: 10 viene provato prima di 20.

Ogni risposta ha un TTL (time to live), in secondi, che dice per quanto può restare nella cache. Con TTL 300 il resolver riusa la risposta per cinque minuti senza chiedere di nuovo. Un TTL basso permette di cambiare indirizzo rapidamente; uno alto riduce il traffico. Le richieste DNS viaggiano di norma su UDP porta 53: sono domande brevi, e se la risposta non arriva si ripete. Passa a TCP 53 quando la risposta è troppo grande o per i trasferimenti di zona.

Da terminale (su Linux, vedi i comandi base) lo vedi con dig www.esempio.it o nslookup www.esempio.it.

DHCP: l’indirizzo senza configurarlo a mano

Il DHCP (Dynamic Host Configuration Protocol) assegna automaticamente la configurazione di rete. Fornisce: indirizzo IP, maschera, gateway, server DNS e la durata del lease, cioè del “prestito” dell’indirizzo. Usa UDP: porta 67 per il server, 68 per il client.

Lo scambio si ricorda con DORA:

1. Discover: il client, con IP 0.0.0.0, manda un broadcast: “c’è un server DHCP?”.
2. Offer: il server propone un indirizzo libero e i parametri.
3. Request: il client accetta l’offerta (ancora in broadcast, così anche gli altri server DHCP sanno che non è stata scelta la loro).
4. Acknowledge: il server conferma; il client può usare l’indirizzo fino alla scadenza del lease. A metà lease di solito chiede di rinnovarlo.

Perché UDP e broadcast? Il client non ha ancora un IP, quindi non può aprire una connessione TCP e non conosce l’indirizzo del server. Un broadcast non attraversa un router: se il server DHCP sta in un’altra rete (VLAN comprese) serve un relay, per esempio ip helper-address sui router Cisco.

Un caso tipico di verifica, che collega DHCP e subnetting: rete 192.168.1.0/24, gateway 192.168.1.1, server fissi da .2 a .49, pool DHCP da 192.168.1.50 a 192.168.1.200. Quanti dispositivi riescono a ottenere un indirizzo? $200-50+1=151$, uno in più della differenza perché gli estremi sono inclusi. Se ne arrivano 152, il 152° non riceve nulla.

HTTP e HTTPS: richiesta, risposta, codici

HTTP è il protocollo del web: il client manda una richiesta, il server una risposta. Funziona su TCP, di default sulla porta 80; non ha memoria delle richieste precedenti (è stateless, per questo esistono i cookie).

La richiesta ha: riga iniziale (metodo, risorsa, versione), header, riga vuota e un eventuale corpo. I due metodi da sapere:

• GET: chiede una risorsa; eventuali parametri stanno nell’URL.
• POST: invia dati al server, per esempio un form di login; i dati stanno nel corpo, non nell’URL.

Header che ricorrono: Host (il sito richiesto: su un solo IP possono vivere molti siti, ed è obbligatorio in HTTP/1.1), User-Agent, Accept, Content-Type, Content-Length, Location (nei reindirizzamenti), Cache-Control.

La risposta inizia con un codice di stato; la prima cifra dice la famiglia:

Le famiglie: 2xx successo, 3xx reindirizzamento, 4xx errore del client, 5xx errore del server. Un 404 vuol dire che il server è stato raggiunto e risponde; un 500 che il guasto è dal lato server.

HTTPS è HTTP dentro un canale TLS, sulla porta 443. TLS fa tre cose: cifra i dati, verifica con un certificato che il server è chi dice di essere, garantisce che i dati non siano modificati. La richiesta non cambia: cambia che nessuno in mezzo può leggerla. La negoziazione TLS viene dopo l’handshake TCP e prima della richiesta HTTP. (Le versioni recenti, HTTP/3, usano UDP con QUIC sulla porta 443; a scuola si studia HTTP su TCP.)

Errori tipici

1. Scambiare DNS e DHCP. Il DHCP dà l’indirizzo al PC; il DNS traduce i nomi. Il DHCP comunica l’indirizzo del DNS al PC, ma sono servizi diversi.
2. Dire che il DNS usa sempre UDP, o che HTTP “usa la porta 80” senza distinguere HTTPS (443).
3. Mettere il DNS prima del DHCP. Senza indirizzo IP e senza server DNS configurato, il PC non può chiedere nulla.
4. Dimenticare il livello di trasporto. DHCP e DNS sono UDP; HTTP e HTTPS sono TCP. È la domanda classica quando ti chiedono “come viaggia” un messaggio.
5. Confondere 301 e 404, o non sapere in quale famiglia sta un codice. Basta guardare la prima cifra.
6. Ricordare solo la sigla DORA senza sapere chi manda cosa: Discover e Request partono dal client, Offer e Acknowledge dal server.

Esercizio 1: la sequenza di pacchetti da un PC appena acceso

Traccia. Un PC è collegato alla rete 192.168.1.0/24. Il router 192.168.1.1 fa da gateway e da server DHCP, e il DHCP indica come DNS 203.0.113.53. Il PC apre https://www.esempio.it/, che risolve in 198.51.100.20. Elenca i messaggi in ordine, con protocollo di trasporto e porte. (Gli indirizzi sono fittizi, presi dalle classi riservate alla documentazione.)

Soluzione.

Controlli da fare, riga per riga:

• La porta del client (68, 53112, 50321) è un valore alto scelto dal sistema operativo, tranne la 68 che è fissa per il DHCP; quella del server è quella nota (67, 53, 443).
• I pacchetti verso 203.0.113.53 e 198.51.100.20 hanno IP di destinazione fuori dalla /24, ma MAC di destinazione quello del gateway: ecco perché l’ARP serve prima del DNS.
• Prima di TLS ci sono 11 messaggi: 4 DHCP, 2 ARP, 2 DNS, 3 TCP.
• Perché UDP per DHCP e DNS e TCP per HTTP? DHCP e DNS sono scambi brevi domanda-risposta e il DHCP parte senza IP; HTTP deve trasferire pagine intere, in ordine e senza perdite, e per questo si appoggia a TCP.

Su informatica non c’è ancora una verifica dedicata: nella categoria Verifiche tecnici trovi le simulazioni delle altre materie dell’indirizzo, utili per allenare tempi e formato, ma non su questo argomento.

Esercizio 2: leggere HTTP e dig

Traccia. Un PC manda la richiesta A e riceve la risposta B. Poi, per capire chi gestisce il sito, si lancia dig.

Richiesta A:

GET /corsi/informatica.html HTTP/1.1
Host: www.esempio.it
User-Agent: Mozilla/5.0
Accept: text/html

Risposta B:

HTTP/1.1 301 Moved Permanently
Location: https://www.esempio.it/corsi/informatica.html
Content-Length: 0

Risposta di dig www.esempio.it:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.esempio.it.            IN  A

;; ANSWER SECTION:
www.esempio.it.     300     IN  CNAME   web.esempio.it.
web.esempio.it.     120     IN  A       198.51.100.20

;; Query time: 38 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)

Domande e soluzioni.

a) Su quale porta è partita la richiesta A, e cosa deve fare ora il browser? La richiesta è in chiaro, quindi HTTP sulla porta 80. Il codice 301 (famiglia 3xx) dice che la pagina si è spostata in modo permanente a https://…. Il browser manda una nuova richiesta GET a quell’indirizzo, su TCP 443 con TLS. Ci sono quindi due connessioni TCP.

b) A cosa serve Host? Un solo server con un solo IP può ospitare molti siti: l’IP porta alla macchina, Host dice a quale sito è destinata la richiesta.

c) Quali record ci sono nella risposta dig e che indirizzo ha il sito? Un CNAME (www.esempio.it è un alias di web.esempio.it) e un A (web.esempio.it → 198.51.100.20). Il sito ha quindi indirizzo 198.51.100.20.

d) Con quale protocollo ha viaggiato la risposta, e di chi è? Dalla riga SERVER: UDP, porta 53, dal server DNS 203.0.113.53. Nei flag manca aa, quindi non è una risposta autorevole: arriva dal resolver. Ci sono rd (ricorsione richiesta) e ra (ricorsione disponibile).

e) Se dopo 100 secondi un altro PC chiede lo stesso nome allo stesso resolver, cosa succede? La risposta arriva dalla cache. Ogni record scala il suo TTL: il CNAME ha ancora $300-100=200$ secondi, il record A $120-100=20$. Fra altri 20 secondi il record A scade e il resolver rifà la domanda.

Esercizio 3: dove si è rotto?

Tre sintomi, tre diagnosi.

1. Un PC mostra l’indirizzo 169.254.37.12 e non naviga. Gli indirizzi 169.254.0.0/16 sono quelli che il sistema si assegna da solo quando non trova nessun server DHCP. Si controllano cavo, server DHCP e, se il server sta in un’altra rete, il relay.
2. Un PC ha 192.168.1.57/24, gateway e DNS configurati. ping 198.51.100.20 risponde, il browser dice “server non trovato” e ping www.esempio.it dà errore di risoluzione. La rete funziona: si è rotto il DNS.
3. Il browser mostra “404”. Il DNS ha risolto, TCP si è aperto, il server ha risposto: è la risorsa che manca (URL sbagliato). Con un 500 il problema sarebbe sul server.

Per ripassare

Disegna su un foglio la sequenza dell’esercizio 1, senza guardare la tabella, con porte e protocolli di trasporto; poi rifai le domande dell’esercizio 2 su un dig tuo, per esempio su un dominio qualsiasi dal tuo terminale. Il passo successivo, quando arriva il progetto di rete, è dove mettere questi servizi e con quali regole: ne parlo in VLAN e sicurezza in quinta.

Su informatica non c’è ancora una verifica dedicata: le altre prove le vedi nella categoria Verifiche tecnici. Il resto del programma è in /materie/informatica/. Se vuoi una mano su un punto che non ti torna, la diagnosi gratuita è su /contatti/.