Record DNS: cosa sono e quali tipi esistono

Quando un dominio “non va”, il problema spesso non è il server web ma il DNS: il livello che traduce un nome come www.example.com in un indirizzo IP o in un altro record utile al servizio. I record DNS non fanno tutti la stessa cosa: alcuni puntano a un host, altri definiscono la posta, altri ancora servono per delegare zone, verificare identità, gestire alias o pubblicare parametri tecnici. Se li confondi, finisci con siti irraggiungibili, mail respinte o validazioni fallite.

In pratica, il DNS è una base dati distribuita con regole precise. Ogni record ha un tipo, un nome, un valore e un TTL. Il tipo dice che informazione stai pubblicando; il nome dice per quale etichetta vale; il valore contiene il dato vero e proprio; il TTL indica per quanto tempo i resolver possono tenerlo in cache. Il punto operativo è semplice: se cambi un record, non sempre il risultato è immediato, perché la cache dei resolver può trattenere il vecchio valore fino alla scadenza del TTL.

La classificazione utile: record di indirizzamento, delega e servizio

Il modo più pulito per capire i record DNS è dividerli per funzione. Questa divisione è più utile del semplice elenco alfabetico, perché ti aiuta a diagnosticare i problemi.

Se ragioni per funzione, eviti un errore classico: tentare di usare un record per un compito che non gli appartiene. Ad esempio, un CNAME non è un indirizzo IP, e una zona DNS non si gestisce con un solo record “magico” ma con un insieme coerente di dati.

A e AAAA: il punto di ingresso per IPv4 e IPv6

A associa un nome a un indirizzo IPv4. AAAA fa la stessa cosa per IPv6. Sono i record più semplici, ma anche quelli che più spesso finiscono al centro di incidenti banali: IP sbagliato, record duplicato, propagazione non attesa, o aggiornamento fatto solo su una parte dei name server autorevoli.

Esempio operativo: se il tuo sito deve rispondere su 203.0.113.10 e 2001:db8::10, pubblicherai un A e un AAAA sul nome del servizio. Molti stack moderni preferiscono IPv6 quando disponibile, quindi un AAAA rotto può causare sintomi strani anche se l’IPv4 funziona. È una delle prime cose da verificare quando “da alcune reti il sito va, da altre no”.

Verifica rapida da terminale:

dig A www.example.com +short
 dig AAAA www.example.com +short

Se il risultato non è quello atteso, il problema può essere nel record, nella cache del resolver o nella delega della zona. Per distinguere i casi, conviene interrogare i name server autorevoli direttamente.

dig @ns1.example-dns.net www.example.com A +short
 dig @ns1.example-dns.net www.example.com AAAA +short

Se il valore è corretto sugli autorevoli ma non sui resolver pubblici, sei davanti a un tema di cache o propagazione percepita. Se invece è già sbagliato sugli autorevoli, il fix è nella zona DNS, non altrove.

CNAME: alias, comodità e vincoli reali

CNAME dice che un nome è un alias di un altro nome. Non punta a un IP, punta a un altro record risolvibile. È molto utile per distribuire servizi, per esempio quando vuoi far sì che www.example.com segua un target gestito dal provider CDN o da una piattaforma esterna.

Il vincolo da ricordare è che un nome con CNAME non dovrebbe avere altri record dello stesso livello: niente A, niente MX, niente TXT sullo stesso owner name, se vuoi restare nel comportamento standard e prevedibile. In pratica, un nome alias deve essere trattato come un alias e basta.

Errore tipico: usare CNAME sul dominio apex, cioè il root della zona, come example.com. Nella pratica operativa molti provider offrono soluzioni equivalenti come ALIAS, ANAME o flattening lato DNS, perché il DNS classico non consente un CNAME puro sul nome di zona principale senza effetti collaterali. Se il pannello ti propone un “CNAME flattening”, quello è il meccanismo da valutare, non un trucco da inventare manualmente.

MX: la posta non passa dal record sbagliato

I record MX indicano quali server ricevono la posta per un dominio. Non contengono il contenuto della mail, solo la destinazione e una priorità. Il valore con priorità più bassa viene preferito. Se il tuo dominio è example.com, l’MX decide dove i server esterni consegneranno i messaggi indirizzati a utente@example.com.

Qui gli errori hanno un costo immediato: una priorità errata, un target non risolvibile, oppure un MX che punta a un nome senza record A/AAAA funzionanti. Risultato: mail respinte, ritardi o fallback non desiderati. Quando la posta “sparisce”, il primo controllo non è sul server IMAP ma sul DNS della zona.

dig MX example.com +short
 dig A mail.example.com +short
 dig AAAA mail.example.com +short

Buona pratica: il nome usato dall’MX deve essere risolvibile e stabile, e il server mail deve presentare una configurazione coerente con quel nome. Se usi un provider esterno, verifica anche che l’MX sia quello documentato dal servizio e non una vecchia configurazione rimasta in zona dopo una migrazione.

TXT: il record più sottovalutato e più abusato

TXT è un contenitore testuale generico. È nato per annotazioni, ma oggi viene usato per SPF, DKIM, DMARC, verifiche di dominio, challenge ACME e integrazioni varie. Proprio perché è generico, è anche uno dei record più disordinati nelle installazioni reali.

Due problemi ricorrenti: stringhe spezzate male e più record confliggenti. Alcuni provider frammentano automaticamente il testo lungo, altri no; alcuni pannelli mostrano la stringa in modo diverso da come viene pubblicata davvero. Se un validatore ti dice che il record non è corretto, non fidarti del solo screenshot: interroga la zona e guarda l’output reale.

Esempi tipici di uso corretto:

Con SPF e DMARC il punto non è solo “mettere il record”: bisogna controllare la lunghezza, il numero di lookup DNS e la coerenza con il flusso mail reale. Un SPF troppo complesso può superare i limiti di ricerca e fallire anche se la sintassi sembra corretta.

NS e SOA: chi è autorevole e chi governa la zona

I record NS indicano quali server sono autorevoli per una zona. Il record SOA contiene i parametri di base della zona: server primario, contatto amministrativo, seriale e timer di refresh/retry/expire. Sono record che raramente tocchi ogni giorno, ma quando qualcosa nella delega non funziona sono proprio loro a spiegare dove si è rotto il flusso.

Se la delega è incoerente, potresti vedere una zona che risponde in un punto della rete e non in un altro. Per questo, in caso di troubleshooting, conviene verificare sia i NS del dominio sia la catena completa fino agli autoritativi. Un nome può sembrare corretto in un pannello, ma non esserlo nella realtà pubblicata ai resolver globali.

dig NS example.com +short
 dig SOA example.com +short
 dig +trace www.example.com

Il seriale del SOA è importante soprattutto in ambienti con replica o trasferimenti di zona: se non cambia quando modifichi i record, alcuni secondari possono non aggiornarsi come previsto. Non è il problema più comune nei servizi DNS gestiti, ma in ambienti self-hosted resta un classico.

SRV, CAA, PTR e altri record che fanno la differenza

Alcuni record sono meno visibili ma molto utili. SRV specifica host e porta di un servizio, spesso in applicazioni che non si appoggiano solo a A o CNAME. CAA limita quali autorità di certificazione possono emettere certificati per il dominio. PTR è il record di reverse DNS, usato per risolvere un IP verso un nome, molto rilevante in contesti mail e reputazione.

Il reverse DNS non vive nella stessa mentalità del DNS forward: non basta avere un record A per ottenere anche il PTR. In genere il reverse è gestito dal provider dell’IP o dal datacenter. Se il tuo server invia posta e il reverse non è coerente con l’hostname annunciato, alcuni filtri antispam alzano il livello di sospetto.

Il record CAA è spesso trascurato fino al giorno in cui il rinnovo automatico del certificato fallisce. Se hai impostato un CAA restrittivo, il provider ACME o la CA usata deve essere esplicitamente autorizzata. In caso contrario, la richiesta di certificato può essere rifiutata anche se DNS e web server funzionano perfettamente.

TTL: il dettaglio che cambia il comportamento percepito

Il TTL non è decorazione. Decide quanto a lungo un resolver può tenere in cache un record prima di chiedere di nuovo. TTL bassi sono utili durante migrazioni o cambi IP, perché riducono il tempo di persistenza del vecchio dato. TTL troppo bassi, però, aumentano il carico di query verso i resolver autorevoli e possono peggiorare la stabilità percepita.

La strategia corretta dipende dal contesto. In un cambio programmato, abbassi il TTL prima della finestra di intervento, aspetti che la vecchia cache scada, poi fai la modifica. Dopo la migrazione, puoi riportarlo a un valore più equilibrato. Se cambi il record senza preparare la TTL, il vecchio indirizzo può continuare a essere usato da una parte del traffico per un tempo non banale.

Controllo utile:

dig www.example.com A +ttlunits
 dig www.example.com AAAA +ttlunits

Se il TTL residuo è ancora alto, non forzare conclusioni affrettate: potrebbe essere semplicemente la cache del resolver intermedio. Per questo, nei cambi critici, conviene sempre verificare sia sul resolver pubblico sia sugli autorevoli.

Record DNS e problemi reali: come leggerli senza perdere tempo

Quando un servizio non risponde, il DNS è uno dei primi livelli da escludere. Il flusso corretto è semplice: nome giusto, record giusto, delega giusta, target raggiungibile. Se uno di questi passaggi fallisce, il sintomo può essere un timeout, una pagina bianca, un errore di certificato o una mail che non arriva.

In ambienti con pannelli di hosting, il rischio non è solo la sintassi del record ma anche l’errore di contesto: nome record scritto con il dominio completo quando il pannello si aspetta solo l’host, oppure viceversa. È una fonte classica di record duplicati o sbagliati. In caso di dubbio, il dato da fidare è sempre l’output effettivo di interrogazione DNS, non la sola schermata del pannello.

Come scegliere il record giusto senza improvvisare

La regola pratica è questa: se devi pubblicare un indirizzo numerico, usa A o AAAA. Se devi creare un alias verso un altro nome, usa CNAME dove consentito. Se devi definire la posta, usa MX e verifica i target. Se devi dichiarare policy, autenticazione o validazioni, usa TXT con attenzione alla forma esatta richiesta dal servizio. Se devi controllare chi è autorevole o come è delegata la zona, guarda NS e SOA. Se devi limitare l’emissione di certificati, considera CAA. Se lavori con servizi che espongono porta e protocollo, valuta SRV.

La parte più importante non è memorizzare i tipi, ma capire il vincolo. Un record DNS non è un campo libero da riempire a caso: è una dichiarazione con semantica precisa. Se cambi semantica, cambi anche il comportamento di client, resolver, mail server e sistemi di validazione.

Schema mentale rapido per non sbagliare

Se devi decidere in pochi secondi, usa questa sequenza:

Questo schema riduce i fix sbagliati. Per esempio, se un sito non risponde non ha senso inseguire il certificato prima di aver verificato che il nome risolva sull’IP corretto. Al contrario, se la web app funziona ma il client mostra errore di fiducia sul certificato, il DNS va controllato solo in relazione a CAA, validazioni ACME o record di verifica, non come causa primaria del routing.

Conclusione operativa: il DNS va letto come un sistema, non come una lista

I record DNS non sono etichette decorative. Sono istruzioni distribuite che influenzano web, mail, certificati e deleghe. La differenza tra una configurazione pulita e una fragile sta quasi sempre nella coerenza tra record, TTL, delega e target. Se impari a distinguere i tipi per funzione, la diagnosi diventa più veloce e gli errori più facili da isolare.

In produzione, il metodo resta lo stesso: prima osservi con dig e con gli autorevoli, poi correggi il record giusto, poi aspetti la cache, infine verifichi il comportamento del servizio. È un lavoro di precisione, non di tentativi casuali.