Modulo 8 · 8.4
Errori comuni
Modulo 8: Sicurezza e risoluzione dei problemi · Tempo di lettura: 10 minuti
Obiettivo della lezione: dopo questa lezione riconoscerà i dieci errori DNS più comuni dai loro sintomi e saprà come risolverli.
Concetti chiave: punto finale, dominio duplicato, modifica nel posto sbagliato, due record SPF, CNAME sul dominio principale, AAAA dimenticato, MX senza indirizzo, proxy per la posta, vecchio DS dopo un trasferimento, cache
Come usare questa lezione
Gli errori qui sotto non provengono da un manuale, ma dalle domande che i provider di hosting ricevono ogni settimana. Per ogni errore vedrà: cosa nota l'utente, come dimostrarlo con una sola domanda e qual è la soluzione. Davanti a un problema inizi sempre con le stesse due domande: quali nameserver ha il dominio (dig +short NS example.com) e cosa restituisce il nameserver autoritativo (dig @<nameserver> <nome> <type>). Con questo risolve già metà dei casi.
1. Dimenticare il punto finale
Sintomo: un CNAME, MX o NS non funziona; un servizio dice "record non trovato".
Dimostrazione: dig +short CNAME shop.example.com restituisce shops.platform.example.example.com.
Causa: in una zona un nome senza punto finale è relativo: il pannello aggiunge il proprio dominio alla fine (lezione 2.2).
Soluzione: scriva il nome di destinazione come nome completo con punto (shops.platform.example.). Alcuni pannelli aggiungono il punto automaticamente; dopo il salvataggio verifichi cosa è stato effettivamente impostato.
2. Il nome di dominio duplicato nel nome
Sintomo: una verifica o un controllo DKIM presso un servizio non riesce, mentre il record "è presente".
Dimostrazione: dig +short TXT k2._domainkey.example.com non restituisce nulla, ma dig +short TXT k2._domainkey.example.com.example.com sì.
Causa: il servizio indica il nome completo (k2._domainkey.example.com) e il pannello aggiunge di nuovo il dominio alla fine.
Soluzione: nel campo nome inserisca solo la parte che precede il proprio dominio: k2._domainkey. Il pannello di solito mostra sotto il campo il nome completo: lo controlli.
3. Modificare nel posto sbagliato
Sintomo: modifica un record, ma non cambia nulla, nemmeno dopo un giorno.
Dimostrazione: dig +short NS example.com restituisce nameserver di un soggetto diverso da quello dove ha effettuato la modifica (ad esempio un costruttore di siti web o Cloudflare).
Causa: solo il soggetto dei nameserver determina il DNS (lezione 2.1). I record impostati altrove non hanno alcun effetto.
Soluzione: modifichi il record presso il soggetto dei nameserver, oppure ripristini i nameserver originali. Un esempio reale: qualcuno aveva impostato i nameserver verso una piattaforma di costruzione siti per il proprio sito web, ma il record A per mail non era presente lì. Risultato: l'invio funzionava, la ricezione no, perché l'MX puntava a mail.example.com e quel nome non esisteva più.
4. Due record SPF
Sintomo: la posta finisce più spesso nello spam o viene rifiutata, da quando ha collegato un nuovo servizio.
Dimostrazione: dig +short TXT example.com restituisce due righe che iniziano con v=spf1.
Causa: il nuovo servizio ha indicato "aggiunga questo record SPF", ed è stato fatto alla lettera. Con due record SPF, SPF non è valido (permerror, RFC 7208), il che è peggio che non avere affatto SPF.
Soluzione: li unisca in un unico record: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Faccia attenzione al limite di dieci ricerche (lezione 4.3).
5. Un CNAME sul dominio principale
Sintomo: il pannello rifiuta il record, oppure dopo il salvataggio la Sua posta smette di funzionare.
Dimostrazione: il servizio chiede di "creare un CNAME per @".
Causa: un CNAME non può coesistere con altri record, e sul dominio principale (apex) sono sempre presenti i record SOA e NS (e spesso MX e TXT). Vedi lezione 3.2.
Soluzione: su @ utilizzi il record A (ed eventualmente AAAA) indicato dal servizio, e il CNAME solo per www o un sottodominio. Alcuni fornitori DNS dispongono di un ALIAS o "CNAME flattening" per questo caso.
6. L'AAAA dimenticato durante un trasferimento
Sintomo: dopo un trasferimento, parte dei visitatori (spesso da mobile) vede ancora il vecchio sito, oppure si verifica un errore di certificato.
Dimostrazione: dig +short A example.com restituisce il nuovo indirizzo, dig +short AAAA example.com restituisce ancora un indirizzo del vecchio server.
Causa: i dispositivi con IPv6 preferiscono l'AAAA. È stato aggiornato solo l'A.
Soluzione: aggiorni anche l'AAAA, oppure lo rimuova se il nuovo server non ha IPv6. Un esempio reale: nel collegare una piattaforma di e-commerce, oltre al nuovo record A andava rimosso anche il vecchio AAAA, altrimenti il negozio restava irraggiungibile per una parte dei visitatori.
7. Un MX che non punta a nulla
Sintomo: non riceve posta; i mittenti ricevono un messaggio di errore.
Dimostrazione: dig +short MX example.com restituisce 10 mail.example.com., ma dig +short A mail.example.com non restituisce nulla (NXDOMAIN).
Causa: un MX punta a un nome, e quel nome deve avere un record A o AAAA. Spesso il record A per mail è scomparso durante un trasferimento di nameserver. Un MX non può nemmeno puntare a un indirizzo IP o a un CNAME (RFC 2181).
Soluzione: crei un record A per il nome del server di posta, oppure faccia puntare l'MX a un nome che ha effettivamente un indirizzo.
8. Posta altrove, ma il vecchio server crede di dover consegnare la posta
Sintomo: la posta proveniente dall'esterno arriva correttamente al nuovo provider, ma la posta dal Suo stesso sito web (modulo di contatto, negozio online) non arriva mai. A volte riceve 550 Unknown user.
Dimostrazione: l'MX punta al nuovo provider, ma sul server web la consegna locale della posta è ancora attiva.
Causa: non si tratta di un errore DNS, ma ne ha tutto l'aspetto. Un server web convinto di gestire lui stesso le caselle di posta non consulta l'MX.
Soluzione: disattivi nel pannello del Suo hosting la consegna locale (in DirectAdmin: la casella "Utilizzi questo server per gestire le mie e-mail"). Altri pannelli hanno un'impostazione simile, spesso chiamata "Remote mail exchanger" o "e-mail esterna".
9. Proxy attivo per la posta
Sintomo: presso un fornitore DNS con funzione proxy (come la nuvola arancione di Cloudflare), il sito web funziona, ma il Suo programma di posta non riesce a connettersi, oppure il certificato del sito non viene rinnovato.
Dimostrazione: dig +short A mail.example.com restituisce un indirizzo del proxy invece del Suo server di posta.
Causa: un proxy web inoltra solo il traffico web, non la posta.
Soluzione: disattivi il proxy (nuvola grigia, "DNS only") per mail e tutti i nomi utilizzati dal Suo programma di posta. Per i certificati: disattivi temporaneamente il proxy finché il certificato non è stato emesso, oppure utilizzi la modalità SSL corretta per il proxy.
10. Vecchio DS dopo un trasferimento
Sintomo: dopo un trasferimento di nameserver, il Suo dominio è irraggiungibile per una parte del mondo; altre persone non riscontrano alcun problema.
Dimostrazione: dig example.com @1.1.1.1 restituisce SERVFAIL, dig +cd example.com @1.1.1.1 restituisce invece una risposta. DNSViz (https://dnsviz.net/, lezione 8.1) colora il DS di rosso e disegna sotto una chiave grigia, tratteggiata, che non è più presente nella Sua zona. Zonemaster e il Verisign DNSSEC Debugger segnalano lo stesso problema a parole.
Causa: presso il registro è ancora presente il DS del vecchio soggetto (lezione 8.1). Solo i resolver che validano falliscono, perciò non tutti se ne accorgono.
Soluzione: faccia aggiornare il DS con la chiave del nuovo soggetto, oppure lo rimuova e riattivi DNSSEC in seguito.
E l'"errore" che non è un errore: la cache
Molto spesso tutto è corretto, ma Lei vede ancora la vecchia risposta. Lo riconosce così: dig @<nameserver> restituisce la nuova risposta, anche uno strumento di verifica online da altri paesi, solo il Suo computer no. Soluzione: finestra privata, telefono tramite 4G/5G, oppure svuoti la cache (lezione 8.2). Anche una riga dimenticata nel file hosts del Suo computer (da un test precedente prima di un trasferimento) produce questo effetto: rimuova quella riga.
Una trappola collegata: richiedere un nome nuovo prima ancora di averlo creato. Il resolver memorizza allora "non esiste" (cache negativa) e ci vuole più tempo prima che il nuovo nome funzioni (lezione 6.2).
Nella pratica: ecco come appare in un pannello
Molti pannelli prevengono parte di questi errori. Mio WebOké, ad esempio, avvisa se manca il punto finale e mostra sotto il campo nome il nome completo; DirectAdmin rifiuta i record non validi con "Error Writing Records". Cloudflare e altri fornitori hanno avvisi simili. Prima di modifiche importanti, faccia sempre un backup o un'esportazione della Sua zona, così potrà sempre tornare indietro.
Riepilogo
- Inizi sempre con: quali nameserver, e cosa dice il nameserver autoritativo.
- La maggior parte degli errori riguarda il nome (punto, dominio duplicato) o il posto (soggetto sbagliato).
- Un solo record SPF, nessun CNAME su @, trasferire anche l'AAAA, MX verso un nome con indirizzo.
- SERVFAIL dopo un trasferimento è quasi sempre un vecchio DS.
- Se solo Lei vede la vecchia risposta, si tratta della Sua cache o del file hosts.
Quiz
Esercizio
Esercizio Z8.4: Riconoscere gli errori. Riceverà cinque brevi casi con l'output di dig allegato (nell'ambiente del corso). Scelga per ciascun caso quale dei dieci errori si tratta. Poi una vera ricerca: scopra con dig o uno strumento online quale record è sbagliato per dnssec-failed.org (stato e cosa restituisce +cd), e se wikipedia.org ha esattamente un solo record SPF.
Per saperne di più
Questi articoli descrivono le soluzioni nei pannelli di WebOké; presso altri fornitori i pulsanti hanno nomi diversi.
- Il sito web o l'indirizzo e-mail non funziona dopo un trasloco o una modifica DNS: verifichi il Suo dominio
- Quanto tempo richiede una modifica dei nameserver o del DNS, e cosa fare se non la vede?
- Guida DirectAdmin 18.7: Il mio dominio non funziona ancora dopo un trasferimento o una modifica
- Guida DirectAdmin 18.9: Non ricevo più email
- Guida DirectAdmin 5.4: Record CNAME e il punto finale
- L'invio di e-mail tramite PHP non funziona, i record MX puntano altrove
- Utilizzare nameserver propri o esterni (come Cloudflare) per il Suo dominio