DNS - struttura, risoluzione, record
Dal nome leggibile all'IP numerico: come il Domain Name System organizza Internet in una gerarchia distribuita, come avviene la risoluzione ricorsiva e iterativa e quali record rendono possibile ogni servizio.
1. Servizi Internet e ruolo del DNS
Il DNS (Domain Name System) è il servizio di livello applicativo che traduce nomi di dominio leggibili (es. www.example.com) in indirizzi IP numerici utilizzati per instradare i pacchetti.
Internet non è solo cavi e router: è un ecosistema di servizi di livello applicativo standardizzati che garantiscono interoperabilità. HTTP/HTTPS per il Web, FTP per i file, SMTP/POP3/IMAP per la posta, RTP per VoIP/streaming, SSH per accesso remoto sicuro e — al centro di tutto — DNS per la risoluzione dei nomi. Senza DNS dovremmo ricordare IP come 142.250.184.36.
HTTP/HTTPS
World Wide Web, ma prima di caricare una pagina serve risolvere il nome del server
DNS
Rubrica distribuita globale: il primo servizio invocato quando digiti un URL
SMTP / MX
Anche l'invio email dipende dal DNS per trovare il mail server di destinazione
Apri il browser in aula laboratorio e vai su https://cisco.com. Prima della connessione TCP/443, il PC fa una query A verso il resolver configurato (es. 8.8.8.8). Se osservate Wireshark vedrete: query DNS standard per cisco.com IN A, risposta con IP e TTL. Disattivate la rete WiFi e provate a pingare 8.8.8.8: funziona via IP, ma digitare google.com fallisce perché senza DNS non c'è traduzione.
All'interrogazione: parti dall'analogia "rubrica telefonica distribuita". Poi aggiungi: è gerarchico, distribuito, con caching. Se ti chiedono perché indispensabile, rispondi: usabilità + scalabilità: impossibile memorizzare hosts.txt centralizzato come negli anni '70.
2. Struttura gerarchica: root, TLD, domini e sottodomini
Il DNS è un database distribuito ad albero. Ogni nome è un percorso dalla radice verso le foglie, letto da destra a sinistra. Il punto finale . rappresenta la root ed è logico anche quando non lo scriviamo.
Root "."
Punto finale implicito. 13 nomi logici (A-M.root-servers.net) replicati con anycast in centinaia di istanze worldwide.
TLD
Top Level Domain: .com .org .net .edu + ccTLD .it .fr .de .jp + nuovi gTLD .tech .cloud .school
Second Level Domain
Nome scelto e registrato: google in google.com, aruba in aruba.it. È l'identità dell'organizzazione.
Sottodomini
Creati dal titolare senza registrazione extra: www, mail, ftp, blog, shop. Organizzano servizi diversi sullo stesso dominio.
Confondere TLD con dominio: .com è TLD, google.com è SLD+TLD, www.google.com include sottodominio. In verifica disegna sempre l'albero con frecce e livelli.
3. IANA, ICANN, Whois e tipologie di TLD
La gestione globale non è casuale: IANA gestisce numeri, TLD, parametri; ICANN supervisiona policy, accredita i registrar e garantisce stabilità della root zone. Senza questo governo, collisioni e abusi sarebbero inevitabili.
| Tipo | Descrizione | Esempi |
|---|---|---|
| gTLD | Domini generici internazionali storici | .com .org .net .edu .info |
| ccTLD | Associati a uno Stato ISO (2 lettere) | .it .fr .de .uk .jp .us |
| nuovi gTLD | Introdotti dopo 2013 per verticali | .tech .online .cloud .school .shop |
Whois è il protocollo/servizio che espone informazioni pubbliche su un dominio: registrar, data registrazione/scadenza, name server autoritativi, stato. Utile per troubleshooting, sicurezza, contenziosi.
Su https://lookup.icann.org/ cercate profgiagnotti.altervista.org e poi google.com. Annotate: registrar, created, expiry, name servers. Notate che i sottodomini Altervista non hanno Whois diretto perché è il dominio altervista.org a essere registrato. Confrontate un ccTLD (.it) con un gTLD (.com): policy diverse su privacy.
4. Come funziona: resolver, server e risoluzione ricorsiva vs iterativa
Resolver = client DNS del PC (stub) + server ricorsivo del provider/Google/Cloudflare che esegue il lavoro. Root server = conosce i TLD. Authoritative = conosce la zona e risponde con l'IP finale.
Resolver
Di solito 8.8.8.8, 1.1.1.1 o quello ISP. Cache + recursion. Primo interrogato dal browser.
Root Server
Non sa l'IP finale, ma sa dove sono i TLD. Risponde con referral a .com, .it, etc.
Authoritative
Gestisce la zona example.com e possiede i record A/AAAA/MX. Risposta definitiva.
Nella pratica quotidiana: il PC chiede ricorsione al resolver del provider (flag RD=1), il resolver poi esegue una serie di query iterative verso root, TLD e authoritative finché non ottiene la risposta. Il caching a ogni livello riduce drasticamente il traffico verso la root.
Disegna due colonne: sinistra Client-Resovler (ricorsiva), destra Resolver-Root-TLD-Auth (iterativa). Se all'interrogazione ti dicono "spiega iterativa" inizia da "ogni server non risponde direttamente ma ti dice chi interrogare dopo".
Dire che il root conosce l'IP di google.com. No: il root conosce solo i server .com. È l'authoritative di google.com che conosce l'IP. La delega è il cuore del DNS.
5. I record DNS: A, AAAA, MX, NS, CNAME, PTR, SOA, TXT
Un record è una tupla: Name (FQDN), Value (dato), Type, Class (quasi sempre IN=Internet), TTL (secondi di permanenza in cache). Il TTL basso favorisce aggiornamenti rapidi, TTL alto riduce query.
| Tipo | Ruolo | Esempio reale |
|---|---|---|
| A | Nome → IPv4 (host) | example.com → 93.184.216.34 |
| AAAA | Nome → IPv6 | example.com → 2606:2800:220:1::32 |
| MX | Mail Exchange, indica server posta + priorità | example.com → mail.example.com (pref 10) |
| NS | Name Server autoritativi della zona | example.com → ns1.example.com |
| CNAME | Alias: un nome punta a altro nome canonico | www.example.com → example.com |
| PTR | Risoluzione inversa IP → nome (in zona in-addr.arpa) | 34.216.184.93 → example.com |
| SOA | Start of Authority: primario, email admin, serial, refresh | Zona example.com, serial 2024050101 |
| TXT | Testo libero: SPF, DKIM, DMARC, verifica ownership | v=spf1 include:_spf.google.com ~all |
MX e priorità
Posso avere più MX con pref diverse. A parità di priorità = round robin. Senza MX, la posta non arriva.
CNAME vs A
CNAME non deve coesistere con altri record sullo stesso nome. Se usato su apex (dominio nudo) rompe MX/NS: meglio ANAME/ALIAS del provider.
TXT = SPF/DKIM
Verifica anti-spam: SPF dice quali IP possono spedire, DKIM firma crypto, DMARC dice cosa fare se falliscono.
Digitate: nslookup → set type=MX → gmail.com. Vedete 5 server con priorità. Poi set type=TXT → gmail.com mostra SPF. Infine set type=NS → google.com. Questo dimostra che un nome ha più tipi di record contemporaneamente, ma distribuiti su server diversi.
6. Cache, TTL e comandi pratici
Il DNS è velocissimo grazie al caching: resolver, browser, OS mantengono le risposte per TTL secondi. TTL alto = meno query, ma propagazione lenta delle modifiche. TTL basso (60-300s) utile prima di migrazioni.
1) ipconfig /displaydns | more → cercate TTL residuo. 2) Cambiate DNS da automatico a 1.1.1.1 e 8.8.8.8: notate tempi diversi con nslookup. 3) Su Wireshark filtrate dns e aprite una pagina mai visitata: contate query A, AAAA, CNAME. 4) Verificate se il sito della scuola ha record AAAA (IPv6 ready?).
Prima di una verifica su DNS, svuota cache browser + OS, altrimenti vedi risposte vecchie. E ricorda: dig mostra flags utili: qr rd ra, status NOERROR/NXDOMAIN, ANSWER section, QUERY TIME.
7. Verifica / Esercizio
🔬 Attività pratica - Analizza www.itis Rossi
La segreteria ha registrato itisrossi.edu.it con zona gestita da ns1.itisrossi.edu.it. Devi progettare i record per: sito web, posta, IPv6, alias www.
- Scomponi
www.itisrossi.edu.itin sottodominio, SLD, TLD, root e indica tipo TLD. - Descrivi la catena di risoluzione completa quando un alunno digita www.itisrossi.edu.it da casa (IP 8.8.8.8 come resolver).
- Scrivi i record DNS minimali (A, AAAA, MX, NS, CNAME, TXT SPF) supponendo IP 79.2.10.20 e mail su stesso IP.
- Spiega cosa succede se metti TTL=86400 e poi cambi IP il giorno dell'open day.
- Quale record useresti per verificare proprietà dominio su Google Search Console?
1) Scomposizione: . = root implicita, .it = ccTLD (country code Italia), edu = SLD? No, in questo caso edu.it è SLD esteso gestito con regole .it (itisrossi è terzo livello ma funzionalmente SLD registrato), www = sottodominio. TLD .it è ccTLD.
2) Catena: Browser → stub resolver PC → resolver ricorsivo 8.8.8.8 (cache miss) → Root . (referral a server .it) → TLD .it (referral a ns1.itisrossi.edu.it) → Authoritative ns1 risponde con A 79.2.10.20 → Resolver cache + risposta al client. In realtà Google ha già in cache TLD .it, quindi 1 query a authoritative basta.
3) Record esempio: @ IN NS ns1.itisrossi.edu.it. | @ IN A 79.2.10.20 | @ IN AAAA 2001:db8::1 | @ IN MX 10 mail.itisrossi.edu.it. | mail IN A 79.2.10.20 | www IN CNAME @ | @ IN TXT "v=spf1 ip4:79.2.10.20 ~all"
4) TTL: Con TTL 86400 (24h), resolver di tutto il mondo mantengono vecchio IP per 24h → parte utenza vede sito vecchio non raggiungibile. Prima di cambio IP abbassa TTL a 300s per 48h, poi modifica, poi rialza.
5) Verifica ownership: Record TXT con token fornito da Google (es. google-site-verification=...). TXT è il canale standard per prove di possesso.
8. Riepilogo e concetti chiave
📚 Prossimo passo - DNS messaggi UDP TCP DNSSEC DDNS
Ora che sai struttura e record, vedremo come il DNS parla davvero: formato messaggi, perché usa UDP e quando passa a TCP, come DNSSEC firma le risposte contro spoofing e come DDNS aggiorna IP dinamici. Porta appunti su TTL e preparati a catturare un pacchetto DNS reale.