Summary

On 25 August 2026, we were informed that gara.kulinaryos.com, a test platform used for FIC activities, was no longer reachable. We confirmed that the hostname returned NXDOMAIN, meaning that it did not exist in the authoritative DNS zone. After confirming the original destination, the record was restored and the platform became reachable again.

We apologize for the disruption to the test environment.

Impact

Access to the Gara test platform through its usual hostname was unavailable during the incident. This incident caused no additional impact on the institutional site, app, ERP, operations journal or email services. Unrelated findings already under observation for those services continue to be tracked separately.

Findings

Both RBX authoritative servers return NXDOMAIN for the hostname, and the same result is visible through Cloudflare, Google and Quad9 public resolvers. The gara record is absent from the current zone and from the historical DNS backup available for the migration.

The immediate cause is therefore a missing DNS record, not propagation delay. The platform's former IP address or canonical target was not present in the recovered DNS documentation, so creating a speculative record would be unsafe.

Recovery

The existing server configuration and valid TLS certificate confirmed that Gara is hosted on the same VPS as the app and ERP. The following record was restored through the RBX infrastructure repository:

gara.kulinaryos.com → 116.203.21.141

Both authoritative servers now return the record over UDP and TCP with an identical SOA serial. Cloudflare, Google and Quad9 resolve the same address. HTTPS validation succeeds with a valid certificate, / redirects to /crm-fic, and the final application response is HTTP 200.

Prevention

  • Build a complete subdomain inventory from DNS exports, application settings, certificates and web-server configuration before future migrations.
  • Reconcile the inventory with service owners, including development and test environments that may not appear in the registrar's visible zone export.
  • Add pre-migration and post-migration availability checks for every confirmed hostname.
  • Keep the authoritative zone, service ownership and recovery destination documented together in version control.
  • Treat any newly discovered legacy hostname as a migration finding and include it in the monitoring scope before closing the change window.