Modulo 1 · 1.4
Il viaggio di una richiesta DNS
Modulo 1: Cos'è il DNS? · Tempo di lettura: 8 minuti
Obiettivo della lezione: Dopo questa lezione sarà in grado di spiegare passo per passo come un resolver trova una risposta, e dove lungo il percorso le risposte vengono memorizzate.
Concetti chiave: resolver (ricorsivo), server root, server TLD, nameserver autoritativo, rinvio (delega), cache
Due tipi di server DNS
Nella lezione 1.1 ha visto che il DNS è distribuito: nessuno sa tutto. Come fa allora il Suo browser a ottenere l'indirizzo di www.example.com? Per questo collaborano due tipi di server:
- I nameserver autoritativi (in inglese authoritative) conoscono la risposta per la propria porzione. I nameserver di
example.comconoscono i record diexample.com. Non cercano nulla per conto di altri. - I resolver (detti anche resolver ricorsivi) cercano la risposta per Lei. Continuano a interrogare finché non la trovano. Il Suo provider internet dispone di un resolver, ed esistono resolver pubblici come quelli di Quad9, Cloudflare o Google.
Il Suo computer di per sé non cerca quasi nulla. Dispone di un piccolo stub resolver che inoltra la richiesta al resolver della Sua rete e ne riceve la risposta.
Il viaggio, passo per passo
Supponiamo che il resolver non abbia ancora memorizzato nulla e Lei chieda il record A di www.example.com.
- Il Suo computer chiede al resolver: "Qual è il record A di www.example.com?"
- Il resolver interpella un server root. Ogni resolver ha incorporato un elenco degli indirizzi dei server root. Il server root non sa nulla di
example.com, ma sa chi gestisce.com. Risponde con un rinvio: "Per questo deve rivolgersi ai nameserver di com: a.gtld-servers.net, b.gtld-servers.net, e così via." - Il resolver interpella un nameserver di .com. Anch'esso non conosce l'indirizzo IP di
www.example.com, ma sa quali nameserver haexample.com. Di nuovo un rinvio: "Lo chieda a ns1.hosting.example o ns2.hosting.example." - Il resolver interpella un nameserver di example.com. Questo è autoritativo per il dominio e fornisce la risposta: "www.example.com ha il record A 192.0.2.10."
- Il resolver restituisce la risposta al Suo computer. Il Suo browser si collega a 192.0.2.10.
Un rinvio da un livello superiore ai nameserver di un livello inferiore si chiama delega. La root delega .com a Verisign, .com delega example.com ai nameserver indicati dall'assegnatario del dominio. Per un dominio .nl funziona esattamente allo stesso modo, solo che la root rinvia ai nameserver di .nl (SIDN, la registry di .nl nei Paesi Bassi, ad esempio ns1.dns.nl). Lo vedrà Lei stesso nell'esercizio in fondo a questa lezione. Per questo è così importante che i nameserver presso il registro siano corretti (lezione 2.1).
La cache: non tutto il viaggio ogni volta
Se ogni resolver dovesse ricominciare dalla root a ogni richiesta, la root riceverebbe una quantità inimmaginabile di interrogazioni. Questo non accade, perché il resolver memorizza le risposte per un certo periodo. Questa memoria si chiama cache.
Per quanto tempo una risposta può essere memorizzata è indicato nella risposta stessa: il TTL (time to live), in secondi. Un TTL di 3600 significa: questa risposta può essere memorizzata per un'ora. Anche i rinvii vengono memorizzati. Un resolver che ha appena saputo quali nameserver ha .com non dovrà richiederlo di nuovo alla root la volta successiva.
Se qualcun altro presso lo stesso provider chiede un minuto dopo www.example.com, il resolver risponde immediatamente dalla propria cache. Nessun viaggio, nessuna attesa.
Le cache si trovano in più punti:
- nel resolver del Suo provider o nel resolver pubblico che utilizza;
- nel Suo sistema operativo (Windows, macOS, il Suo telefono);
- nel Suo browser;
- talvolta nel Suo router.
Questo rende tutto veloce ed efficiente, ma ha una conseguenza che incontrerà spesso in seguito: se modifica un record, le cache continueranno a restituire la vecchia risposta finché il loro TTL non sarà scaduto. Per questo qualcuno vede già una modifica mentre qualcun altro ancora no. Il modulo 6 tratta questo argomento in modo approfondito.
I server root
Esistono 13 nomi per i server root: da a.root-servers.net a m.root-servers.net. Sono gestiti da dodici organizzazioni diverse. Dietro ogni nome si trovano in realtà numerosi server in tutto il mondo, in centinaia di luoghi, che condividono lo stesso indirizzo (questo si chiama anycast). Il Suo resolver raggiunge automaticamente quello più vicino. Anche i nameserver dei TLD, come quelli di .com e .nl, funzionano così. Per questo il DNS è veloce e continua a funzionare anche se un server smette di rispondere.
Dove le cose possono andare storte
Conoscendo il viaggio, è più facile individuare i problemi:
- La delega non è corretta. Presso il registro sono indicati nameserver che non conoscono (più) il dominio. Il resolver non riesce allora a proseguire al passo 4. La risposta sarà un errore oppure non arriverà alcuna risposta.
- Il server autoritativo fornisce una risposta diversa da quella attesa. In questo caso ha modificato il record in un punto diverso da dove si trovano i nameserver (lezione 2.1).
- La cache ha ancora la vecchia risposta. In questo caso non c'è nulla di rotto. Deve attendere che il TTL scada, oppure svuotare la Sua cache.
- Il DNSSEC non è corretto. Un resolver validante controlla le firme lungo il percorso. Se la catena non è corretta, rifiuta la risposta (lezione 8.1).
Con lo strumento dig +trace può ripercorrere il viaggio da sé, dalla root fino al server autoritativo. Lo imparerà nella lezione 8.2. Anche alcuni strumenti online possono farlo.
Riepilogo
- I nameserver autoritativi conoscono la risposta per il proprio dominio; i resolver cercano la risposta per Lei.
- Un resolver inizia dalla root, riceve un rinvio verso il TLD, poi verso i nameserver del dominio, e lì ottiene la risposta.
- Un rinvio di questo tipo si chiama delega.
- Le risposte vengono memorizzate nelle cache, per tutto il tempo indicato dal TTL; per questo le modifiche non sono visibili ovunque immediatamente.
- Esistono 13 nomi di server root, ma grazie all'anycast dietro ciascuno si trovano numerosi server in tutto il mondo.
Quiz
Esercizio
Esercizio Z1.4: Seguire il viaggio. Segua il viaggio per www.sidn.nl, con dig +trace www.sidn.nl oppure uno strumento online che mostri una trace. Compili: (1) un nameserver di nl. che incontra lungo il percorso, (2) un nameserver autoritativo di sidn.nl.
Per approfondire
Questi articoli descrivono la situazione presso WebOké. Presso altri fornitori il funzionamento è simile.