Introduzione

Il DNS è l'elenco che traduce un nome in qualcosa di usabile. relicsoftware.it diventa un indirizzo IP. La posta di quel dominio diventa "questi sono i server che accettano email". Un testo a caso diventa una prova per SPF o una verifica del registrar.

Non è magia. Non "si propaga nel mondo in 48 ore" come un incantesimo. È un albero di server e una cache. Se sbagli un record, una parte di internet vede ancora il valore vecchio. Un'altra vede già il nuovo. Tu, dal PC, vedi quello che ha in cache il resolver del tuo ISP.

Questa guida copre i record che tocchi davvero quando sposti un sito, un server di posta o un pannello:

cosa fa il DNS, in pratica
TTL
A e AAAA
CNAME (e perché sull'apex a volte non si può)
MX
TXT: SPF, DKIM, DMARC in breve
NS
come controllare con nslookup e dig
errori che fanno sparire il sito o la posta

Ti serve il pannello DNS del dominio (registrar o DNS ospitato: Cloudflare, Route 53, il pannello del hosting). Se il sito sta su una macchina tua, tieni accanto Self-hosting: i record puntano a un IP che deve essere raggiungibile.

Stai spostando sito o posta e non vuoi un giorno di DNS sbagliato? Contattaci

Cosa fa il DNS, senza teatro

Tu digiti un nome. Il browser chiede a un resolver (spesso quello del router, che chiede a quello del provider). Il resolver non "conosce" tutti i siti. Parte dalla radice, scende ai server del TLD (.it, .com), arriva ai nameserver autoritativi del tuo dominio. Quelli hanno i record che hai scritto tu.

Risposta tipica: "questo nome è questo IP, e puoi ricordartelo per N secondi" (TTL).

Tre ruoli, tre posti diversi. Confonderli è il primo errore.

Ruolo	Chi è	Cosa sbaglia la gente
Registrar	Chi ti ha venduto il dominio	Si cambia NS qui, non i record A
DNS autoritativo	Dove stai i record	A, MX, TXT vivono qui
Hosting / VPS	Dove gira il sito	L'IP va nel record A, non "nel dominio"

Puoi comprare il dominio da A, usare i DNS di B, e ospitare il sito su C. È normale. Devi sapere dove stai modificando.

Cambiare l'A nel pannello sbagliato non fa motivo. Se i NS del registrar puntano altrove, quel pannello è un museo. I resolver interrogano i NS dichiarati, non "il sito del registrar".

TTL: quanto dura la bugia

TTL (time to live) è quanti secondi un resolver può tenere la risposta. 3600 = un'ora. 300 = cinque minuti. 86400 = un giorno.

Non è un timer globale. Ogni resolver ha ricevuto la risposta in un momento diverso. Se il TTL è 86400 e cambi l'A, qualcuno può vedere il vecchio IP per ore. Qualcun altro, che non aveva cache, vede subito il nuovo.

Prima di un cutover (sposti il sito, cambi mail):

Abbassa il TTL in anticipo, almeno quanto era il TTL vecchio. Se era 86400, abbassa e aspetta un giorno
Fai il cambio
Verifica
Rimetti un TTL ragionevole (3600 è un default onesto per un sito piccolo)

Abbassare il TTL nel momento in cui cambi l'IP non serve. I resolver che hanno già la risposta vecchia la tengono fino a scadenza. Il lavoro si fa prima.

TTL bassissimi (60 secondi) su un dominio fermo aumentano solo le query. Non rendono il sito "più veloce".

Record A e AAAA

A: nome → IPv4. 203.0.113.10

AAAA: nome → IPv6. 2001:db8::10

relicsoftware.it.     3600  IN  A      203.0.113.10
www.relicsoftware.it. 3600  IN  A      203.0.113.10
relicsoftware.it.     3600  IN  AAAA   2001:db8::10

L'apex (il dominio nudo, senza www) è un A o un AAAA. O entrambi.

Due record A sullo stesso nome sono un round-robin. I resolver pescano ora l'uno ora l'altro. Serve se hai due server che servono lo stesso sito. Non serve se hai copiato l'A del hosting vecchio e quello nuovo "per sicurezza". In quel caso metà dei visitatori va sul cadavere.

Regole A / AAAA

Un nome, un IP: un solo A (e un solo AAAA, se usi IPv6)
Due A solo se entrambi gli IP devono rispondere allo stesso servizio
Se non hai IPv6 sul server, non inventare un AAAA
Se hai AAAA e il firewall è solo IPv4, una parte dei client va in timeout

www può essere un altro A verso lo stesso IP, o un CNAME verso l'apex. Le due cose non si mischiano sullo stesso nome: CNAME è esclusivo. Lo vediamo sotto.

CNAME: un alias, non un "A più comodo"

CNAME dice: "questo nome è un alias di quest'altro nome". Il resolver riparte e chiede l'A (o altro) del target.

www.relicsoftware.it.  3600  IN  CNAME  relicsoftware.it.
shop.relicsoftware.it. 3600  IN  CNAME  shops.example-cdn.net.

Utile per CDN, pages, un servizio che ti dà un hostname e non un IP fisso. L'IP lo cambia loro. Tu punti al nome.

Perché a volte non va sull'apex

Lo standard: un CNAME non può convivere con altri record sullo stesso nome. L'apex ha già, di solito, NS e SOA. Spesso ha MX. Quindi CNAME sull'apex rompe o è vietato dal pannello.

Molti provider offrono un "CNAME flattening" o un record ALIAS/ANAME. Non è un CNAME vero. È il loro server che risolve il target e risponde con un A. Va bene se il provider lo documenta. Non è portabile copiando la riga in un BIND qualunque.

Se il pannello rifiuta un CNAME su relicsoftware.it e accetta www, non è un bug. È il DNS. Punta l'apex con A/AAAA (o ALIAS del provider). Lascia il CNAME su www o su shop.

Non fare CNAME di un nome che deve avere MX. La posta guarda MX su quel nome. Un CNAME lì è conflitto. Vedi errori comuni.

MX: dove arriva la posta

MX non è un IP. È un hostname di un mail server, con una priorità. Numero più basso = più preferito.

relicsoftware.it.  3600  IN  MX  10  mx1.example-mail.net.
relicsoftware.it.  3600  IN  MX  20  mx2.example-mail.net.

Il server mx1.example-mail.net deve avere un A (o AAAA). Non mettere un IP nel campo MX. Non mettere un CNAME come destinazione MX se puoi evitarlo: alcuni sistemi fanno i capricci. Il fornitore di posta ti dà i valori esatti. Si copiano. Non si "interpretano".

Se sposti la posta da un hosting "tutto incluso" a Google, Microsoft 365 o un mail server tuo:

Tieni gli MX vecchi finché non hai creato gli utenti nuovi
Imposta SPF/DKIM/DMARC prima o insieme, non tre settimane dopo
Cambia gli MX
Togli gli MX vecchi. Due set di MX verso sistemi diversi = posta spezzata a metà

Lasciare l'MX del vecchio hosting "tanto il sito l'ho già spostato" è come lasciare la cassetta delle lettere nel palazzo vecchio. Qualcuno continua a consegnare lì.

TXT: SPF, DKIM, DMARC (il minimo)

TXT è un pezzo di testo legato a un nome. Serve per verifiche ("dimostra che il dominio è tuo") e per la posta.

SPF

Dice quali host possono inviare posta per quel dominio. Una policy. Non è crittografia.

relicsoftware.it.  3600  IN  TXT  "v=spf1 include:_spf.google.com -all"

Un solo SPF per nome. Due record SPF = fallimento. Se hai due servizi che spediscono (sito + newsletter + 365), si fondono in un unico v=spf1 .... Non si affiancano.

-all = chi non è in lista è rifiutato. ~all = soft fail. +all = accetta il mondo. Non usare +all.

DKIM

Una firma. Il mittente firma le mail. Il ricevente chiede un TXT (di solito selettore._domainkey.tuodominio) e verifica. Il valore te lo dà il servizio di posta. Lo copi. Non lo inventi.

Se cambi piattaforma, il DKIM vecchio non firma più. Ne pubblichi uno nuovo. Il vecchio si toglie quando non spedisci più da lì.

DMARC

Una policy su cosa fare se SPF o DKIM falliscono, e dove mandare i report.

_dmarc.relicsoftware.it.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none osserva. quarantine e reject arrivano dopo, quando i report dicono che non stai rompendo la posta legittima. Partire da reject il primo giorno è un modo per perdere mail.

Ordine sensato per la posta

MX verso il sistema giusto
Un solo SPF, con tutti gli include che servono
DKIM acceso sul pannello del mail e TXT pubblicato
DMARC a none, poi si alza

Altri TXT comuni: verifica Google Search Console, verifica del registrar, chiavi per servizi. Stesso nome, più TXT, di solito è lecito. SPF è l'eccezione che non va duplicata.

NS: chi è autorità sul dominio

I record NS dicono quali server rispondono in modo autoritativo.

relicsoftware.it.  86400  IN  NS  ns1.example-dns.net.
relicsoftware.it.  86400  IN  NS  ns2.example-dns.net.

Li cambi dal registrar (delegazione). I NS "dentro" la zona devono coincidere. Se al registrar lasci i NS del vecchio hosting e nel nuovo pannello crei record perfetti, internet ignora il pannello nuovo.

Cambio sito (stesso DNS)

NS invariati
Cambi A/AAAA (e CNAME se c'è CDN)
TTL abbassato prima
MX solo se sposti anche la posta

Cambio DNS (altro provider)

Copi tutti i record, non solo l'A
Verifichi MX, TXT, DKIM
Poi cambi NS al registrar
Aspetti la cache dei NS (TTL spesso alto)

Il cutover del sito è un cambio di A. Il cutover del DNS è un cambio di NS. Sono due lavori. Farli insieme, di corsa, è come cambiare serratura e indirizzo lo stesso pomeriggio senza avvisare il postino.

Il mito della "propagazione"

Non esiste un'onda che gira il pianeta in 24–48 ore. Esiste:

cache dei resolver (TTL)
cache del tuo PC / browser
a volte cache del resolver del cellulare diversa da quella dell'ufficio
ritardo sul cambio NS (i TLD hanno TTL propri, spesso ore)

Per questo "da me si vede, dal cliente no". Non è che "non si è propagato in Germania". È che il resolver del cliente ha ancora il vecchio A.

Cosa fare invece di aspettare e pregare:

Interroga i nameserver autoritativi, non solo 8.8.8.8
Interroga un resolver pubblico
Confronta

Se l'autoritativo ha già il valore nuovo e Google DNS ha il vecchio, è cache. Aspetti il TTL. Se l'autoritativo ha ancora il vecchio, non hai scritto dove credevi, o stai guardando la zona sbagliata.

whatsmydns e siti simili sono un indizio, non una sentenza. Mostrano resolver sparsi. Per lavorare usi dig verso i NS del dominio.

Controllare: nslookup e dig

dig è più chiaro. Su Ubuntu/Debian: sudo apt install dnsutils. Su Windows, nslookup c'è già. In Windows 10/11 puoi anche installare dig (pacchetto BIND o client Linux in WSL).

Chi è autorità

dig NS relicsoftware.it +short

nslookup -type=NS relicsoftware.it

Record A, esplicitando il server

Sostituisci ns1.example-dns.net con uno dei NS trovati sopra:

dig A relicsoftware.it @ns1.example-dns.net +norecurse

nslookup relicsoftware.it ns1.example-dns.net

Se qui l'IP è sbagliato, il problema è la zona. Non la "propagazione".

Cosa vede un resolver pubblico

dig A relicsoftware.it @8.8.8.8
dig A relicsoftware.it @1.1.1.1

Guarda anche TTL nella risposta. Se è 847 su un record impostato a 3600, quella cache scade tra 847 secondi. Non tra due giorni.

MX e TXT

dig MX relicsoftware.it +short
dig TXT relicsoftware.it +short
dig TXT _dmarc.relicsoftware.it +short

nslookup -type=MX relicsoftware.it
nslookup -type=TXT relicsoftware.it

CNAME

dig CNAME www.relicsoftware.it +short
dig A www.relicsoftware.it +short

Il secondo comando segue la catena e ti dà l'IP finale. Utile per vedere se l'alias punta dove credi.

Autoritativo = valore nuovo. Resolver pubblico = valore vecchio, TTL in calo. Non toccare altro. Aspetta. Se l'autoritativo è sbagliato, il pannello o i NS sono sbagliati. Si lavora lì.

Errori comuni

Due A per sbaglio

Hai aggiunto il nuovo IP e non hai cancellato il vecchio. Metà degli utenti va sul server spento. Sintomo: "a volte il sito c'è, a volte no". Non è il hosting instabile. È round-robin involontario.

dig A tuodominio.it +short

Due righe? Una di troppo, se hai un solo server.

CNAME insieme a MX (o ad A)

Stesso nome, CNAME più qualsiasi altra cosa. Pannelli seri lo bloccano. Quelli meno seri accettano e i resolver si comportano a caso. Posta che non arriva, o sito che non risolve.

www in CNAME va bene. Apex con MX: A/AAAA (o ALIAS), non CNAME.

Host vecchio lasciato lì

FTP, mail., webmail., un A verso un IP di un hosting chiuso tre anni fa. Non rompe sempre il sito. Rompe quando un client o un software "intelligente" usa mail.tuodominio.it invece dell'MX. O quando un certificato Let's Encrypt tenta tutti i nomi della zona.

Dopo un trasferimento, elenca:

dig A tuodominio.it +short
dig A www.tuodominio.it +short
dig MX tuodominio.it +short
dig TXT tuodominio.it +short

Poi, dal pannello, ogni riga che non sai spiegare. O la documenterai, o la togli.

SPF doppio

Due TXT che iniziano con v=spf1. I ricevitori non "li uniscono". Falliscono. Unisci gli include in una riga. Attenzione al limite di lookup SPF (10). Troppi include annidati rompono comunque.

TTL e cambio NS insieme

Cambi i NS e i record nello stesso quarto d'ora, con TTL a 86400. Per un giorno hai una mescolanza. Copia prima la zona, verifica, poi delega.

IPv6 orfano

AAAA verso un IP che non ascolta sulla 80/443. I client dual-stack preferiscono IPv6. Il sito "non apre" da alcune reti. Da altre sì (solo IPv4). Stesso genere di trappola che in SSH si vede con -4. Togli l'AAAA o sistema il server.

Checklist prima di un cutover

TTL abbassato in tempo
Lista dei record attuali salvata (screenshot o export)
A/AAAA nuovi verificati sul server (il servizio ascolta)
MX e TXT allineati se la posta si muove
Nessun A vecchio rimasto
Dopo il cambio: dig sugli NS autoritativi

Se ospiti tu il servizio, il DNS è la metà. L'altra è firewall, certificato, reverse proxy. Self-hosting è il pezzo macchina. Questo articolo è il pezzo nomi. Se invece il sito lo costruiamo noi, il pezzo dominio e record sta in siti web.

Conclusione

I record non sono rituali. A e AAAA dicono dove sta il servizio. CNAME è un alias, e sull'apex spesso non ci sta. MX è la cassetta della posta. TXT è dove la posta dimostra di essere legittima, e dove i servizi ti verificano. NS decide chi ha ragione.

La "propagazione" è cache. Si misura interrogando l'autoritativo e un resolver, guardando il TTL rimasto. Gli incidenti più frequenti sono due A, un CNAME dove non va, MX o SPF del tenant vecchio, un AAAA dimenticato.

Scrivi i record, controlla con dig, solo allora chiudi il pannello.

Devi spostare dominio, sito o posta e vuoi i record allineati al primo colpo? Parliamone

Risorse utili (autorevoli):

Cloudflare Learning: che cos'è il DNS — modello, resolver, zona, in linguaggio accessibile
Cloudflare Learning: tipi di record DNS — A, AAAA, CNAME, MX, TXT, NS
IANA: Root Servers — la radice del DNS, dal registro ufficiale
RFC 1035 — specifiche originali (tecnico, per chi vuole la fonte)
RFC 1912 — errori operativi classici, ancora attuali