Gli errori DNS più comuni dipendono da record mancanti, valori errati, nameserver non coerenti, cache ancora attive o conflitti tra record A, AAAA, CNAME, MX e DNSSEC. La diagnosi corretta consiste nel verificare prima chi gestisce la zona DNS, poi confrontare i risultati ottenuti da resolver differenti e infine correggere un solo elemento alla volta.
Il DNS stabilisce a quale server devono essere indirizzati sito, posta e altri servizi. Un errore nella zona può rendere irraggiungibile soltanto il sito, bloccare la ricezione delle email oppure produrre risultati differenti tra utenti e reti. Questa guida raccoglie gli errori DNS più comuni e propone un metodo ordinato per identificarli senza modifiche casuali.
Per creare o modificare i record consulta anche Zone Editor cPanel: record DNS. Prima di intervenire salva uno screenshot o un’esportazione della configurazione attuale.
Prima verifica chi gestisce realmente il DNS
Il primo controllo riguarda i nameserver autoritativi. Se il dominio utilizza nameserver Cloudflare, modificare la zona presente in cPanel non cambia il risultato pubblico. Se utilizza nameserver Xlogic, una modifica effettuata presso il registrar ma non nella zona autorevole può essere ignorata.
Puoi controllare i nameserver con:
dig NS esempio.it +short
host -t NS esempio.it
nslookup -type=NS esempio.itConfronta il risultato con i nameserver configurati presso il registrar. Se non coincidono, determina prima quale piattaforma deve essere mantenuta come autoritativa.
Record A errato o mancante
Il record A collega un nome IPv4 a un indirizzo IP. Se il dominio principale o il sottodominio www punta a un vecchio server, il browser mostrerà il sito precedente, una pagina predefinita o un errore di connessione.
Verifica:
dig A esempio.it +short
dig A www.esempio.it +short- l’indirizzo deve corrispondere al server corretto;
- il record
wwwpuò essere un A oppure un CNAME coerente; - non creare record duplicati con valori differenti;
- se usi Cloudflare, ricorda che un record Proxied restituisce IP Cloudflare e non l’IP origine.
Record AAAA rimasto sul vecchio server
Un record AAAA assegna un indirizzo IPv6. Alcune reti preferiscono IPv6 e altre utilizzano IPv4: per questo un AAAA errato può far funzionare il sito ad alcuni utenti e mostrare un server diverso ad altri.
dig AAAA esempio.it +shortSe il servizio non utilizza IPv6, non aggiungere un AAAA inventato. Se il record esiste, deve puntare a un IPv6 effettivamente configurato sul server e sul virtual host.
CNAME in conflitto con altri record
Un nome configurato come CNAME normalmente non deve avere contemporaneamente altri record dello stesso nome. Un errore frequente consiste nel creare un CNAME per www e lasciare anche un A differente, oppure nell’usare un CNAME sul dominio principale quando il provider DNS non supporta funzioni di flattening.
Controlla:
dig CNAME www.esempio.it +short
dig A www.esempio.it +shortIl risultato deve riflettere una sola strategia chiara. Non sostituire record MX, TXT o altri dati del dominio principale con un CNAME senza aver verificato le conseguenze.
Nameserver modificati solo parzialmente
Il dominio deve delegare a un insieme coerente di nameserver. Inserire un nameserver del vecchio provider e uno del nuovo può produrre risposte differenti, perché ogni server può contenere una zona diversa.
Verifica l’intero set presso il registrar e controlla che tutti i nameserver autorevoli restituiscano gli stessi record:
dig @ns1.esempio-dns.tld esempio.it A
dig @ns2.esempio-dns.tld esempio.it ASe le risposte non coincidono, correggi la zona o la delega prima di attendere ulteriormente.
Record MX e posta configurati in modo errato
I record MX stabiliscono quali server ricevono le email. Un MX errato può lasciare il sito perfettamente online ma bloccare la posta in entrata. Verifica:
dig MX esempio.it +short
dig A mail.esempio.it +shortLa destinazione MX deve essere un nome host completo che risolve a un indirizzo valido. Non usare direttamente un IP come valore MX. Se le caselle sono ospitate su Xlogic, controlla anche la modalità Email Routing; se la posta è esterna, preserva i record indicati dal provider.
Consulta Record MX errati e problemi di ricezione.
Record TXT duplicati o non validi
SPF, DKIM, DMARC e verifiche di servizi esterni utilizzano record TXT. L’errore più comune è pubblicare due record SPF distinti sullo stesso nome. In questo caso i destinatari possono considerare la configurazione non valida.
- mantieni un solo record SPF per nome;
- non rimuovere verifiche TXT che non riconosci senza identificarne l’uso;
- controlla virgolette e suddivisione automatica delle stringhe lunghe;
- verifica che DKIM e DMARC siano pubblicati sul nome corretto.
Per l’autenticazione email consulta Email Deliverability in cPanel.
DNSSEC configurato in modo incoerente
DNSSEC richiede coerenza tra la firma della zona e il record DS pubblicato presso il registrar. Se il DS resta attivo dopo un cambio di provider DNS o di chiavi, i resolver validanti possono restituire SERVFAIL anche quando i record sembrano corretti.
dig esempio.it A +dnssec
dig DS esempio.it +shortNon rimuovere o rigenerare le chiavi senza seguire una procedura coordinata. Consulta DNSSEC: come attivarlo in sicurezza.
Cache DNS locale, del provider o del browser
Una modifica corretta può non essere visibile subito perché il vecchio record è ancora nella cache di un resolver. Controlla il TTL e interroga più server:
dig @1.1.1.1 esempio.it A
dig @8.8.8.8 esempio.it A
dig @9.9.9.9 esempio.it ASe i resolver pubblici rispondono correttamente ma un solo dispositivo mostra il valore precedente, svuota la cache locale o cambia temporaneamente resolver. Non modificare di nuovo la zona soltanto perché un computer mantiene il vecchio dato.
Metodo di diagnosi consigliato
- annota il sintomo esatto: sito, posta, sottodominio o certificato;
- controlla nameserver e zona autoritativa;
- interroga il record interessato con
digo strumenti equivalenti; - confronta resolver pubblici e nameserver autoritativi;
- verifica TTL, DNSSEC e proxy Cloudflare;
- correggi un solo record alla volta;
- attendi il TTL precedente prima di concludere che la modifica non funzioni;
- esegui un nuovo test da rete e dispositivo differenti.
Quando aprire un ticket Xlogic
Apri un ticket quando la zona utilizza nameserver Xlogic e i nameserver autoritativi restituiscono dati inattesi, quando non puoi modificare il record necessario oppure quando il problema coinvolge configurazioni server, routing della posta o certificati.
Indica dominio, record atteso, risultato ottenuto, data e ora, nameserver utilizzati e screenshot della zona. Non inviare password, codici 2FA o chiavi private.
Fonti tecniche ufficiali
Domande frequenti sugli errori DNS
Perché il sito funziona da una rete ma non da un’altra?
Resolver differenti possono conservare record precedenti fino alla scadenza del TTL oppure preferire IPv6 quando esiste un record AAAA. Confronta A e AAAA da più resolver prima di modificare nuovamente la zona.
Posso avere due record A per lo stesso nome?
È tecnicamente possibile e può essere usato per distribuire il traffico, ma se gli indirizzi non ospitano lo stesso sito gli utenti riceveranno risultati incoerenti. Non usarlo come soluzione casuale a un problema DNS.
Un record Proxied Cloudflare deve mostrare l’IP Xlogic?
No. Un record Proxied restituisce indirizzi Cloudflare. L’IP origine resta nascosto; per verificarlo devi consultare la configurazione della zona o impostare temporaneamente DNS only solo quando necessario e sicuro.
SERVFAIL significa che il dominio non esiste?
No. SERVFAIL indica che il resolver non è riuscito a ottenere o validare una risposta. Una causa frequente è DNSSEC incoerente, ma possono esistere anche errori del nameserver o della zona.
Quanto devo aspettare dopo una correzione DNS?
Dipende dal TTL del record precedente e dalle cache intermedie. La modifica può essere visibile sui nameserver autoritativi subito, mentre i resolver possono continuare a servire il vecchio dato fino alla scadenza.