Sintesi

Il 25 agosto 2026 ci è stato segnalato che gara.kulinaryos.com, una piattaforma di test utilizzata per le attività FIC, non era più raggiungibile. Abbiamo confermato che il nome restituiva NXDOMAIN, cioè non esisteva nella zona DNS autoritativa. Dopo aver verificato la destinazione originale, il record è stato ripristinato e la piattaforma è tornata accessibile.

Ci scusiamo per l'interruzione dell'ambiente di test.

Impatto

L'accesso alla piattaforma Gara tramite il suo indirizzo abituale non è stato disponibile durante l'incidente. Questo incidente non ha causato ulteriori impatti sul sito istituzionale, sull'app, sull'ERP, sul diario operativo o sui servizi e-mail. Gli elementi indipendenti già sotto osservazione per tali servizi continuano a essere monitorati separatamente.

Riscontri

Entrambi i server autoritativi RBX restituiscono NXDOMAIN per questo nome e lo stesso risultato è visibile tramite i resolver pubblici Cloudflare, Google e Quad9. Il record gara non è presente nella zona attuale né nel backup DNS storico disponibile per la migrazione.

La causa immediata è quindi l'assenza del record DNS, non un ritardo di propagazione. L'indirizzo IP precedente o il nome canonico della piattaforma non erano presenti nella documentazione DNS recuperata; creare un record ipotetico non sarebbe sicuro.

Ripristino

La configurazione esistente del server e il certificato TLS valido hanno confermato che Gara è ospitata sulla stessa VPS dell'app e dell'ERP. Il seguente record è stato ripristinato tramite il repository infrastrutturale RBX:

gara.kulinaryos.com → 116.203.21.141

Entrambi i server autoritativi restituiscono ora il record via UDP e TCP con lo stesso seriale SOA. Cloudflare, Google e Quad9 risolvono lo stesso indirizzo. La verifica HTTPS riesce con un certificato valido, / reindirizza a /crm-fic e la risposta finale dell'applicazione è HTTP 200.

Prevenzione

  • Creare un inventario completo dei sottodomini utilizzando esportazioni DNS, configurazioni applicative, certificati e configurazioni dei web server prima delle prossime migrazioni.
  • Riconciliare l'inventario con i responsabili dei servizi, includendo gli ambienti di sviluppo e test che potrebbero non comparire nell'esportazione visibile del registrar.
  • Aggiungere verifiche di disponibilità prima e dopo la migrazione per ogni hostname confermato.
  • Conservare insieme nel controllo versione la zona autoritativa, la responsabilità del servizio e la destinazione di ripristino.
  • Trattare ogni hostname legacy scoperto successivamente come elemento della migrazione e includerlo nel monitoraggio prima di chiudere la finestra di cambiamento.