Guida alla configurazione dei record DNS
Un riferimento che raccoglie tipi, scopi, esempi di sintassi e avvertenze dei record del sistema dei nomi necessari al recapito della posta e alla gestione di un sito: A, MX, TXT, SPF, DKIM, DMARC e gli altri.
Elenco dei tipi di record DNS
| Tipo | Scopo | Esempio di sintassi | Avvertenze |
|---|---|---|---|
| Record A | È il record più elementare: associa un nome di dominio a un indirizzo IPv4. Indica a quale indirizzo si trovi realmente il servente web o quello di posta. | example.com. 3600 IN A 192.0.2.1 |
Un tempo di vita troppo breve — in questo esempio 3600 secondi, cioè un'ora — moltiplica le interrogazioni al servente autorevole e ne accresce il carico; uno troppo lungo ritarda la propagazione quando si cambia indirizzo IP. |
| Record AAAA | Associa un nome di dominio a un indirizzo IPv6: è esattamente la versione IPv6 del record A. | example.com. 3600 IN AAAA 2001:db8::1 |
Affiancandovi un record A, anche le reti prive di supporto IPv6 possono ripiegare sulla connessione IPv4: è il cosiddetto funzionamento a doppia pila. |
| Record CNAME | Tratta un nome host come alias di un altro nome host canonico. Si usa, per esempio, per far corrispondere www.example.com a example.com. | www.example.com. 3600 IN CNAME example.com. |
Un nome host con un record CNAME non può averne altri, come MX o TXT: è un vincolo della norma RFC 1034. Inoltre alla radice della zona, indicata con la chiocciola, non si può assegnare un CNAME. |
| Record MX | Indica quale servente debba ricevere la posta destinata al dominio. Se ne possono indicare più d'uno, ciascuno con un valore di preferenza. | example.com. 3600 IN MX 10 mail.example.com. |
La priorità è tanto più alta quanto più basso è il valore. Per ridondanza è consueto indicare più serventi con priorità diverse. La destinazione di un record MX deve essere un nome host dotato di record A, non un CNAME. |
| Record TXT | Record di uso generale che associa al dominio un testo qualsiasi. Serve per SPF, DKIM e DMARC, ma anche per la verifica della titolarità del dominio e per molti altri scopi. | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
Un dominio può avere più record TXT, ma se se ne collocano due destinati allo stesso scopo, per esempio SPF, si genera un errore di interpretazione: vanno riuniti in uno solo. |
| Record SPF (una specie di record TXT) | Elenca i serventi, cioè gli indirizzi IP, autorizzati a inviare posta a nome del dominio: è il meccanismo di autenticazione del dominio mittente che previene la contraffazione. Si configura come record TXT. | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
Per ciascun dominio è valido un solo record SPF. Superando il limite di dieci interrogazioni al sistema dei nomi si genera un errore, perciò attenzione al concatenarsi delle deleghe include. Il tipo di record dedicato, il numero 99, è stato abolito nel 2014 e oggi SPF si esprime soltanto con record TXT. |
| Record DKIM (una specie di record TXT) | Meccanismo che appone una firma elettronica ai messaggi per verificare che non siano stati alterati durante il transito e che provengano davvero da un mittente legittimo. La chiave pubblica viene esposta in un record TXT. | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
La prima parte del nome host, cioè il selettore, è una stringa assegnata in modo diverso da ciascun servizio di posta. La chiave privata resta sul servente mittente e nel sistema dei nomi si pubblica soltanto quella pubblica. |
| Record DMARC (una specie di record TXT) | Meccanismo che, sulla base degli esiti di SPF e DKIM, dichiara come politica il trattamento dei messaggi che non superano l'autenticazione — nessun provvedimento, posta indesiderata o rifiuto — e consente di ricevere relazioni sugli esiti. | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
La transizione sicura consiste nel cominciare da p=none, limitandosi al monitoraggio, e nel rafforzare gradualmente la politica verso quarantine e reject dopo aver verificato l'assenza di problemi. |
| Record NS | Indica quali siano i serventi autorevoli del dominio, cioè della zona. È il punto di partenza della risoluzione dei nomi per l'intero dominio. | example.com. 86400 IN NS ns1.example-dns.com. |
Se i serventi dei nomi registrati presso il registrar non coincidono con i record NS interni alla zona, la risoluzione dei nomi diventa instabile: è la cosiddetta delega zoppa. |
| Record SOA | Record obbligatorio, presente una sola volta per zona, che ne conserva le informazioni amministrative: servente primario, indirizzo dell'amministratore, numero di serie, intervalli di ritentativo e altro. | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
Dopo ogni aggiornamento del file di zona occorre incrementare il numero di serie, altrimenti le modifiche non si propagano ai serventi secondari con il trasferimento di zona. |
| Record CAA | Limita le autorità di certificazione abilitate a emettere certificati per il dominio, prevenendo emissioni indebite da parte di autorità non previste. | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
In assenza di qualunque record CAA si considera che ogni autorità possa emettere certificati. Per i certificati con carattere jolly occorre indicare a parte l'etichetta issuewild. |
| Record PTR | Consente la risoluzione inversa, cioè risalire dal nome host a partire dall'indirizzo IP: è il verso opposto del record A. Si configura nelle zone inverse, in-addr.arpa e ip6.arpa. | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
Molti serventi di posta considerano indesiderati, o rifiutano, i messaggi provenienti da mittenti privi di risoluzione inversa o con un PTR non corrispondente al record A: per un servente che invia posta è una configurazione pressoché indispensabile. |
Consigli
- Se avete dubbi sulla configurazione di SPF, DKIM e DMARC, conviene prima analizzare i record attuali con lo strumento di verifica dei record SPF, DKIM e DMARC e poi confrontarli con gli esempi di sintassi di questa pagina.
- Per i record ordinari un tempo di vita di circa un'ora, cioè 3600 secondi, è una scelta prudente; riducendolo a trecento secondi soltanto poco prima di una migrazione, la propagazione dopo il passaggio risulterà più rapida.
- Il valore di un record TXT che superi i 255 caratteri può essere suddiviso automaticamente in più stringhe: dopo un copia e incolla verificate che il numero delle virgolette non sia sballato.
- Per controllare il formato di un indirizzo di posta elettronica in sé, usate anche lo strumento dedicato alla convalida degli indirizzi: eviterete verifiche incomplete.
- Quando adottate un nuovo servizio di recapito della posta, la via sicura è far funzionare DMARC con p=none, esaminare le relazioni per una o due settimane e passare alla politica definitiva solo dopo aver accertato l'assenza di problemi.
Domande frequenti
SPF verifica la legittimità dell'indirizzo IP, cioè da quale servente sia partito il messaggio; DKIM verifica con una firma elettronica che il contenuto non sia stato alterato. Soltanto quando entrambi danno esito positivo l'autenticazione del dominio mittente raggiunge un'efficacia sufficiente.
Non è un obbligo di legge, ma i principali serventi riceventi, come Gmail e Yahoo! Mail, lo impongono di fatto ai grandi mittenti: in sua assenza cresce il rischio che i messaggi siano considerati indesiderati o rifiutati.
Le più probabili sono che la destinazione del record MX sia un CNAME, che il valore di priorità sia stato indicato per errore, oppure che il servente di posta non sia configurato per accettare i messaggi diretti a quel dominio.
Se l'indirizzo IP è fisso e volete configurare la radice del dominio, indicata con la chiocciola, usate un record A o AAAA; se invece volete trattare il nome come alias di un altro nome host, per esempio l'indirizzo di una rete di distribuzione dei contenuti, usate un CNAME.
Nel normale esercizio è consueto attestarsi intorno a un'ora, cioè 3600 secondi. Riducendolo a circa trecento secondi soltanto poco prima di una migrazione del servente o di un cambio di configurazione, la propagazione successiva al passaggio sarà più rapida.
A proposito — storia dei record DNS e dell'autenticazione della posta
Il sistema dei nomi è noto come il meccanismo che lega i nomi di dominio agli indirizzi IP, ma in realtà, oltre ai record A e AAAA, ne sono definiti molti altri tipi, ciascuno con un ruolo diverso. Nel mondo del recapito della posta, in particolare, soltanto la collaborazione di più record — MX, TXT per SPF, DKIM e DMARC, e PTR — permette di riconoscere un messaggio come legittimo e non contraffatto: se anche uno solo manca, cresce il rischio che il messaggio finisca fra quelli indesiderati o venga rifiutato.
Ripercorrendo la storia dell'autenticazione del dominio mittente, SPF fu proposto nella prima metà degli anni Duemila come rimedio ai messaggi indesiderati; intorno al 2007 fu poi standardizzato DKIM, volto a rilevare le alterazioni del contenuto. Nessuno dei due, però, stabiliva che cosa fare in caso di autenticazione fallita, e a colmare quel vuoto arrivò nel 2012 DMARC, che valuta in modo unitario gli esiti di SPF e DKIM e fornisce sia la politica per gli insuccessi sia il meccanismo delle relazioni: una sorta di cabina di regia dell'autenticazione.
Alcuni record hanno visto cambiare le proprie specifiche per ragioni storiche. Il tipo di record dedicato a SPF, il numero 99, fu definito in una norma del 2006, ma generò confusione nelle implementazioni e fu formalmente abolito nel 2014 dalla RFC 7208: oggi lo standard prevede di esprimere SPF soltanto con record TXT. Anche DKIM e DMARC, del resto, non hanno un tipo di record proprio e sono realizzati inserendo in un record TXT una sintassi particolare, riconoscibile dai prefissi v=DKIM1 e v=DMARC1: un'ulteriore testimonianza della duttilità del sistema dei nomi.