Il portale è irraggiungibile ma il server è acceso: quando il problema è nel DNS e come diagnosticarlo in 10 minuti

A luglio 2025 mi ha chiamato il titolare di un e-commerce B2B nel settore dell'illuminotecnica - circa 600 clienti attivi, portale Laravel 10 su VPS Hetzner CPX41 - con il classico: "Il sito non va." Il server era acceso, SSH rispondeva, Nginx serviva correttamente da localhost (curl http://127.0.0.1 restituiva la home page), MySQL era attivo, PHP-FPM non dava errori. Tutto funzionava - tranne che nessun browser al mondo riusciva a raggiungere il sito digitando il dominio.

Il problema non era nel server, non era nell'applicazione, non era nella rete. Il problema era a monte di tutto: il DNS. La sera prima, il titolare aveva autorizzato il trasferimento del dominio da un registrar italiano a un provider internazionale - un'operazione che sulla carta è routine. Ma il trasferimento aveva cambiato i nameserver di riferimento, il vecchio registrar aveva già cancellato la zona DNS, e il nuovo provider non aveva ancora ricevuto la configurazione corretta. Per 6 ore il dominio aveva puntato al nulla.

Il DNS è l'invisibile che tiene insieme internet. Quando funziona - il 99,9% del tempo - nessuno ci pensa. Quando si rompe, niente funziona: il sito scompare, le email non arrivano, le API non rispondono. E il problema è che un errore DNS non genera nessun log nel server, nessun allarme in Nginx, nessuna eccezione in Laravel. Il server non sa nemmeno che nessuno lo sta raggiungendo. Per il titolare del portale illuminotecnico, le 6 ore di downtime DNS si sono tradotte in circa 40 ordini persi (stima basata sulla media storica del periodo) e un numero imprecisato di clienti che hanno rinunciato e sono andati a comprare altrove. Il costo di un downtime DNS è identico al costo di un downtime server - con la differenza che il server si riavvia in 30 secondi e il DNS si propaga in ore. Per una PMI B2B dove i clienti hanno alternative a un click di distanza, 6 ore di irraggiungibilità possono costare relazioni commerciali che hanno richiesto anni per costruire.

Come si diagnostica un problema DNS in 10 minuti senza strumenti specialistici?

La diagnosi DNS si fa con tre comandi disponibili su qualunque sistema Linux. Non serve Wireshark, non serve un account Cloudflare, non serve nessun tool proprietario. Servono dig, whois e 10 minuti di metodicità:

# 1. Il dominio risolve? A quale IP?
dig +short portale.it A
# Se restituisce vuoto → il record A non esiste o i nameserver non rispondono

# 2. Quali nameserver sono autoritativi per il dominio?
dig NS portale.it +short
# Se restituiscono nameserver del vecchio provider → il trasferimento non è completo

# 3. Il nameserver risponde? (interrogalo direttamente)
dig @ns1.nuovoprovider.com portale.it A
# Se timeout → il nameserver non ha la zona configurata

# 4. Cosa dice il registrar? (stato del dominio nel registry)
whois portale.it | grep -i "nameserver\|status\|registrar"

# 5. Confronto: cosa vede Google DNS vs cosa vede il tuo resolver locale
dig @8.8.8.8 portale.it A +short
dig @1.1.1.1 portale.it A +short
dig portale.it A +short

Sul dominio del cliente illuminotecnico, il primo comando restituiva vuoto. Il secondo mostrava i nameserver del nuovo provider. Il terzo andava in timeout - il nuovo provider non aveva ancora configurato la zona. Il quarto confermava che il trasferimento era completato a livello di registry - i nameserver erano stati aggiornati - ma la zona DNS sul nuovo provider era vuota. Il dominio esisteva, puntava a nameserver reali, ma quei nameserver non sapevano nulla del dominio.

Un punto importante sulla metodicità della diagnosi: quando un sito è irraggiungibile, la tentazione è saltare subito a "riavvio il server" o "controllo Nginx". Ma se il server risponde via SSH e curl http://127.0.0.1 restituisce contenuto, il server funziona - e qualunque intervento sul server è tempo perso. Il DNS è la prima cosa da verificare, non l'ultima. La regola che applico in ogni intervento di emergenza è: se il server risponde da localhost ma non dal dominio, il problema è nel DNS fino a prova contraria.

Un secondo strumento che uso quando il problema non è evidente con dig: traceroute e mtr per verificare se il traffico raggiunge effettivamente il server. Se il DNS risolve all'IP corretto ma il sito non risponde, il problema potrebbe essere nel routing di rete (raro su VPS Hetzner/OVH, più comune su provider minori) o nel firewall del server. Ma sul caso del cliente illuminotecnico il problema era chiaro: dig restituiva vuoto, il DNS era la causa.

Il fix è stato in due passaggi: primo, creare la zona DNS sul nuovo provider con i record corretti (A, AAAA, MX, CNAME www, TXT per SPF/DKIM/DMARC). Secondo, impostare un TTL basso (300 secondi = 5 minuti) su tutti i record per accelerare la propagazione. In 15 minuti dal fix, il sito era raggiungibile da Google DNS (8.8.8.8). In 2 ore, dalla maggior parte dei resolver mondiali. In 6 ore, da tutti - inclusi i resolver ISP italiani che tipicamente hanno cache più aggressive.

Stai cercando un Consulente Informatico esperto per diagnosticare e risolvere problemi DNS sulla tua infrastruttura? Nel mio profilo professionale trovi l'esperienza concreta su configurazione DNS, migrazione di dominio e gestione di VPS Hetzner, OVH, Contabo e Digital Ocean per PMI.

Le 6 misconfigurazioni DNS che trovo più spesso su VPS di PMI

Nei miei interventi su VPS di PMI italiane, i problemi DNS si ripetono con una regolarità impressionante. Ecco i cinque più frequenti, in ordine di probabilità:

1. Record A mancante per www. Il dominio portale.it risolve correttamente, ma www.portale.it no. Sembra banale, ma la documentazione sulle cause di downtime post-propagazione documenta che i record www mancanti sono tra le cause più comuni di parziale irraggiungibilità. Il fix è un CNAME www.portale.it → portale.it o un secondo record A con lo stesso IP.

2. TTL troppo alto su record che cambiano. Un TTL di 86400 (24 ore) significa che se cambi IP del server - per una migrazione, un upgrade, un failover - i client continueranno a raggiungere il vecchio IP per un'intera giornata. Il consiglio operativo standard è abbassare il TTL a 300-600 secondi almeno 24 ore prima di qualunque cambio pianificato, fare il cambio, verificare la propagazione, e poi rialzare il TTL a valori normali (3600-14400).

3. Record MX mancanti o errati. Il sito funziona ma le email non arrivano - o arrivano al server sbagliato. Se la posta è gestita da Google Workspace, Microsoft 365 o un altro provider, i record MX devono puntare ai loro server, non all'IP del VPS. Un problema che si manifesta spesso dopo migrazioni di dominio dove i record MX non vengono copiati.

4. Record SPF/DKIM/DMARC non allineati dopo migrazione. Legato al punto 3: dopo un cambio di provider DNS, i record TXT per SPF, DKIM e DMARC devono essere ricreati manualmente - non vengono trasferiti automaticamente con il dominio. Ho descritto in dettaglio l'impatto di SPF/DKIM/DMARC mancanti sulla deliverability delle email nel mio articolo sulle email transazionali di Laravel che finiscono in spam.

5. Glue record orfani dopo cambio nameserver. Quando si cambiano i nameserver di un dominio, i vecchi glue record (i record A dei nameserver stessi, registrati al livello del registry) possono restare attivi. Alcuni resolver continuano a interrogare i vecchi nameserver attraverso i glue record anche dopo che i NS record sono stati aggiornati. Il sintomo è un downtime che colpisce solo alcuni utenti e solo per alcune ore - il tipo di problema intermittente che è quasi impossibile da diagnosticare senza dig +trace che mostra l'intera catena di risoluzione dalla root fino al record finale.

6. DNSSEC non disabilitato prima del trasferimento. Se il vecchio registrar aveva DNSSEC abilitato, il record DS nel registry punta alle chiavi del vecchio provider. Dopo il trasferimento, il nuovo provider ha chiavi diverse (o non ha DNSSEC configurato), e i resolver che validano DNSSEC rifiutano le risposte come non autentiche. Il risultato: il sito funziona per chi non usa DNSSEC validation (la maggioranza), ma è irraggiungibile per chi lo usa (inclusi alcuni resolver aziendali). La soluzione: disabilitare DNSSEC sul vecchio registrar prima del trasferimento, aspettare la propagazione della rimozione del record DS, e solo dopo trasferire il dominio.

Come prevenire downtime DNS: la checklist pre-migrazione

Dopo il fix sul cliente illuminotecnico, ho documentato una checklist che ora uso prima di ogni migrazione di dominio o cambio di provider DNS:

[ ] Esportare TUTTA la zona DNS attuale (tutti i record, non solo A e CNAME)
[ ] Verificare record MX, TXT (SPF/DKIM/DMARC), CAA
[ ] Abbassare TTL a 300s su tutti i record almeno 24 ore prima
[ ] Se DNSSEC è attivo: disabilitarlo e attendere propagazione DS removal
[ ] Creare la zona sul nuovo provider con tutti i record PRIMA di cambiare NS
[ ] Verificare con dig @nuovo-ns dominio.it A che la zona risponda
[ ] Solo allora: procedere con il cambio dei nameserver
[ ] Monitorare propagazione per 24 ore con dig @resolver diversi
[ ] Dopo 48 ore: rialzare TTL a valori normali (3600-14400)

Questa checklist sembra ovvia. Non lo è: nella mia esperienza, 7 migrazioni di dominio su 10 saltano almeno due di questi passaggi. E ognuno dei passaggi saltati è un potenziale downtime. Il punto che sfugge alla maggior parte dei titolari PMI è che un errore DNS non ha un rollback istantaneo: anche se correggi il record immediatamente, la propagazione richiede tempo - da 5 minuti (se il TTL era basso) a 24 ore (se era alto). È l'unico tipo di errore infrastrutturale in cui il fix non coincide con il ripristino del servizio. E questo è il motivo per cui la prevenzione - TTL basso prima del cambio, zona pronta sul nuovo provider, verifica con dig - è enormemente più importante del fix post-incidente.

Sul portale ufficiale DNS.org dedicato al troubleshooting ci sono molti esempi di downtime causati da errori che sembrano banali: un punto mancante alla fine di un record CNAME (che trasforma www.portale.it in www.portale.it.portale.it), un record A duplicato con IP diversi che causa comportamento casuale, un record TXT con virgolette non chiuse che corrompe l'intera zona. Il DNS è il sistema più fragile e meno monitorato di qualunque infrastruttura web - e il primo che dovrebbe avere un alert attivo.

Monitoring DNS: sapere prima del cliente che qualcosa non va

Il DNS è l'unico componente dell'infrastruttura che la maggior parte delle PMI non monitora affatto. Il monitoring di PHP-FPM, MySQL, disco e CPU è ormai comune. Ma un check che verifichi che il dominio risolva correttamente all'IP giusto? Quasi mai presente. Eppure è il check più semplice da implementare.

Con Blackbox Exporter di Prometheus (lo stesso componente che uso per il check HTTPS descritto nel mio articolo sul monitoring proattivo per Laravel su VPS), il check DNS è una configurazione di poche righe:

# /etc/prometheus/blackbox.yml - modulo DNS
modules:
  dns_portale:
    prober: dns
    timeout: 5s
    dns:
      transport_protocol: udp
      query_name: "portale.it"
      query_type: "A"
      valid_rcodes:
        - NOERROR
      validate_answer_rrs:
        fail_if_not_matches_regexp:
          - ".*XXX\\.XXX\\.XXX\\.XXX.*"  # IP atteso del VPS

L'alert scatta quando il DNS restituisce un IP diverso da quello atteso o non restituisce nulla - esattamente lo scenario del cliente illuminotecnico. Con questo check attivo, il problema sarebbe stato rilevato in 30 secondi anziché in 6 ore. Il costo: zero (Blackbox Exporter è open source), il tempo di configurazione: 10 minuti.

Per completare il quadro del monitoring, consiglio anche un check esterno - un servizio come UptimeRobot o Healthchecks.io che verifica la raggiungibilità del sito da più location geografiche. Il check interno (Prometheus sul VPS) verifica che il VPS sia in grado di risolvere il proprio dominio; il check esterno verifica che il resto del mondo lo possa fare. Sono complementari: un problema DNS che colpisce solo il resolver locale del VPS non verrà visto dal check esterno, e un problema che colpisce solo alcuni resolver geografici non verrà visto dal check interno.

Per chi vuole un quadro più ampio sulla gestione degli incidenti su infrastruttura - non solo DNS ma anche server, applicazione e comunicazione - ho scritto una guida dedicata all'incident response in 72 ore per Laravel e Symfony che copre il protocollo completo con tempistiche NIS2.

Se il tuo sito è irraggiungibile e non capisci perché - il server è acceso, l'applicazione funziona, ma nessuno riesce a raggiungerti - il problema è quasi certamente nel DNS. La diagnosi richiede 10 minuti e tre comandi. Contattami se hai bisogno di assistenza: in un'ora verifico la catena DNS completa, identifico il problema e lo risolvo, e se stai pianificando una migrazione di dominio o un cambio di provider DNS, posso gestirla con la checklist operativa che garantisce zero downtime verificato.