--- id: "dns" kind: "glossary-term" title: "DNS" language: "it" category: "DNS e basi tecniche" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/it/glossario/dns/" translations: en: "https://tldlog.com/glossary/dns/" es: "https://tldlog.com/es/glosario/dns/" de: "https://tldlog.com/de/glossar/dns/" fr: "https://tldlog.com/fr/glossaire/dns/" pt-BR: "https://tldlog.com/pt/glossario/dns/" ru: "https://tldlog.com/ru/glossariy/dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns/" --- # DNS sistema dei nomi a dominio L'elenco mondiale che trasforma i nomi leggibili dalle persone, come example.com, negli indirizzi numerici usati dai computer. È organizzato come un albero. In cima c'è la zona radice, poi i domini di primo livello, poi i nomi sotto di essi. Senza il DNS, i nomi a dominio non funzionerebbero. Il DNS (Domain Name System, sistema dei nomi a dominio) è l'elenco di internet. I dispositivi si raggiungono tramite indirizzi IP numerici (IPv4 o IPv6), assegnati separatamente dai nomi a dominio, ma le persone usano nomi come example.com. Il DNS collega le due cose, così che un nome digitato in un browser o usato in un indirizzo email raggiunga il computer giusto. Nessuna singola organizzazione detiene l'intero elenco: è distribuito su molti server gestiti da molti operatori, che conservano le risposte in locale per un certo tempo per rendere tutto più veloce. ## Che cos'è il DNS e perché internet ne ha bisogno Il DNS ha la forma di un albero. In cima c'è la zona radice. Sotto si trovano i domini di primo livello (TLD), come .com o .es, e sotto ancora i nomi che le persone registrano. Un nome può contenere diversi tipi di record: indirizzi (record A per IPv4, record AAAA per IPv6), ma anche i nomi dei server responsabili (record NS) e i dati di sicurezza per il DNSSEC. ## Che cosa succede quando si digita un nome a dominio: una ricerca passo per passo Si supponga che un'app abbia bisogno dell'indirizzo di `www.example.com`. 1. L'app interroga lo stub resolver, un piccolo software DNS presente sul dispositivo. Questo passa la domanda a un resolver ricorsivo, di solito gestito dal fornitore di accesso a internet o da un servizio DNS pubblico. 2. Il resolver ricorsivo controlla prima la propria cache. Se ha già la risposta e il suo TTL (time to live, tempo di vita) non è scaduto, risponde subito. 3. Altrimenti parte dalla cima. Conosce gli indirizzi dei root server grazie a un elenco integrato, i root hints. 4. Un root server non conosce l'indirizzo di `www.example.com`. Risponde con un rinvio: dove trovare i server di .com. 5. Nemmeno un server di .com conosce la risposta finale. Risponde con un rinvio ai name server scelti dal titolare di example.com. 6. Uno di questi name server è autoritativo per example.com. Restituisce l'indirizzo in un record A o AAAA. Il resolver conserva la risposta per il tempo consentito dal TTL e la passa al dispositivo. ## Resolver e server autoritativi: chi chiede e chi risponde I resolver pongono domande per conto degli utenti. I server autoritativi rispondono con i dati delle zone che contengono, senza interrogare altri server. Sono i name server di un dominio, elencati nei suoi record NS. Alcuni resolver ricorsivi sono resolver DNS pubblici: servizi pensati per essere usati da chiunque su internet, al posto di quello fornito dal proprio fornitore di accesso. Il termine tecnico «open resolver» di solito indica un'altra cosa: un resolver che risponde a chiunque per errore, perché configurato male. Poiché ogni ricerca passa da un resolver, questo è anche un punto in cui i nomi possono essere filtrati. Gli standard DNS prevedono codici di errore per un nome bloccato per la policy dell'operatore stesso, bloccato su richiesta di terzi o filtrato su richiesta dell'utente. ## La delega: come il lavoro si divide dalla radice fino al dominio L'albero del DNS è diviso in zone. Si crea una divisione dove un'organizzazione vuole controllare una parte dell'albero, modificarne i dati in autonomia e delegarne a sua volta delle parti più in basso. Una zona madre delega una zona figlia pubblicando record NS che puntano ai name server della figlia. Per un dominio come example.com la catena è questa: - L'IANA gestisce la zona radice e registra quali server sono responsabili di ciascun TLD. Le funzioni IANA sono svolte da PTI, un'affiliata dell'ICANN, e l'IANA non fa pagare nulla per questi servizi. - Verisign, come Root Zone Maintainer in base a un accordo con l'ICANN, compila il file della zona radice secondo le istruzioni dell'IANA, lo firma con il DNSSEC e lo invia agli operatori dei root server. - I root server rispondono con rinvii ai name server di ciascun TLD. - Il registro del TLD pubblica nella propria zona i record NS di ogni nome registrato, più i record glue e i record DS dove servono. - I name server scelti dal titolare del dominio rispondono per il dominio stesso. Questa delega interna al DNS è diversa dalla delega di un TLD, che consiste nell'aggiungere un nuovo dominio di primo livello alla zona radice. ## Errori comuni come NXDOMAIN e SERVFAIL e che cosa significano Ogni risposta DNS contiene un codice di risposta. Due codici di errore ricorrono spesso. ### NXDOMAIN NXDOMAIN (codice 3, «name error») significa che il nome non esiste, e che non esiste nemmeno alcun nome sotto di esso. Le cause tipiche sono un errore di battitura, un dominio non registrato o un dominio la cui delega è stata rimossa dalla zona del TLD. ### SERVFAIL SERVFAIL (codice 2, «server failure») significa che la ricerca non è stata completata. Non dice che il nome manca, solo che non si è ottenuta una risposta affidabile. Le cause più comuni sono: - name server indicati per una zona ma non configurati per servirla; - name server che non rispondono, o guasti di rete lungo il percorso; - firme DNSSEC che non superano la convalida, nel qual caso un resolver che esegue la convalida deve restituire SERVFAIL. Un resolver può conservare una risposta SERVFAIL per cinque minuti al massimo. Gli Extended DNS Errors permettono a un server di aggiungere il motivo, come «DNSSEC Bogus». ### Un esempio pratico Si supponga che il titolare di example.com sposti il dominio su nuovi name server senza averli ancora configurati per servire la zona. I resolver che seguono la nuova delega possono restituire SERVFAIL finché i nuovi server non vengono configurati. ## Chi gestisce il DNS e chi lo paga Nessuna singola organizzazione gestisce il DNS. Ogni livello ha i propri operatori e il proprio modo di finanziarsi. - **Root server.** A ottobre 2026 le 13 identità nominali dei root server sono gestite da 12 organizzazioni indipendenti, tra cui università, aziende e la stessa ICANN, tramite più di 2.000 istanze in tutto il mondo. Gli operatori non sono pagati per questo servizio e lo finanziano da sé. - **TLD.** Ogni registro gTLD deve gestire il DNS del proprio TLD secondo livelli di servizio fissati nel contratto con l'ICANN. A ottobre 2026, in base al Registry Agreement base approvato il 12 marzo 2026, il servizio DNS deve essere disponibile il 100% del tempo, il che richiede che almeno due dei name server delegati del TLD rispondano correttamente. Un totale di 4 ore di indisponibilità del DNS in una settimana è la soglia per una transizione d'emergenza del registro. - **Domini.** Il titolare sceglie i name server autoritativi del dominio, pagando un provider oppure usando server inclusi gratuitamente in un altro servizio. Dal 1987 le regole ne chiedono più di uno: la RFC 1034 prevede che chi assume la gestione di una zona dimostri di avere name server ridondanti. - **Resolver.** I fornitori di accesso a internet e i servizi DNS pubblici gestiscono i resolver su cui si appoggiano gli utenti. ## Fonti - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 1034: Domain Names - Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034.txt) - [RFC 8914: Extended DNS Errors](https://www.rfc-editor.org/rfc/rfc8914.txt) - [Root Name Servers (IANA)](https://www.iana.org/domains/root/servers) - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Base Registry Agreement (ICANN), approved 12 March 2026](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-12-03-2026-en.pdf) ## termini correlati - [zona radice](https://tldlog.com/it/glossario/zona-radice/) - [resolver](https://tldlog.com/it/glossario/resolver/) - [name server](https://tldlog.com/it/glossario/name-server/) - [TLD](https://tldlog.com/it/glossario/tld/) - [nome a dominio](https://tldlog.com/it/glossario/nome-dominio/)