Resumo

Em 25 de agosto de 2026, fomos informados de que gara.kulinaryos.com, uma plataforma de testes usada em atividades da FIC, não estava mais acessível. Confirmamos que o nome retornava NXDOMAIN, o que significa que ele não existia na zona DNS autoritativa. Após confirmarmos o destino original, o registro foi restaurado e a plataforma voltou a responder.

Pedimos desculpas pela interrupção do ambiente de testes.

Impacto

O acesso à plataforma Gara pelo endereço habitual ficou indisponível durante o incidente. Este incidente não causou impacto adicional no site institucional, app, ERP, diário de operações ou serviços de e-mail. Achados independentes já acompanhados nesses serviços continuam sendo tratados separadamente.

Constatações

Os dois servidores autoritativos da RBX retornam NXDOMAIN para o nome, e o mesmo resultado aparece nos resolvedores públicos da Cloudflare, Google e Quad9. O registro gara não consta na zona atual nem no backup histórico de DNS disponível para a migração.

A causa imediata é, portanto, a ausência do registro DNS, e não um atraso de propagação. O antigo endereço IP ou destino canônico da plataforma não estava presente na documentação DNS recuperada; criar um registro por suposição não seria seguro.

Recuperação

A configuração existente no servidor e o certificado TLS válido confirmaram que Gara está hospedada na mesma VPS do app e do ERP. O seguinte registro foi restaurado pelo repositório de infraestrutura da RBX:

gara.kulinaryos.com → 116.203.21.141

Os dois servidores autoritativos agora retornam o registro por UDP e TCP com o mesmo serial SOA. Cloudflare, Google e Quad9 resolvem o mesmo endereço. A validação HTTPS passa com certificado válido, / redireciona para /crm-fic e a resposta final da aplicação é HTTP 200.

Prevenção

  • Montar um inventário completo de subdomínios a partir de exportações DNS, configurações das aplicações, certificados e configurações dos servidores web antes de futuras migrações.
  • Conciliar o inventário com os responsáveis pelos serviços, incluindo ambientes de desenvolvimento e testes que possam não aparecer na exportação visível do registrador.
  • Adicionar verificações de disponibilidade antes e depois da migração para cada hostname confirmado.
  • Manter zona autoritativa, responsabilidade pelo serviço e destino de recuperação documentados em conjunto no controle de versão.
  • Tratar qualquer hostname legado descoberto posteriormente como achado da migração e incluí-lo no monitoramento antes de encerrar a janela de mudança.