Record DNS: A, AAAA, CNAME, MX e TXT spiegati bene

Il DNS e' il livello piu' fragile di qualunque presenza online: un record sbagliato non rompe la connettivita', rompe solo il tuo dominio, e lo fa in modo silenzioso. Vediamo i tipi di record che servono davvero, cosa fanno e dove si sbaglia piu' spesso.

Come si legge un record

Ogni record ha quattro componenti: nome (il sottodominio a cui si applica), TTL (per quanti secondi i resolver possono tenerlo in cache), tipo e valore. Il nome "@" indica il dominio nudo, ad esempio velixconnect.it senza prefissi. Il TTL e' l'unico parametro che governa la velocita' di propagazione: un cambio di IP con TTL a 86400 secondi resta visibile agli utenti fino a 24 ore dopo la modifica.

Regola operativa: prima di una migrazione, abbassa il TTL a 300 secondi almeno 24 ore prima. Dopo che la migrazione e' stabile, rialzalo a 3600 o piu' per ridurre il carico sui resolver.

A e AAAA: dal nome all'indirizzo

Il record A associa un nome a un indirizzo IPv4, il record AAAA a un indirizzo IPv6. Sono gli unici record che restituiscono un indirizzo vero e proprio: tutto il resto e' indirezione.

Punti pratici:

• Puoi avere piu' record A per lo stesso nome: i resolver li restituiscono in ordine variabile, ottenendo un bilanciamento grossolano. Non e' failover: se un IP e' morto, il client ci finisce comunque e aspetta il timeout.
• Se pubblichi un AAAA devi essere certo che il servizio risponda davvero su IPv6. Un AAAA verso un host che non ascolta su IPv6 produce timeout su client dual stack, con pagine lentissime e diagnosi difficile.
• Per i servizi in CDN o in cloud l'indirizzo cambia nel tempo: in quel caso il record giusto non e' A ma CNAME verso il nome fornito dal provider.

CNAME: alias, con vincoli

Il CNAME dice "per questo nome, ricomincia la risoluzione da quest'altro nome". E' comodo perche' segue automaticamente i cambi di IP a monte, ma ha due limiti rigidi:

• Un nome con CNAME non puo' avere altri record. Niente MX, niente TXT sullo stesso nome.
• Sul dominio nudo il CNAME e' vietato dallo standard, perche' li' vivono per forza SOA e NS. Alcuni provider offrono ALIAS o CNAME flattening, che risolvono il nome lato server autoritativo e restituiscono un A: e' una funzione proprietaria, non un CNAME.

Errore classico: mettere un CNAME su www verso il dominio nudo e poi un altro CNAME sul dominio nudo verso il provider. Catena che molti resolver troncano, con risultati incoerenti tra rete e rete.

MX: dove arriva la posta

Il record MX indica quali server accettano la posta per il dominio, con una priorita' numerica: valore piu' basso, preferenza piu' alta. Server con la stessa priorita' vengono usati in round robin.

Cose da sapere:

• Il valore di un MX deve essere un nome, non un indirizzo IP, e quel nome deve risolvere in A o AAAA. Un MX che punta a un IP e' formalmente invalido e molti mittenti lo rifiutano.
• Il valore di un MX non dovrebbe essere un CNAME. Funziona quasi sempre, ma alcuni MTA rigidi lo scartano.
• Se il dominio non deve ricevere posta, non lasciare il campo vuoto: pubblica un MX nullo, cioe' un record con priorita' 0 e valore punto. E' il modo standard per dire che il dominio non accetta email.
• Cambiare hosting web non cambia la posta, ma se sposti i nameserver perdi tutta la zona: ricopia gli MX prima del cambio, non dopo.

TXT: tutto il resto

Il record TXT contiene testo libero ed e' diventato il contenitore per le policy antispoofing e per le verifiche di proprieta' del dominio.

Gli usi principali:

• SPF, un unico record TXT sul dominio nudo che elenca chi puo' spedire a nome del dominio. Deve essere uno solo: due record SPF sullo stesso nome invalidano la valutazione. Attenzione anche al limite di dieci lookup DNS generati dai meccanismi include.
• DKIM, pubblicato su un selettore nella forma selettore._domainkey, con la chiave pubblica usata per verificare la firma dei messaggi.
• DMARC, su _dmarc, con la policy da applicare quando SPF e DKIM falliscono. Si parte sempre da p=none con gli indirizzi di report, si legge cosa arriva per qualche settimana, poi si passa a quarantine e infine a reject.
• Verifiche di proprieta' per servizi cloud e strumenti di analytics: si possono tenere piu' record TXT sullo stesso nome senza problemi, tranne appunto per SPF.

Gli errori che vediamo piu' spesso

• TTL alto lasciato invariato durante una migrazione, con utenti divisi tra vecchio e nuovo server per un giorno intero.
• Zona duplicata su due provider DNS diversi: i nameserver del registrar puntano a uno, l'utente modifica l'altro, e i cambi non compaiono mai.
• AAAA dimenticato dopo la dismissione di un servizio IPv6.
• SPF che elenca ancora il vecchio provider di posta dopo la migrazione, con recapito che finisce in spam.

Un controllo veloce prima di ogni intervento: interroga direttamente i nameserver autoritativi del dominio, non il resolver locale, cosi' vedi lo stato reale della zona senza cache di mezzo.