Guida ai record DNS: quelli che contano e quelli che causano disservizi

La maggior parte dei disservizi segnalati con "il sito è irraggiungibile" ha origine nel DNS. Il server è integro, il codice del sito è perfetto, ma un record testuale punta all'indirizzo errato — oppure è rimasto memorizzato nella cache dei resolver puntando al vecchio server.

Il DNS è inoltre il livello meno visibile di un'infrastruttura web. Nessuno se ne cura finché non si verifica un blocco, e a quel punto la modifica incriminata è stata spesso apportata settimane prima da qualcuno che non fa più parte dell'azienda.

Ecco cosa fa ciascuna tipologia di record DNS e dove si concentrano gli errori più gravi.

A e AAAA — dove risiede il sito web

Il record A mappa un nome host su un indirizzo IPv4. Il record AAAA lo mappa su un indirizzo IPv6.

example.com.      A      203.0.113.10
example.com.      AAAA   2001:db8::1
www.example.com.  A      203.0.113.10

Se questi record sono errati o assenti, nessun altro elemento descritto in questa pagina potrà funzionare.

L'errore tipico: pubblicare un record A per example.com ma dimenticare www.example.com, o viceversa. Metà dei visitatori digita l'indirizzo con la variante mancante e riceve un errore di connessione. Chi gestisce il sito non se ne accorge mai perché digita sempre l'URL allo stesso modo.

A proposito di IPv6: in diversi mercati un'ampia quota del traffico mobile è esclusivamente IPv6 e contatta i siti solo-IPv4 tramite sistemi di traduzione degli operatori (NAT64), che aggiungono latenza a ogni richiesta. Se il vostro fornitore di hosting supporta IPv6, aggiungere i record AAAA è gratuito ed elimina questo passaggio superfluo.

MX — dove viene recapitata la posta elettronica

example.com.  MX  10 mx1.provider.com.
example.com.  MX  20 mx2.provider.com.

Elenca i server autorizzati a ricevere le email per il vostro dominio. Il numero di priorità più basso ha la precedenza assoluta; i numeri più alti fungono da server di riserva (fallback).

Due concetti che generano frequente confusione:

Il record MX governa unicamente la posta in entrata. Se i vostri messaggi in uscita finiscono nello spam dei destinatari, il record MX non c'entra: il problema risiede in SPF, DKIM e DMARC, che risiedono nei record TXT.

Un record MX deve tassativamente puntare a un nome host, mai a un indirizzo IP numerico diretto. La sintassi MX 10 203.0.113.5 non è valida e molti mail server rifiuteranno a priori i messaggi inviati a un dominio configurato in questo modo.

NS — chi detiene l'autorità sul dominio

example.com.  NS  ns1.provider.com.
example.com.  NS  ns2.provider.com.

I nameserver autoritativi deputati a rispondere per la vostra zona DNS. Devono coincidere tassativamente con quelli registrati presso il vostro registrar: i record NS presenti nel file di zona e la delega configurata presso il registrar sono due entità distinte, e possono entrare in conflitto.

L'errore classico durante le migrazioni: trasferite l'hosting, aggiornate i record DNS presso il nuovo provider e il sito funziona sul vostro computer ma non per gli utenti esterni. La causa risiede quasi sempre nella delega del registrar, che punta ancora ai vecchi nameserver: metà di Internet continua a interrogare il vecchio fornitore, che risponde con i vecchi indirizzi IP memorizzati.

Mantenete sempre almeno due nameserver distinti. Avere un solo nameserver introduce un unico punto di vulnerabilità per l'intero dominio, posta elettronica inclusa.

TXT — il contenitore universale

Record di testo libero impiegati per una serie crescente di funzioni critiche:

• SPF — quali server possono trasmettere email per vostro conto: v=spf1 include:_spf.google.com ~all
• DMARC — la policy di applicazione e sicurezza, configurata su _dmarc.example.com
• DKIM — la chiave crittografica pubblica, posizionata su selettore._domainkey.example.com
• Verifica del dominio — Google Search Console, Microsoft 365, Atlassian e molti altri servizi

Due regole fondamentali da ricordare:

Un solo record SPF per ciascun dominio. Pubblicare due record TXT distinti che iniziano con v=spf1 costituisce un errore permanente, con la conseguenza che entrambi i record vengono scartati dai server destinatari. Accade tipicamente quando si attiva un nuovo servizio commerciale e il fornitore aggiunge il proprio record anziché integrare quello esistente. Devono essere uniti in un'unica stringa.

I record TXT si accumulano nel tempo. Molti domini storici conservano stringhe di verifica per servizi dismessi anni prima. Pur non essendo dannosi, creano disordine visivo, ed è proprio nel disordine che si annida il secondo record SPF non autorizzato. Conducete una revisione annuale.

CAA — chi è autorizzato a emettere certificati per voi

Il record più trascurato in assoluto in ambito infrastrutturale.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:security@example.com"

Il record CAA stabilisce quali autorità di certificazione (CA) hanno il permesso di emettere certificati SSL/TLS per il vostro dominio. In sua assenza, qualsiasi CA pubblica al mondo può rilasciarne uno. Con il record CAA attivo, solo quelle esplicitamente autorizzate.

Le autorità di certificazione sono obbligate a verificare questo record prima del rilascio. È una reale misura di sicurezza contro l'emissione abusiva o accidentale di certificati, si configura in due minuti e quasi nessuno la applica.

Due dettagli da impostare correttamente: includete ogni singola CA che utilizzate realmente — comprese quelle impiegate automaticamente dalla vostra CDN o dal provider di hosting — e utilizzate issuewild ";" per impedire l'emissione di certificati wildcard se non ne fate uso.

SOA — i metadati della zona DNS

Unico per ciascuna zona, solitamente gestito in automatico dal provider. Il parametro cruciale da conoscere è il numero seriale: si incrementa a ogni modifica della zona. Durante una migrazione, se il seriale non è cambiato, significa che la modifica non è stata propagata. Questo semplice controllo risolve all'istante molti dubbi del tipo "ho già salvato la configurazione".

TTL: la causa delle migrazioni complesse

Ogni record reca un Time To Live (TTL): il numero di secondi per cui i resolver possono conservarlo nella propria cache locale.

Un record con un TTL impostato a 24 ore può richiedere un'intera giornata per aggiornarsi a livello mondiale. Non esiste modo per accelerare la propagazione a posteriori. Una volta che un resolver ha salvato la vecchia risposta, continuerà a fornirla fino alla naturale scadenza del TTL.

La procedura corretta per evitare qualsiasi disservizio:

1. 48 ore prima della migrazione, riducete il TTL dei record interessati a 300 secondi.
2. Attendete che il vecchio TTL scada completamente, affinché tutti i resolver nel mondo acquisiscano il nuovo valore breve.
3. Eseguite il cambio di puntamento. La variazione si propagherà ovunque in soli cinque minuti.
4. Il giorno successivo, reimpostate il TTL a valori standard (3600 secondi o superiori).

Il passaggio 4 è fondamentale: mantenere perennemente un TTL troppo basso aumenta il numero di query DNS e rallenta la prima connessione di ogni nuovo visitatore.

È la procedura DNS più efficace in assoluto e va pianificata per tempo: non può essere applicata retroattivamente quando il blocco è già in corso.

Perché strumenti diversi mostrano risultati discordanti

Perché interrogano resolver differenti, e ciascun resolver conserva in cache una copia aggiornata a un momento diverso, in base al proprio ciclo di TTL.

Subito dopo una modifica questo comportamento è assolutamente fisiologico e si normalizza alla scadenza dei timer di cache. Se la discrepanza persiste oltre il termine del TTL, significa che due sistemi stanno fornendo risposte contrastanti — solitamente due insiemi di nameserver rimasti attivi in parallelo dopo una migrazione incompiuta.

Potete verificare tutti i record DNS del vostro dominio e i relativi TTL tramite il nostro strumento gratuito di verifica DNS. Le query vengono eseguite direttamente dal vostro browser, mostrando la configurazione rilevata dal resolver a voi più vicino.

Checklist operativa per la migrazione

1. Esportate il file di zona completo attuale prima di modificare qualsiasi parametro.
2. Riducete i TTL a 300 secondi con 48 ore di anticipo.
3. Configurate l'intera zona presso il nuovo fornitore prima di modificare la delega dei nameserver.
4. Aggiornate i nameserver presso il registrar.
5. Verificate che i record A, AAAA, MX, TXT e CAA rispondano correttamente dal nuovo provider.
6. Effettuate test di invio e ricezione email in entrambe le direzioni.
7. Mantenete attiva la vecchia zona DNS per almeno una settimana: i resolver con record NS ancora in cache continueranno a interrogarla.
8. Riportate i TTL ai valori ottimali una volta stabilizzato il traffico.

Il passaggio 7 è quello che viene ignorato più spesso, ed è la causa per cui una migrazione sembra perfetta il primo giorno e inizia a perdere email il terzo giorno.

Apri strumento Ricerca DNS Tutti i record DNS di un dominio, interrogati in tempo reale dal vostro browser. →