Nameserver e DNS: cosa sono e come configurarli per un sito stabile e raggiungibile

Quando si registra un dominio, si trasferisce un sito web oppure si attiva un nuovo servizio di hosting, è facile incontrare espressioni come nameserver, zona DNS, record A, CNAME, MX e TTL. Per chi non possiede competenze tecniche, queste sigle possono apparire complesse e poco comprensibili. In realtà, descrivono il sistema che permette a un dominio di indirizzare correttamente gli utenti verso un sito, consegnare i messaggi di posta elettronica e collegarsi a servizi esterni.

Comprendere nameserver e DNS è importante perché un errore nella loro configurazione può rendere un sito irraggiungibile, interrompere il funzionamento delle caselle e-mail, impedire la verifica di un dominio oppure compromettere alcuni servizi digitali. Non è quindi un argomento riservato esclusivamente agli amministratori di sistema: anche proprietari di siti, aziende e professionisti dovrebbero conoscerne almeno i principi fondamentali.

Il Domain Name System, abbreviato in DNS, può essere considerato un sistema di traduzione. Gli utenti ricordano facilmente un nome come esempio.it, mentre i computer comunicano utilizzando indirizzi numerici chiamati indirizzi IP. Il DNS collega il nome del dominio all’indirizzo del server che ospita il sito. ICANN descrive infatti il DNS come il sistema che facilita la navigazione consentendo di utilizzare un nome testuale al posto di un indirizzo IP difficile da ricordare.

Nei prossimi paragrafi vedremo come funziona il sistema DNS, quali sono le differenze tra nameserver e record, come eseguire una configurazione corretta e quali errori evitare durante modifiche, trasferimenti e migrazioni.

“La grande innovazione fu permettere a tutti di gestire la propria rete rendendo visibili ovunque le modifiche.”
— Paul Mockapetris

Che cosa sono nameserver e DNS e perché sono indispensabili

Per capire che cosa sono nameserver e DNS, conviene partire dal problema che risolvono. Ogni dispositivo connesso a Internet utilizza uno o più indirizzi IP per comunicare. Un server potrebbe, per esempio, essere raggiungibile tramite un indirizzo IPv4 composto da quattro gruppi numerici oppure tramite un indirizzo IPv6 molto più lungo.

Memorizzare questi indirizzi sarebbe poco pratico. Inoltre, un sito potrebbe cambiare server e quindi indirizzo IP senza modificare il proprio nome pubblico. Il DNS introduce un livello intermedio che separa il nome utilizzato dagli utenti dall’infrastruttura tecnica che eroga il servizio.

Quando una persona digita un dominio nel browser, il dispositivo deve scoprire quale indirizzo IP contattare. Questa operazione prende il nome di risoluzione DNS. La richiesta attraversa diversi componenti, ciascuno con una funzione precisa, fino a ottenere una risposta considerata attendibile.

Il DNS non è un unico archivio centrale contenente tutti i domini del mondo. È una struttura gerarchica e distribuita, progettata in modo che differenti soggetti possano gestire parti specifiche dello spazio dei nomi. Le specifiche fondamentali del sistema sono descritte nelle RFC 1034 e 1035 dell’Internet Engineering Task Force. (IETF Datatracker)

Questa struttura distribuita permette al sistema di crescere e di continuare a funzionare senza dipendere da un solo database globale. L’Internet Society ricorda che il DNS venne ideato da Paul Mockapetris proprio per sostituire la precedente gestione basata su una tabella centralizzata degli host, diventata inadeguata con l’aumento delle reti collegate. (Internet Society)

Come avviene la risoluzione di un dominio

Quando viene richiesto un indirizzo come www.esempio.it, il browser controlla innanzitutto se possiede già una risposta memorizzata nella cache. Se non la trova, la richiesta viene inviata a un resolver ricorsivo, normalmente fornito dall’operatore Internet, dal sistema aziendale o da un servizio DNS scelto dall’utente.

Il resolver esegue una serie di interrogazioni:

1. contatta l’infrastruttura DNS radice;
2. individua i server responsabili dell’estensione, per esempio .it;
3. riceve l’indicazione dei nameserver autorevoli del dominio;
4. interroga uno di questi nameserver;
5. ottiene il record necessario, come l’indirizzo IP associato al sito;
6. restituisce la risposta al browser.

La zona radice rappresenta il punto più alto della gerarchia. IANA spiega che i root name server sono configurati come 13 autorità denominate, ma il servizio è materialmente distribuito attraverso centinaia di server presenti in numerosi Paesi.

Il passaggio tra questi livelli avviene normalmente in una frazione di secondo. Molte risposte vengono inoltre conservate temporaneamente nelle cache, riducendo il numero di richieste necessarie e velocizzando le interrogazioni successive.

Il resolver ricorsivo e il nameserver autorevole svolgono quindi funzioni differenti. Il resolver cerca la risposta per conto dell’utente, mentre il server autorevole conserva e comunica le informazioni ufficiali della zona DNS.

Un server autorevole può contenere, per esempio:

• l’indirizzo IPv4 del dominio;
• l’indirizzo IPv6 del server;
• il server destinato a ricevere la posta;
• i sottodomini configurati;
• le verifiche richieste da piattaforme esterne;
• le politiche utilizzate per autenticare l’invio delle e-mail.

ICANN definisce un authoritative name server come il server DNS che ospita il database ufficiale dei resource record di una zona. Questo database identifica gli indirizzi dei server web, dei server di posta e degli altri nameserver appartenenti alla zona.

La gerarchia DNS: root, estensioni, domini e sottodomini

Un nome di dominio è organizzato secondo livelli gerarchici. La lettura tecnica avviene da destra verso sinistra.

Nel dominio blog.esempio.it possiamo distinguere:

• .it, cioè il dominio di primo livello o TLD;
• esempio, cioè il dominio registrato;
• blog, cioè il sottodominio.

Al vertice della struttura si trova la root, rappresentata tecnicamente da un punto finale che normalmente non viene mostrato. La zona radice contiene le deleghe verso i domini di primo livello, tra cui estensioni generiche come .com e .org ed estensioni nazionali come .it, .fr o .de. IANA mantiene il database delle deleghe dei top-level domain. (ANAI)

Il registro responsabile dell’estensione conserva le informazioni necessarie per sapere quali nameserver sono stati assegnati al dominio. I nameserver indicati presso il registrar devono poi essere in grado di fornire risposte autorevoli e coerenti.

Questa distinzione spiega perché esistano almeno due livelli di configurazione:

• la delega del dominio, effettuata presso il registrar attraverso i nameserver;
• la zona DNS, gestita dal provider indicato attraverso i record.

Modificare un record A nella zona DNS non equivale a cambiare nameserver. Nel primo caso si modifica una singola destinazione mantenendo lo stesso gestore DNS. Nel secondo caso si trasferisce l’intera autorità DNS verso un altro sistema.

Un dominio può anche utilizzare diversi sottodomini senza acquistare nuove registrazioni. Per esempio, un’azienda potrebbe configurare:

• www.azienda.it per il sito istituzionale;
• shop.azienda.it per l’e-commerce;
• area.azienda.it per il portale clienti;
• mail.azienda.it per un servizio di posta;
• crm.azienda.it per un’applicazione interna.

Ogni sottodominio può puntare allo stesso server del dominio principale oppure a un’infrastruttura completamente differente. La zona DNS consente quindi di coordinare servizi diversi mantenendo un’identità digitale coerente.

Differenza tra nameserver, zona DNS, dominio e hosting

Uno degli errori più comuni consiste nel confondere dominio, nameserver, DNS e hosting. Questi elementi collaborano tra loro, ma non svolgono la stessa funzione.

Il dominio è il nome registrato, come azienda.it. Il registrar è il fornitore attraverso il quale il dominio viene registrato e rinnovato. Il registro è l’organizzazione responsabile dell’estensione. L’hosting ospita i file e il database del sito. I nameserver indicano dove si trova la gestione autorevole del DNS. La zona DNS contiene i record che regolano i singoli servizi.

È possibile acquistare tutto dallo stesso provider. In questo caso, la configurazione iniziale viene spesso eseguita automaticamente: il dominio utilizza i nameserver del fornitore, la zona contiene l’indirizzo dell’hosting e la posta viene predisposta secondo il servizio scelto.

Una configurazione più articolata può invece prevedere:

• dominio registrato presso il provider A;
• nameserver gestiti dal provider B;
• sito ospitato dal provider C;
• posta elettronica erogata dal provider D;
• CDN e protezione del traffico gestite dal provider E.

Questa architettura è perfettamente possibile, purché ogni record sia configurato correttamente. Il registrar non deve necessariamente coincidere con il gestore DNS o con l’hosting.

Nameserver e record DNS non sono la stessa cosa

I nameserver vengono generalmente indicati attraverso nomi simili a:

ns1.provider.example
ns2.provider.example

Questi valori vengono inseriti nel pannello del registrar. Il loro compito è comunicare all’infrastruttura DNS globale quale servizio possiede la zona autorevole del dominio.

All’interno del pannello del gestore DNS si trovano invece i record. Una zona semplificata potrebbe contenere:

@      A       192.0.2.10
www    CNAME   esempio.it
@      MX      10 mail.esempio.it
mail   A       192.0.2.20

Il simbolo @ indica normalmente il dominio principale. Il primo record collega il dominio all’indirizzo IPv4 del server web. Il secondo fa in modo che www utilizzi il dominio principale come destinazione. Il terzo individua il server di posta, mentre il quarto associa il nome del server di posta a un indirizzo IP.

Cambiare i nameserver significa affidare l’intera zona a un altro gestore. Se la nuova zona non contiene tutti i record necessari, alcuni servizi smetteranno di funzionare.

Per esempio, durante una migrazione potrebbe essere copiato il record del sito ma non quello della posta. In questo caso il sito risulterebbe raggiungibile, mentre le e-mail potrebbero non essere recapitate. Potrebbero inoltre mancare record TXT utilizzati per autenticazione, verifica della proprietà, newsletter, strumenti di analisi o piattaforme aziendali.

Prima di sostituire i nameserver è quindi necessario replicare integralmente la zona DNS, verificando almeno:

• record del dominio principale;
• record relativi a www;
• sottodomini;
• configurazione e-mail;
• record SPF, DKIM e DMARC;
• verifiche di servizi esterni;
• eventuali record SRV;
• configurazioni IPv6;
• DNSSEC, quando attivo.

Quando si modifica soltanto l’hosting, non è sempre necessario cambiare nameserver. Se la zona DNS viene mantenuta presso lo stesso fornitore, può essere sufficiente aggiornare il record A o CNAME relativo al sito.

Questa soluzione riduce il numero di elementi coinvolti e può rendere la migrazione più controllabile. La scelta dipende però dall’architettura utilizzata, dal livello di assistenza disponibile e dalle funzionalità offerte dal gestore DNS.

Chi gestisce i nameserver e come individuarli

I nameserver possono essere gestiti dal registrar, dal provider hosting, da una piattaforma DNS specializzata oppure da un’infrastruttura proprietaria.

Per individuarli è possibile consultare:

• il pannello di gestione del dominio;
• la documentazione del provider;
• i dati pubblici di delega;
• strumenti di interrogazione DNS;
• i comandi dig o nslookup;
• il supporto tecnico del fornitore.

Un’interrogazione NS restituisce i nameserver dichiarati per il dominio. È tuttavia opportuno verificare anche la coerenza tra la delega pubblicata dal registro e i record NS presenti nella zona autorevole.

Durante un trasferimento del dominio, i nameserver possono rimanere invariati. Trasferire il dominio da un registrar a un altro non implica automaticamente il trasferimento del sito, della posta o della zona DNS. Prima di avviare l’operazione è comunque prudente verificare le condizioni del nuovo provider, perché alcuni registrar includono il servizio DNS solo per i domini mantenuti presso di loro.

Occorre distinguere anche il trasferimento del dominio dalla migrazione del sito:

• il trasferimento del dominio cambia il registrar;
• la migrazione dell’hosting sposta file e database;
• la modifica dei nameserver cambia il gestore della zona DNS;
• la modifica dei record cambia la destinazione di uno o più servizi.

Queste operazioni possono essere eseguite insieme, ma non sono equivalenti. Separarle permette di pianificare il lavoro con maggiore precisione e di individuare più facilmente la causa di eventuali problemi.

Un’azienda che desidera centralizzare dominio, hosting e assistenza può valutare un servizio professionale di gestione di domini e hosting. La centralizzazione non è obbligatoria, ma può ridurre la frammentazione delle responsabilità e facilitare gli interventi tecnici.

Quali record configurare nella zona DNS

I record DNS sono istruzioni associate a un nome. Ogni tipologia risponde a una domanda specifica: dove si trova il sito, quale server riceve le e-mail, quale servizio può inviarle oppure quale piattaforma deve essere considerata autorizzata.

Una zona può contenere pochi record oppure decine di configurazioni. Non è consigliabile aggiungere record senza una necessità precisa. Allo stesso modo, non bisogna eliminare valori apparentemente inutili senza averne identificato la funzione.

Record A, AAAA, CNAME e ALIAS

Il record A associa un nome a un indirizzo IPv4. È uno dei record più utilizzati per collegare un dominio al server web.

Esempio:

@    A    192.0.2.10

Il valore @ indica il dominio principale. Se il dominio fosse esempio.it, la configurazione stabilirebbe che esempio.it deve essere risolto verso l’indirizzo indicato.

Il record AAAA svolge una funzione analoga, ma utilizza un indirizzo IPv6:

@    AAAA    2001:db8::10

IPv4 e IPv6 possono coesistere. In questo caso i dispositivi compatibili possono utilizzare il protocollo più appropriato. È però importante non pubblicare un record AAAA se il server non è realmente configurato per rispondere correttamente tramite IPv6. Una configurazione incoerente potrebbe generare problemi intermittenti per una parte degli utenti.

Il record CNAME indica che un nome è un alias di un altro nome:

www    CNAME    esempio.it

La configurazione comunica che www.esempio.it deve seguire la destinazione assegnata a esempio.it. Il vantaggio è la possibilità di modificare l’indirizzo del dominio principale senza aggiornare separatamente il record di www.

Il CNAME viene frequentemente utilizzato anche per collegare sottodomini a servizi esterni:

shop    CNAME    servizio-ecommerce.example

In questo modo shop.esempio.it può mostrare un’applicazione ospitata su una piattaforma differente.

Di norma, un nome configurato come CNAME non dovrebbe contenere contemporaneamente altri record incompatibili. Inoltre, il dominio principale non può sempre utilizzare un CNAME tradizionale, perché la zona deve contenere anche record come SOA e NS.

Alcuni provider propongono record chiamati ALIAS, ANAME o funzioni di CNAME flattening. Non si tratta sempre di record DNS standardizzati con lo stesso comportamento: sono soluzioni implementate dal gestore per consentire al dominio principale di seguire una destinazione basata su hostname. Prima di utilizzarle è opportuno consultare la documentazione specifica.

Record MX, TXT, SPF, DKIM e DMARC

Il record MX, abbreviazione di Mail Exchanger, indica quali server devono ricevere la posta elettronica destinata al dominio.

Esempio:

@    MX    10 mail1.provider.example
@    MX    20 mail2.provider.example

Il numero rappresenta la priorità. Un valore numerico più basso indica normalmente il server da contattare per primo. Se il primo server non è disponibile, il mittente può tentare la consegna verso quello successivo.

Il valore di un record MX deve essere un nome host, non direttamente un indirizzo IP. Il nome indicato deve poi essere risolvibile tramite un record A o AAAA.

Un errore negli MX può impedire la ricezione delle e-mail. Tuttavia, la corretta consegna non dipende soltanto da questi record. La reputazione del server, le configurazioni antispam e i sistemi di autenticazione svolgono un ruolo altrettanto importante.

Il record TXT consente di pubblicare informazioni testuali nella zona DNS. Viene utilizzato per numerose finalità, tra cui:

• verifica della proprietà del dominio;
• autenticazione e-mail;
• configurazione di piattaforme esterne;
• politiche di sicurezza;
• associazione del dominio a servizi cloud;
• validazione di certificati o applicazioni.

SPF, DKIM e DMARC utilizzano il DNS per pubblicare informazioni relative alla posta elettronica.

SPF specifica quali server sono autorizzati a inviare e-mail per conto del dominio. Un esempio semplificato può essere:

@    TXT    "v=spf1 include:provider.example -all"

La sintassi effettiva deve essere fornita dal servizio e-mail. È importante evitare la presenza di più record SPF separati sullo stesso dominio. Quando vengono utilizzati diversi fornitori, le rispettive autorizzazioni devono essere normalmente integrate in un’unica politica coerente.

DKIM utilizza una firma crittografica aggiunta ai messaggi in uscita. La chiave pubblica necessaria per verificare la firma viene pubblicata nel DNS attraverso un record associato a un selettore:

selector1._domainkey    TXT    "v=DKIM1; k=rsa; p=..."

Il valore completo viene generato dal provider di posta o dalla piattaforma che invia i messaggi.

DMARC permette al proprietario del dominio di indicare come gestire i messaggi che non superano correttamente i controlli SPF e DKIM. Può inoltre attivare l’invio di report utili a individuare abusi e problemi di configurazione.

Esempio iniziale:

_dmarc    TXT    "v=DMARC1; p=none; rua=mailto:dmarc@esempio.it"

La politica p=none viene spesso utilizzata durante la fase di monitoraggio, perché consente di raccogliere dati senza chiedere ai destinatari di rifiutare i messaggi. Dopo aver verificato tutte le sorgenti autorizzate, è possibile valutare politiche più restrittive, come quarantine o reject.

L’adozione di una politica rigida senza un’analisi preliminare può bloccare anche messaggi legittimi, per esempio quelli inviati da CRM, newsletter, software gestionali o moduli del sito. La configurazione deve quindi essere progressiva e verificata.

Record NS, SOA, PTR, CAA e SRV

Il record NS specifica quali nameserver sono autorevoli per una zona o per una sua delega. Nella zona principale vengono normalmente configurati dal provider DNS.

Il record SOA, cioè Start of Authority, contiene alcune informazioni amministrative della zona, tra cui:

• nameserver principale;
• riferimento del responsabile;
• numero seriale;
• intervalli utilizzati per aggiornamenti e tentativi;
• parametri relativi alla cache negativa.

Il numero seriale permette ai server secondari di riconoscere la presenza di una nuova versione della zona. Nei pannelli gestiti, il SOA viene aggiornato automaticamente e non richiede interventi manuali.

Il record PTR realizza la risoluzione inversa: associa un indirizzo IP a un nome. Non viene normalmente configurato nella zona del dominio, perché la gestione dipende dal soggetto che controlla l’indirizzo IP.

Il reverse DNS è particolarmente rilevante per i server di posta. Se un’azienda utilizza un server e-mail dedicato, deve richiedere al provider dell’indirizzo IP di configurare un PTR coerente con il nome host del server.

Il record CAA consente di indicare quali autorità di certificazione sono autorizzate a emettere certificati TLS per il dominio. Non sostituisce gli altri controlli di validazione, ma aggiunge una politica pubblicata nel DNS.

Esempio:

@    CAA    0 issue "ca.example"

Il record SRV descrive la posizione di un servizio associato a un protocollo e può includere priorità, peso, porta e destinazione. Lo standard è definito dalla RFC 2782. (IETF)

Un SRV può essere utilizzato da sistemi di comunicazione, servizi aziendali, applicazioni collaborative e strumenti che devono individuare automaticamente un endpoint.

La struttura generale è:

_servizio._protocollo    SRV    priorità peso porta destinazione

Poiché la sintassi varia in base all’applicazione, questi record devono essere copiati esattamente dalle istruzioni del fornitore.

Non tutti i record devono essere presenti in ogni zona. Un sito vetrina con posta inclusa potrebbe richiedere una configurazione relativamente semplice, mentre un’organizzazione con diversi servizi cloud potrebbe avere una zona molto più articolata.

Il principio da seguire è mantenere una configurazione documentata, essenziale e coerente, evitando duplicazioni e record obsoleti.

Come impostare nameserver e DNS senza interrompere sito e posta

La configurazione di nameserver e DNS deve essere pianificata prima di qualsiasi modifica. Intervenire direttamente sul pannello senza conoscere la configurazione esistente aumenta il rischio di interruzioni.

Il primo passaggio consiste nel distinguere l’operazione che si deve effettuare. Le situazioni più comuni sono:

• attivazione di un nuovo dominio;
• collegamento del dominio a un hosting;
• migrazione del sito;
• cambio del provider DNS;
• trasferimento del dominio;
• attivazione di un nuovo servizio e-mail;
• collegamento di un sottodominio;
• configurazione di una piattaforma esterna;
• introduzione di un sistema CDN o di sicurezza.

Ogni situazione richiede interventi differenti. Se bisogna soltanto collegare un nuovo sottodominio a una piattaforma, non è necessario sostituire tutti i nameserver. Se invece si desidera spostare l’intera gestione DNS, bisogna preparare una nuova zona completa.

Procedura per cambiare nameserver in sicurezza

Prima di modificare i nameserver è opportuno esportare o annotare tutti i record presenti nella zona attuale.

Il controllo dovrebbe includere:

• nome o host del record;
• tipologia;
• valore o destinazione;
• priorità;
• TTL;
• eventuale stato proxy;
• note sulla funzione;
• servizio che ha richiesto il record.

La nuova zona deve essere creata prima di modificare la delega. In questo modo, quando le richieste inizieranno a raggiungere i nuovi nameserver, questi saranno già in grado di fornire risposte corrette.

Una procedura ordinata può seguire questi passaggi:

1. Inventario dei servizi attivi. Bisogna identificare sito, posta, sottodomini, newsletter, CRM, strumenti di analisi, piattaforme cloud e verifiche.
2. Esportazione della zona. Quando il provider lo consente, è preferibile ottenere un file completo; in alternativa, si possono registrare manualmente i valori.
3. Creazione della nuova zona. Tutti i record necessari devono essere inseriti nel nuovo sistema.
4. Controllo preventivo. È necessario verificare valori, priorità, sintassi, punti finali e duplicazioni.
5. Riduzione anticipata del TTL. Quando possibile, il TTL dei record che cambieranno può essere ridotto prima della migrazione.
6. Modifica della delega. I nuovi nameserver vengono inseriti presso il registrar.
7. Verifica da reti differenti. Le risposte devono essere controllate utilizzando resolver e connessioni diverse.
8. Monitoraggio dei servizi. Sito, posta, certificati, moduli e sottodomini devono essere testati.
9. Mantenimento temporaneo della vecchia zona. Il precedente servizio non dovrebbe essere disattivato immediatamente.
10. Ripristino di TTL adeguati. Dopo la stabilizzazione, i valori temporaneamente ridotti possono essere aumentati.

È consigliabile non eseguire modifiche importanti in prossimità di campagne pubblicitarie, lanci, scadenze, eventi o periodi nei quali il sito e la posta risultano particolarmente critici.

Il vecchio provider DNS dovrebbe rimanere operativo durante il periodo di transizione. Alcuni resolver potrebbero infatti continuare a utilizzare temporaneamente le informazioni precedenti memorizzate nella cache.

TTL e propagazione DNS: che cosa significano realmente

Il TTL, cioè Time to Live, indica per quanto tempo una risposta DNS può essere conservata nella cache prima di dover essere richiesta nuovamente.

Un TTL di 3600 secondi corrisponde a un’ora. Se un resolver ha memorizzato un record con questo valore, potrebbe continuare a utilizzare la risposta precedente fino alla scadenza.

La RFC 2181 chiarisce che il TTL rappresenta un tempo massimo di permanenza nella cache, non un obbligo assoluto di conservarvi il dato per l’intera durata. (IETF Datatracker)

L’espressione “propagazione DNS” viene spesso utilizzata per descrivere il periodo durante il quale utenti diversi possono ricevere risposte differenti dopo una modifica. Non esiste però un singolo processo che copia simultaneamente il record su tutti i server del mondo.

Quello che accade è principalmente questo:

• i nameserver autorevoli iniziano a fornire il nuovo valore;
• alcune cache non possiedono il record e ricevono subito la nuova risposta;
• altre cache conservano ancora il valore precedente fino alla scadenza;
• le modifiche ai nameserver possono coinvolgere anche la cache delle deleghe;
• browser, sistemi operativi e reti locali possono conservare ulteriori dati.

Per questo motivo, una modifica può apparire immediata da un dispositivo e non ancora visibile da un altro.

Un TTL basso rende più rapida la sostituzione delle risposte memorizzate, ma aumenta la frequenza delle interrogazioni ai server autorevoli. Un TTL alto riduce il numero di richieste e favorisce la stabilità della cache, ma rallenta l’adozione di future modifiche.

La RFC 9199 osserva che TTL più bassi facilitano transizioni rapide; quando un cambiamento è pianificato con anticipo, è possibile ridurre il TTL prima dell’intervento e aumentarlo nuovamente dopo la migrazione. (IETF Datatracker)

Una strategia pratica consiste nel:

• mantenere valori normali durante l’operatività;
• ridurre il TTL almeno un intervallo completo prima della migrazione;
• eseguire la modifica;
• monitorare la nuova destinazione;
• ripristinare un TTL più stabile dopo il completamento.

Ridurre il TTL pochi minuti prima della modifica può essere poco utile, perché i resolver che hanno già memorizzato il record continueranno a rispettare il precedente valore.

Il tempo necessario per un cambio di nameserver può essere più lungo rispetto all’aggiornamento di un singolo record, poiché entrano in gioco la delega presso il dominio di livello superiore e i record NS conservati nelle cache.

Come collegare dominio, sito e posta elettronica

Per collegare un dominio a un nuovo hosting è necessario ottenere dal provider almeno uno dei seguenti elementi:

• indirizzo IPv4;
• indirizzo IPv6;
• hostname di destinazione;
• nameserver da utilizzare;
• istruzioni specifiche per il dominio principale e www.

Se il provider richiede la sostituzione dei nameserver, la zona DNS verrà normalmente gestita dal suo pannello. Se invece fornisce un indirizzo IP, è possibile mantenere i nameserver attuali e aggiornare il record A.

Una configurazione frequente prevede:

@      A        IP-DEL-SERVER
www    CNAME    dominio-principale.it

Se il sito utilizza una piattaforma gestita, potrebbe essere richiesto un CNAME verso un hostname esterno. Le istruzioni fornite dalla piattaforma devono essere seguite esattamente, perché alcune soluzioni richiedono anche record TXT per verificare il dominio.

La posta elettronica deve essere trattata separatamente. Spostare il sito non significa necessariamente spostare le caselle e-mail.

Prima di modificare il DNS bisogna sapere:

• quale servizio riceve i messaggi;
• quali record MX sono attivi;
• quali server inviano posta;
• quali record SPF, DKIM e DMARC sono necessari;
• se il sito invia e-mail tramite SMTP;
• se sono presenti newsletter o software gestionali;
• se esistono servizi di autodiscover;
• se alcuni sottodomini sono utilizzati dalla posta.

Un sito può essere pubblicato correttamente mentre la posta rimane sul vecchio provider. È sufficiente mantenere i record e-mail esistenti e modificare soltanto quelli relativi al web.

Quando si trasferiscono anche le caselle, bisogna coordinare la migrazione dei messaggi, la creazione degli account, le credenziali, i client di posta e la modifica dei record. Il nuovo servizio dovrebbe essere pronto prima di aggiornare gli MX.

I moduli di contatto meritano una verifica specifica. Anche se il sito è raggiungibile, le e-mail generate da WordPress o da un’altra applicazione potrebbero essere rifiutate se il server non è autorizzato dai record SPF oppure se il mittente utilizzato non è coerente con il dominio.

Per progetti che richiedono sviluppo, hosting e configurazione coordinata, può essere utile integrare questi aspetti all’interno di un servizio di realizzazione di siti web professionali, evitando che dominio, infrastruttura e applicazione vengano gestiti come elementi completamente separati.

Sicurezza, prestazioni ed errori da evitare nella gestione DNS

Una configurazione DNS corretta non riguarda soltanto la raggiungibilità del sito. Influisce anche sulla continuità operativa, sulla sicurezza, sull’affidabilità della posta e sulla capacità di reagire rapidamente a guasti o migrazioni.

La qualità di un servizio DNS dipende da diversi fattori:

• distribuzione geografica dei server;
• ridondanza;
• capacità di resistere a picchi e attacchi;
• velocità delle risposte;
• disponibilità del pannello;
• presenza di registri delle modifiche;
• controllo degli accessi;
• assistenza tecnica;
• supporto a DNSSEC;
• possibilità di esportare la zona.

Non è corretto valutare un provider soltanto sulla base del tempo medio dichiarato per una query. Anche continuità, sicurezza e facilità di gestione sono determinanti.

DNSSEC, protezione degli account e continuità operativa

Il DNS tradizionale non è stato originariamente progettato per verificare crittograficamente l’autenticità dei dati ricevuti. DNSSEC, cioè Domain Name System Security Extensions, introduce firme digitali che consentono ai resolver compatibili di controllare che i dati della zona siano autentici e non siano stati alterati.

ICANN spiega che DNSSEC rafforza l’autenticazione dei dati DNS attraverso firme digitali basate sulla crittografia a chiave pubblica. Non cifra le richieste o le risposte: firma i dati pubblicati dal proprietario della zona, permettendone la validazione.

DNSSEC crea una catena di fiducia tra la zona radice, il dominio di primo livello e il dominio interessato. Per attivarlo occorre normalmente:

1. abilitare la firma presso il gestore DNS;
2. ottenere i parametri DS;
3. pubblicare il record DS tramite il registrar;
4. verificare che la catena sia valida.

Una configurazione DNSSEC incompleta può rendere il dominio non risolvibile per i resolver che eseguono la validazione. Il caso più rischioso si verifica quando il record DS rimane pubblicato presso il registro, ma la nuova zona non viene più firmata con le chiavi corrispondenti.

Prima di cambiare nameserver su un dominio protetto da DNSSEC è quindi necessario seguire la procedura indicata dai provider. In alcuni casi bisogna coordinare le chiavi; in altri può essere opportuno disabilitare correttamente la vecchia catena e riattivarla dopo il trasferimento.

DNSSEC non protegge l’account del registrar. Se un soggetto non autorizzato ottiene accesso al pannello e modifica nameserver o record, può deviare sito e posta. Per questo motivo la sicurezza operativa deve includere:

• autenticazione a più fattori;
• password uniche e robuste;
• account nominativi;
• limitazione dei privilegi;
• registrazione delle modifiche;
• blocco del trasferimento del dominio;
• e-mail amministrative protette;
• procedure di recupero documentate;
• controllo periodico delle scadenze.

Il dominio è un’infrastruttura critica. La sua perdita o compromissione può influire contemporaneamente sul sito, sulle e-mail, sui servizi cloud e sull’identità digitale dell’organizzazione.

È opportuno evitare che tutte le credenziali siano conosciute da una sola persona senza procedure di continuità. Allo stesso tempo, non bisogna condividere indiscriminatamente l’account principale con collaboratori e fornitori.

Una gestione professionale dovrebbe stabilire:

• chi è il titolare del dominio;
• chi possiede l’accesso amministrativo;
• chi può modificare il DNS;
• chi autorizza le variazioni;
• dove sono documentati i record;
• come vengono conservati i codici di recupero;
• quali fornitori sono coinvolti;
• come intervenire in caso di indisponibilità.

Influenza dei DNS sulle prestazioni del sito

La risoluzione DNS rappresenta una delle fasi iniziali del caricamento di un sito. Prima di connettersi al server, il browser deve ottenere l’indirizzo corretto.

Un servizio autorevole lento o instabile può quindi aumentare il tempo necessario per iniziare la connessione. La cache limita l’impatto per le visite successive, ma non elimina l’importanza di una risposta affidabile.

Le prestazioni dipendono anche dalla posizione dei server e dalla presenza di una rete distribuita. Molti provider utilizzano tecniche che consentono a più nodi di rispondere allo stesso indirizzo, indirizzando le richieste verso un punto disponibile e vicino dal punto di vista della rete.

Tuttavia, cambiare DNS non rende automaticamente veloce un sito lento. Le prestazioni complessive dipendono principalmente da:

• qualità dell’hosting;
• tempi di elaborazione;
• ottimizzazione delle immagini;
• cache delle pagine;
• codice del tema;
• plugin installati;
• database;
• CDN;
• quantità di richieste;
• struttura delle pagine.

Il DNS incide soprattutto sulla fase iniziale di individuazione del server. Un provider affidabile può ridurre ritardi e rischi di indisponibilità, ma non sostituisce l’ottimizzazione tecnica del sito.

Anche il TTL influisce sul comportamento. Valori troppo bassi aumentano il numero di interrogazioni, mentre valori molto alti rallentano le variazioni. Non esiste un valore universale adatto a ogni record.

Un dominio stabile, che cambia raramente indirizzo, può utilizzare TTL più elevati. Un’infrastruttura soggetta a bilanciamento o failover può richiedere valori più bassi. La scelta deve essere coerente con il servizio, con la frequenza delle modifiche e con le capacità del provider.

Errori frequenti e controlli dopo una modifica

Uno degli errori più comuni consiste nel cambiare nameserver senza copiare la zona. Il nuovo sistema diventa autorevole, ma non possiede tutte le istruzioni necessarie.

Altri errori ricorrenti sono:

• eliminare gli MX durante una migrazione del sito;
• creare più record SPF separati;
• inserire un indirizzo IP come destinazione di un MX;
• utilizzare un CNAME insieme a record incompatibili;
• dimenticare i sottodomini;
• pubblicare un record AAAA non funzionante;
• lasciare verifiche obsolete;
• modificare DNSSEC senza coordinare il record DS;
• abbassare il TTL soltanto dopo la modifica;
• disattivare troppo presto la vecchia zona;
• confondere il trasferimento del dominio con quello dell’hosting;
• utilizzare record copiati da documentazione non aggiornata;
• non documentare le modifiche;
• non verificare l’invio e la ricezione delle e-mail.

Dopo un intervento è necessario controllare più livelli. Visualizzare la homepage non è sufficiente.

La verifica dovrebbe comprendere:

1. dominio principale con e senza www;
2. pagine interne;
3. certificato HTTPS;
4. eventuali reindirizzamenti;
5. sottodomini;
6. ricezione delle e-mail;
7. invio verso provider differenti;
8. moduli di contatto;
9. autenticazione SPF, DKIM e DMARC;
10. pannelli e applicazioni esterne;
11. risoluzione IPv4 e IPv6;
12. validazione DNSSEC;
13. risposte da resolver differenti.

È utile controllare anche eventuali errori SERVFAIL, NXDOMAIN, timeout o risposte non autorevoli.

NXDOMAIN indica normalmente che il nome richiesto non esiste. SERVFAIL segnala invece che il resolver non è riuscito a completare correttamente l’interrogazione. Le cause possono includere problemi dei nameserver, errori DNSSEC, deleghe incoerenti o malfunzionamenti temporanei.

Durante una migrazione, risultati differenti non indicano necessariamente un errore. Possono essere dovuti alle cache. È però importante confrontare il valore ottenuto con quello atteso e verificare quali nameserver hanno risposto.

Anche la scadenza del dominio deve essere monitorata. Una zona DNS perfetta non serve se il dominio non viene rinnovato. È consigliabile attivare il rinnovo automatico, mantenere aggiornati i dati di pagamento e utilizzare un indirizzo amministrativo controllato.

La documentazione interna dovrebbe contenere almeno:

• registrar;
• data di scadenza;
• nameserver;
• gestore della zona;
• hosting;
• servizio e-mail;
• elenco dei record;
• motivazione dei record speciali;
• contatti dei fornitori;
• data delle ultime modifiche.

Questa documentazione accelera gli interventi e riduce il rischio di eliminare configurazioni necessarie.

Affidare la configurazione di nameserver e DNS a Doctor Web Agency

La gestione di nameserver e DNS può sembrare semplice quando si limita all’inserimento di un indirizzo IP. Diventa però più delicata quando il dominio collega contemporaneamente sito, posta, sottodomini, newsletter, CRM, CDN e servizi cloud.

In questi casi, ogni modifica deve considerare l’intera architettura. Un record rimosso per errore può interrompere una funzione non immediatamente visibile. Una migrazione non pianificata può generare perdita di messaggi, problemi di autenticazione oppure periodi di indisponibilità.

Prima di intervenire è quindi opportuno rispondere ad alcune domande:

• Dove è registrato il dominio?
• Quale servizio gestisce la zona DNS?
• Dove si trova il sito?
• Chi gestisce la posta elettronica?
• Esistono sottodomini o applicazioni esterne?
• DNSSEC è attivo?
• Quali record devono essere mantenuti?
• È disponibile una copia della configurazione?
• Chi può accedere ai pannelli?
• Esiste una procedura di ripristino?

La risposta permette di costruire una mappa tecnica del progetto. Senza questa ricognizione, il rischio è modificare un elemento senza conoscere le dipendenze.

Un intervento professionale non dovrebbe limitarsi alla sostituzione di due nameserver. Dovrebbe comprendere inventario, backup della zona, preparazione della nuova configurazione, pianificazione del TTL, verifica dei record e-mail, test e monitoraggio.

È inoltre importante stabilire chiaramente le responsabilità tra registrar, hosting, provider DNS, servizio e-mail e sviluppatore. Quando un problema coinvolge più aziende, ogni fornitore potrebbe vedere soltanto una parte dell’infrastruttura.

Un referente tecnico unico può facilitare la diagnosi, coordinare gli interventi e comunicare con i diversi provider. Questo approccio è particolarmente utile per piccole e medie imprese che non dispongono di un reparto informatico interno.

Prima di consegnare o modificare un progetto, è consigliabile verificare che il dominio sia intestato correttamente al cliente. L’agenzia o il professionista può gestirlo tecnicamente, ma la titolarità dovrebbe essere chiara e documentata.

Anche gli accessi devono essere consegnati in modo sicuro. Le password non dovrebbero essere inviate in chiaro attraverso canali non protetti e gli account condivisi dovrebbero essere sostituiti, quando possibile, da utenti nominativi con permessi specifici.

La configurazione DNS non richiede modifiche frequenti, ma ogni cambiamento può avere un impatto elevato. Per questo motivo è preferibile applicare il principio del minimo intervento: modificare soltanto ciò che serve, mantenere una copia della situazione precedente e verificare il risultato.

Quando un progetto cresce, la zona DNS può diventare un vero inventario dei servizi digitali utilizzati dall’azienda. Record e sottodomini mostrano collegamenti con piattaforme commerciali, strumenti di comunicazione, sistemi di verifica e infrastrutture cloud. Una gestione ordinata contribuisce quindi anche alla governance digitale dell’organizzazione.

La manutenzione dovrebbe prevedere controlli periodici per individuare:

• record non più utilizzati;
• sottodomini abbandonati;
• servizi esterni dismessi;
• politiche e-mail incomplete;
• accessi di vecchi fornitori;
• contatti amministrativi non aggiornati;
• domini vicini alla scadenza;
• configurazioni DNSSEC non valide.

Rimuovere record obsoleti riduce la complessità, ma bisogna farlo solo dopo aver verificato che non siano ancora richiesti. In caso di dubbio, è preferibile documentarli e svolgere un controllo con i responsabili dei servizi coinvolti.

Un dominio stabile e correttamente configurato non produce benefici immediatamente visibili come una nuova grafica, ma sostiene silenziosamente quasi tutte le attività online. Quando il DNS funziona, gli utenti raggiungono il sito, le e-mail vengono consegnate e le applicazioni comunicano senza che nessuno debba pensarci. Quando non funziona, invece, l’intera presenza digitale può risultare compromessa.

Checklist finale per una configurazione affidabile

Prima di considerare concluso l’intervento, è utile eseguire una checklist finale:

• dominio attivo e correttamente intestato;
• rinnovo automatico verificato;
• nameserver coerenti con il gestore scelto;
• almeno due server autorevoli;
• dominio principale risolto correttamente;
• variante www funzionante;
• HTTPS valido;
• sottodomini verificati;
• MX corretti;
• SPF unico e coerente;
• DKIM funzionante;
• DMARC monitorato;
• record TXT necessari presenti;
• DNSSEC valido, quando utilizzato;
• accessi protetti con autenticazione a più fattori;
• zona DNS esportata o documentata;
• referenti e fornitori identificati;
• test eseguiti da più reti;
• vecchia configurazione mantenuta durante la transizione;
• monitoraggio completato.

La checklist non elimina ogni possibile imprevisto, ma riduce sensibilmente il rischio di dimenticare elementi importanti.

L’obiettivo non è rendere il DNS inutilmente complesso. Al contrario, una buona configurazione deve essere comprensibile, essenziale e facilmente verificabile. Ogni record dovrebbe avere una funzione nota e ogni accesso dovrebbe essere assegnato in modo consapevole.

Configurare nameserver e DNS con il supporto di Doctor Web Agency

Noi di Doctor Web Agency aiutiamo aziende e professionisti a gestire domini, hosting, posta elettronica e configurazioni DNS in modo ordinato e sicuro. Analizziamo l’infrastruttura esistente, individuiamo record e servizi collegati e pianifichiamo migrazioni limitando interruzioni e problemi di consegna. Verifichiamo nameserver, record web, sottodomini, MX, SPF, DKIM, DMARC, certificati e impostazioni necessarie alle piattaforme esterne. Affianchiamo inoltre il cliente nella scelta dell’hosting e nella gestione tecnica successiva alla pubblicazione. Per richiedere una valutazione della configurazione o ricevere assistenza durante una migrazione, puoi contattami e descrivere il progetto, i servizi utilizzati e le criticità riscontrate.

Tabella riassuntiva di nameserver e record DNS

FAQ – Domande frequenti