Ing. Calogero Bono
Lunedì mattina, alle sei, i siti dei nostri clienti hanno smesso di rispondere. I server erano accesi, i siti funzionavano, i database erano al loro posto. Eppure chiunque provasse ad aprirli riceveva un errore. Il motivo era un dominio che quasi nessuno vede, quello che usiamo per i nostri nameserver.
Lo raccontiamo perché è un errore che può capitare a qualunque agenzia o azienda che gestisce i propri DNS, e perché la lezione vale molto più delle tre ore che ci è costata.
Cosa sono i nameserver e perché un solo dominio può spegnere tutto
Quando qualcuno scrive l'indirizzo di un sito, il suo dispositivo chiede a internet a quale server corrisponde. La risposta la danno i nameserver, cioè i server che custodiscono le zone DNS dei domini.
I nameserver hanno anche loro un nome, per esempio ns1.qualcosa. E quel nome appartiene a un dominio. Se quel dominio smette di esistere, i nameserver diventano irraggiungibili per nome, e con loro tutti i siti che si appoggiano a quei nameserver. Non solo il sito principale, ma ogni dominio cliente delegato lì.
È esattamente quello che è successo a noi.
Il trasferimento era partito, ma non era finito
Venerdì avevamo avviato il trasferimento del dominio dei nostri nameserver verso il registrar che usiamo per tutti gli altri domini. Scadeva il sabato e pensavamo di essere coperti. Il trasferimento era stato accettato, il registro mostrava il dominio come «in trasferimento», e i nameserver erano rimasti identici.
Il problema è che un trasferimento di un dominio generico, come un .com o un .cloud, può richiedere fino a cinque giorni. Fino a quando non si chiude, il dominio resta del vecchio registrar. E per il vecchio registrar quel dominio era semplicemente scaduto e non pagato.
Lunedì mattina lo ha sospeso. Una sospensione di questo tipo toglie il dominio dalla zona pubblica, quindi i nameserver sono spariti da internet e tutti i domini delegati hanno cominciato a rispondere con un errore.
La lezione numero uno. Un trasferimento in corso non ti protegge dalla scadenza. Se un dominio scade tra pochi giorni, prima si rinnova dal registrar attuale, poi si trasferisce con calma.
Come abbiamo rimesso online i siti senza aspettare
Aspettare la fine del trasferimento voleva dire giorni. Abbiamo quindi creato dei nameserver di riserva sotto il nostro dominio principale, registrando i loro indirizzi direttamente nel registro del dominio. In questo modo non dipendevano più dal dominio sospeso.
Poi abbiamo spostato sui nuovi nameserver tutti i domini che gestiamo direttamente. Per i domini .com il cambio è stato visibile in pochi minuti. Per i .it ci è voluto di più, per due motivi che vale la pena conoscere.
- Il registro .it controlla i nameserver prima di accettarli. Verifica che rispondano davvero per quel dominio e che diano tutti la stessa risposta. Se la zona è incoerente anche per un minuto, la richiesta viene rifiutata.
- Il registro .it pubblica le modifiche a intervalli. Anche dopo l'approvazione bisogna aspettare il successivo aggiornamento della zona .it.
Nel nostro caso le prime richieste sono state rifiutate perché uno script interno, scritto anni fa per tenere allineate le zone, rimetteva automaticamente i nameserver vecchi. Lo abbiamo corretto, abbiamo ripresentato le richieste, e i domini .it sono tornati online con l'aggiornamento successivo del registro.
La lezione numero due. Prima di cambiare qualcosa nei DNS, bisogna sapere quali automatismi toccano le stesse zone. Un sistema che «aggiusta da solo» può remare contro proprio quando serve una modifica d'emergenza.
E la posta?
La posta segue gli stessi nomi. Le caselle dei clienti con il nome del server legato al dominio sospeso hanno smesso di collegarsi, mentre quelle configurate con un nome sul dominio del cliente hanno continuato a funzionare appena il dominio è tornato raggiungibile. Le email inviate durante il blocco non sono andate perse. I server di chi spedisce riprovano per ore, e i messaggi arrivano appena la destinazione torna raggiungibile.
C'è poi un dettaglio che molti trascurano, il nome inverso del server di posta. Quando un server riceve una mail controlla come si chiama il server che la spedisce e se quel nome punta davvero allo stesso indirizzo. Se il nome inverso appartiene al dominio sospeso, il controllo fallisce e le mail rischiano di finire in spam. Va allineato su un dominio sano.
La checklist che usiamo da oggi
- Rinnovo automatico sui domini che reggono l'infrastruttura, quelli dei nameserver, della posta e del pannello.
- Mai trasferire un dominio a pochi giorni dalla scadenza senza averlo prima rinnovato dal registrar attuale.
- Nameserver di riserva su un dominio diverso, già pronti e già nel registro, da usare in caso di emergenza.
- Elenco degli script che modificano le zone DNS, da fermare o aggiornare prima di ogni intervento manuale.
- Nome inverso e nome del server di posta sul dominio principale, non su un dominio tecnico secondario.
- Un promemoria trenta giorni prima di ogni scadenza critica, a una persona precisa e non a una casella che nessuno legge.
Perché lo raccontiamo
Perché succede, anche a chi fa questo lavoro ogni giorno. La differenza non la fa l'assenza di errori, ma quanto velocemente li capisci, li risolvi e fai in modo che non si ripetano. Se gestisci da solo i DNS della tua azienda o dei tuoi clienti, controlla oggi la scadenza del dominio dei tuoi nameserver. Ci vuole un minuto.
Se vuoi che diamo un'occhiata noi alla tua configurazione di domini, DNS e posta, scrivici. Ti diciamo cosa rischi e come metterlo in sicurezza.
