A cura del team tecnico di VAY · Aggiornata il
In breve
- Il cambio di provider DNS non tocca sito e caselle email: cambia solo chi risponde alle domande sul dominio.
- La causa più comune di disservizio è un record dimenticato nella copia, quasi sempre MX, SPF, DKIM o un sottodominio poco usato.
- Abbassare il TTL dei record qualche giorno prima riduce i tempi di propagazione e rende possibile tornare indietro in fretta.
- Con DNSSEC attivo il record DS va rimosso o aggiornato prima del cambio dei nameserver.
- Dopo il cambio si verifica tutto dall'esterno: record, posta in ingresso, autenticazione delle email e certificati.
Cosa cambia davvero quando si cambia provider DNS
Il provider DNS è il servizio che pubblica la zona DNS del dominio: l'elenco dei record che dicono dove si trova il sito (A, AAAA, CNAME), chi riceve la posta (MX) e quali servizi sono autorizzati a inviarla a nome dell'azienda (TXT con SPF, DKIM e DMARC).
Il provider DNS può essere diverso dal registrar, che è dove il dominio è registrato e rinnovato, e diverso dall'hosting del sito o dal fornitore della posta. Molte aziende li hanno tutti presso lo stesso fornitore e scoprono la differenza proprio quando devono cambiarne uno.
Cambiare provider DNS significa due cose: ricreare la zona presso il nuovo provider e indicare al registro i nuovi nameserver tramite il registrar. Finché il secondo passaggio non è fatto, il nuovo provider non riceve nessuna richiesta.
Prima del cambio: fai l'inventario completo dei record
Il punto delicato non è il cambio dei nameserver, ma la copia della zona. Esporta la zona dal vecchio provider se lo permette (file di zona in formato BIND); altrimenti annota a mano ogni record, compresi quelli dei sottodomini.
Confronta poi l'inventario con quello che risponde davvero su Internet, con la verifica dei record DNS: un record presente nel pannello ma non pubblicato, o il contrario, emerge subito.
| Record | Esempio | Perché non va dimenticato |
|---|---|---|
| A / AAAA | www → indirizzo del server web | Senza questi record il sito non si raggiunge. Controlla anche il dominio senza www. |
| CNAME | autodiscover, servizi cloud, CDN | Servizi di posta, CRM e piattaforme esterne spesso usano CNAME su sottodomini dimenticati. |
| MX | server di posta in ingresso, con priorità | Se manca o è sbagliato, la posta in arrivo si ferma o torna al mittente. |
| TXT SPF | v=spf1 include:spf.protection.outlook.com -all (esempio con Microsoft 365) | Elenca chi può inviare email per il dominio: senza, la posta aziendale finisce in spam. |
| TXT / CNAME DKIM | selettore._domainkey | Le chiavi di firma della posta: ce n'è una per ogni piattaforma che invia email. |
| TXT DMARC | _dmarc | La policy contro la falsificazione del dominio e l'indirizzo dei report. |
| TXT di verifica | google-site-verification=<codice di Google>, MS=ms<codice di Microsoft> | Servono a Microsoft 365, Google e altri servizi per riconoscere il dominio. |
| SRV / CAA | _sip._tls, issue "letsencrypt.org" | Telefonia, Teams e i certificati: un CAA mancante o sbagliato blocca i rinnovi SSL. |
A / AAAA
- Esempio
- www → indirizzo del server web
- Perché non va dimenticato
- Senza questi record il sito non si raggiunge. Controlla anche il dominio senza www.
CNAME
- Esempio
- autodiscover, servizi cloud, CDN
- Perché non va dimenticato
- Servizi di posta, CRM e piattaforme esterne spesso usano CNAME su sottodomini dimenticati.
MX
- Esempio
- server di posta in ingresso, con priorità
- Perché non va dimenticato
- Se manca o è sbagliato, la posta in arrivo si ferma o torna al mittente.
TXT SPF
- Esempio
- v=spf1 include:spf.protection.outlook.com -all (esempio con Microsoft 365)
- Perché non va dimenticato
- Elenca chi può inviare email per il dominio: senza, la posta aziendale finisce in spam.
TXT / CNAME DKIM
- Esempio
- selettore._domainkey
- Perché non va dimenticato
- Le chiavi di firma della posta: ce n'è una per ogni piattaforma che invia email.
TXT DMARC
- Esempio
- _dmarc
- Perché non va dimenticato
- La policy contro la falsificazione del dominio e l'indirizzo dei report.
TXT di verifica
- Esempio
- google-site-verification=<codice di Google>, MS=ms<codice di Microsoft>
- Perché non va dimenticato
- Servono a Microsoft 365, Google e altri servizi per riconoscere il dominio.
SRV / CAA
- Esempio
- _sip._tls, issue "letsencrypt.org"
- Perché non va dimenticato
- Telefonia, Teams e i certificati: un CAA mancante o sbagliato blocca i rinnovi SSL.
Annota anche i record che "non servono più": spesso servono ancora a qualcuno. Un record tolto per errore si nota dopo settimane, quando un servizio smette di funzionare.
Come cambiare provider DNS passo per passo
- 1
Qualche giorno prima abbassa il TTL dei record principali (A, MX, CNAME) sul vecchio provider, ad esempio a 300 secondi. Aspetta che passi il vecchio TTL perché la modifica abbia effetto.
- 2
Ricrea la zona sul nuovo provider con tutti i record dell'inventario, gli stessi valori e le stesse priorità MX.
- 3
Interroga direttamente i nuovi nameserver prima di usarli: devono rispondere con gli stessi valori dei vecchi. Il controllo si fa record per record, senza fidarsi del pannello.
- 4
Gestisci DNSSEC, se è attivo: rimuovi il record DS presso il registrar e attendi che il suo TTL scada, oppure segui la procedura di passaggio delle chiavi concordata tra i due provider.
- 5
Aggiorna i nameserver presso il registrar. Per i domini .it il Registro esegue un controllo tecnico dei nuovi nameserver: se la zona non è configurata correttamente, il cambio viene rifiutato.
- 6
Lascia attiva la vecchia zona finché il cambio non è propagato ovunque: per qualche tempo alcuni resolver continueranno a interrogare i vecchi nameserver.
- 7
Verifica tutto dall'esterno e, quando è stabile, riattiva DNSSEC sul nuovo provider e riporta i TTL a valori normali.
Come si gestisce DNSSEC durante il cambio
Con DNSSEC attivo, il registro pubblica un record DS che dice ai resolver quale chiave firma la zona. Il nuovo provider firma con chiavi diverse: se il DS resta quello vecchio, i resolver che validano DNSSEC considerano false le risposte e il dominio smette di funzionare per una parte degli utenti, posta compresa.
La strada più semplice è disattivare DNSSEC in modo ordinato prima del cambio e riattivarlo dopo. Lo stato attuale si controlla con la verifica DNSSEC, prima e dopo ogni passaggio.
Rimuovi il record DS prima di cambiare i nameserver, non dopo. È l'errore più grave in una migrazione DNS, perché il problema non si vede da tutte le reti e si scambia per un guasto del provider.
Quanto tempo serve perché il cambio sia effettivo
Non esiste un tempo fisso. I resolver di tutto il mondo conservano le risposte per il tempo indicato dal TTL: finché non scade, alcuni utenti vedono ancora i vecchi valori. Per questo i TTL bassi preparati nei giorni precedenti accorciano la transizione.
Anche il riferimento ai nameserver ha un suo TTL, deciso dal registro e non modificabile dal cliente: in quel periodo vecchi e nuovi nameserver ricevono richieste insieme. Se le due zone sono identiche, nessuno se ne accorge.
Cosa verificare dopo la migrazione
- Tutti i record dell'inventario rispondono dai nuovi nameserver, con la verifica dei record DNS.
- La posta arriva da un indirizzo esterno, e quella inviata non finisce in spam: verifica SPF, DKIM e DMARC.
- Il WHOIS mostra i nuovi nameserver presso il registro: whois del dominio.
- Il certificato del sito si rinnova regolarmente: se il rinnovo usa la validazione via DNS, va riconfigurato sul nuovo provider. Controlla con la verifica del certificato SSL.
- DNSSEC, se riattivato, risulta valido sul nuovo provider.
Cosa vediamo più spesso nelle aziende
Le migrazioni DNS falliscono quasi sempre per un record dimenticato, non per un problema tecnico del provider. I casi tipici sono il record SPF copiato senza un servizio che invia email (gestionale, newsletter, fatturazione), le chiavi DKIM di una piattaforma usata da un solo reparto e i sottodomini creati anni prima per un fornitore.
L'altro caso frequente è il dominio gestito dall'account di un ex fornitore o di un collaboratore che non c'è più: prima di pianificare il cambio conviene verificare chi ha davvero accesso al pannello del registrar.
Gli strumenti da usare
Domande frequenti
Cambiare provider DNS interrompe la posta aziendale?
+
No, se la zona sul nuovo provider contiene gli stessi record MX, SPF, DKIM e DMARC del vecchio. La posta si ferma solo quando un record viene dimenticato o copiato con un valore diverso.
Devo cambiare anche registrar per cambiare provider DNS?
+
No. Il registrar e il provider DNS possono essere diversi: dal registrar si cambiano solo i nameserver del dominio, la zona resta presso il provider DNS che hai scelto.
Quanto tempo devo tenere attiva la vecchia zona DNS?
+
Almeno qualche giorno dopo il cambio dei nameserver, finché tutti i resolver non hanno aggiornato i dati. Tenerla attiva non costa nulla e protegge da disservizi durante la transizione.
Cosa succede se dimentico il record DS di DNSSEC?
+
I resolver che validano DNSSEC rifiutano le risposte firmate con le nuove chiavi e il dominio diventa irraggiungibile per una parte degli utenti. Si risolve aggiornando o rimuovendo il DS presso il registrar, ma serve attendere la scadenza della cache.
Posso fare la migrazione in orario di lavoro?
+
Sì, se la zona è stata preparata e verificata prima: il cambio dei nameserver è trasparente. Conviene comunque evitare i giorni in cui il personale tecnico non è disponibile a verificare il risultato.
Il cambio di provider DNS influisce sul posizionamento del sito su Google?
+
No, se il sito resta raggiungibile allo stesso indirizzo. Contano solo eventuali interruzioni: con una zona completa e TTL ridotti la migrazione non ha effetti sul posizionamento.
Fonti
Preferisci che se ne occupi qualcuno?
I tecnici VAY gestiscono dominio, posta, server e sicurezza delle aziende clienti, con un unico referente.
Parla con un tecnico