---
id: "name-server"
kind: "glossary-term"
title: "name server"
language: "it"
category: "DNS e basi tecniche"
updated: "2026-10-10T23:13:06Z"
canonical: "https://tldlog.com/it/glossario/name-server/"
translations:
  en: "https://tldlog.com/glossary/name-server/"
  es: "https://tldlog.com/es/glosario/servidor-nombres/"
  de: "https://tldlog.com/de/glossar/nameserver/"
  fr: "https://tldlog.com/fr/glossaire/serveur-noms/"
  pt-BR: "https://tldlog.com/pt/glossario/servidor-nomes/"
  ru: "https://tldlog.com/ru/glossariy/dns-server/"
  zh-Hans: "https://tldlog.com/zh/cihui/yuming-fuwuqi/"
---

# name server

Un server che conserva i record DNS e risponde alle domande sui nomi a dominio. Perché un dominio funzioni, il registrar comunica al registro quali name server contengono i suoi record. Cambiare i name server di un dominio cambia il posto in cui si trovano il suo sito web e la sua email.

Un name server è il computer che risponde quando qualcuno chiede dove si trovano il sito web o la posta elettronica di un dominio. Ogni dominio deve averne almeno due, e il registrar li comunica al registro. Se mancano, sono errati o spenti, il dominio smette di funzionare, anche se resta registrato.

## Che cosa fa un name server per un dominio

Le espressioni «name server» e «server DNS» coprono due compiti. I server autoritativi conservano i record DNS di un dominio e rispondono per esso; i resolver pongono quelle domande per conto degli utenti. La RFC 9499 (marzo 2024), il documento sulla terminologia del DNS, osserva che entrambi sono spesso chiamati name server. Qui il termine indica quelli autoritativi.

La zona sopra il dominio, gestita dal registro del suo TLD, contiene record NS che indicano i server del dominio. Questa delega dice ai resolver a chi chiedere. Il registrar invia questi nomi al registro tramite EPP. Un dominio senza name server ha lo stato inactive e non si risolve.

La RFC 1034 (novembre 1987) richiede che ogni zona si trovi su almeno due server, così da sopravvivere al guasto di uno. Il rapporto SAC125 dello SSAC (9 maggio 2024) osserva che i registri di solito ne richiedono almeno due alla registrazione e a ogni aggiornamento.

## Registrar, provider DNS e hosting: chi gestisce i name server

Sono coinvolti tre ruoli, svolti da una sola azienda o da tre:

- Il registrar comunica al registro quali name server usa il dominio.
- Il provider DNS gestisce quei server e la zona con i record del dominio. Può essere il registrar, un servizio di hosting o uno specialista.
- I servizi di hosting web e di posta gestiscono i servizi a cui puntano i record.

Cambiare provider DNS non cambia il registrar: vengono sostituiti solo i name server indicati per il dominio.

## Come cambiare i name server, passo dopo passo

1. Configurare prima la zona presso il nuovo provider DNS, con tutti i record usati dal dominio, compresi quelli del sito e della posta, e con record NS corrispondenti ai nuovi name server.
2. Se il dominio è firmato con DNSSEC, un record DS che punta ancora alle vecchie chiavi può renderlo irraggiungibile per i resolver che verificano le firme. Se il vecchio operatore non collabora, la RFC 6781 descrive questo ordine: chiedere la rimozione del record DS, cambiare i name server, attendere che la modifica si sia diffusa nel DNS, quindi aggiungere un record DS per la zona appena firmata. Fino ad allora il dominio non è protetto da DNSSEC.
3. Verificare che il dominio non sia bloccato contro le modifiche: finché è impostato clientUpdateProhibited o serverUpdateProhibited, il registro rifiuta le modifiche. Il registrar toglie clientUpdateProhibited; serverUpdateProhibited (registry lock) può essere rimosso solo dal registro, tramite il registrar.
4. Inserire i nuovi name server presso il registrar, che li trasmette al registro. Indicarne almeno due, idealmente su reti separate.
5. Mantenere attivo per un po' il vecchio servizio: i resolver conservano copie delle risposte, quindi alcuni visitatori raggiungono i vecchi server per ore o più. Non cancellare la vecchia zona lo stesso giorno.

Regole, blocchi e tempi dipendono dal registro e dal registrar: prima di cambiare un dominio importante conviene verificare con loro.

## Glue record e name server all'interno del proprio dominio

Si prenda example.com, con i name server ns1.example.com e ns2.example.com. Per trovare ns1.example.com, un resolver dovrebbe prima interrogare i name server di example.com: proprio i server che sta cercando. La soluzione è il glue record: il registro pubblica gli indirizzi IP di quei server insieme alla delega. La RFC 9471 (settembre 2023) rende obbligatorio questo glue nelle risposte di rinvio, e osservava allora che gli indirizzi (record A e AAAA) erano l'unico tipo di glue definito.

Nel registro ogni name server è un host object. Poiché ns1.example.com si trova sotto example.com, il dominio deve esistere prima; il registrar crea poi l'host object con i suoi indirizzi IP e vi collega il dominio. Gli indirizzi sono obbligatori solo quando serve il glue: se example.com usasse ns1.example.net, il registro di .com non avrebbe bisogno di glue per quel server.

## Server primari e secondari, e perché la ridondanza conta

Il server primario conserva la copia della zona in cui si fanno le modifiche. I server secondari la copiano con un trasferimento di zona: un trasferimento completo (AXFR) copia l'intera zona, uno incrementale (IXFR) solo ciò che è cambiato. Il protocollo DNS UPDATE (RFC 2136), la parte standard del DNS dinamico, aggiunge o elimina record senza modificare la zona a mano.

Due server sono il minimo, non la raccomandazione: la RFC 2182 (luglio 1997) avverte che una zona con soli due server, quando uno si guasta, in realtà funziona con uno solo, e raccomanda tre server per la maggior parte delle organizzazioni, con almeno uno ben separato dagli altri, e quattro o cinque per un'affidabilità maggiore.

I requisiti tecnici dell'IANA (rivisti l'ultima volta il 14 novembre 2024, a ottobre 2026) si applicano solo alla zona radice, a .INT e a .ARPA, ma sono un utile elenco di controllo: almeno due record NS su indirizzi IP diversi, server in almeno due reti topologicamente separate, risposte autoritative e nessun servizio ricorsivo.

## Che cosa va storto: lame delegation e server dimenticati

«Lame delegation» indica diversi guasti: un server indicato che non risponde, non è raggiungibile o risponde con un errore o senza autorità. La RFC 9499 raccomanda termini più specifici. In ogni caso le ricerche rallentano o falliscono. Una causa comune è un server dimenticato: un assegnatario lascia un provider DNS senza cambiare i record NS, e il dominio resta delegato a server che non rispondono più per esso, il che può aprire la strada a un'acquisizione del controllo.

Un rischio meno visibile: secondo il SAC125, la maggior parte dei registri rifiuta di cancellare un dominio scaduto finché altri domini dipendono da esso, e la RFC 5731 afferma che non dovrebbe essere cancellato finché i suoi host object non sono stati cancellati o rinominati. Alcuni registrar li hanno rinominati all'interno di un altro dominio. Il SAC125 li chiama sacrificial name server, non sicuri quando quell'altro dominio può essere registrato: chi lo registra controlla la risoluzione di tutti i domini che li usano ancora. Secondo il rapporto, a settembre 2020 questo aveva esposto oltre 500.000 domini gTLD al rischio di dirottamento, e la risoluzione di oltre 163.000 era passata sotto un controllo non autorizzato; il SAC125 osserva che l'estensione del problema nei ccTLD non è nota. Raccomanda un codice di condotta per registri e registrar; a ottobre 2026 non risultava confermata l'adozione di alcun codice.

Rinnovare i domini che ospitano i propri name server riduce questo rischio.

## Fonti

- [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt)
- [RFC 2182: Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.txt)
- [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt)
- [Technical requirements for authoritative name servers (IANA)](https://www.iana.org/help/nameserver-requirements)
- [SAC125: SSAC Report on Registrar Nameserver Management](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf)

## termini correlati

- [server autoritativo](https://tldlog.com/it/glossario/server-autoritativo/)
- [record NS](https://tldlog.com/it/glossario/record-ns/)
- [record glue](https://tldlog.com/it/glossario/record-glue/)
- [DNS](https://tldlog.com/it/glossario/dns/)
