Resumo

  • A GoDaddy registrou o início às 21h20 GMT de 12 de dezembro de 2025 e a restauração às 21h28 GMT, depois de detectar e reverter o comando executado inadvertidamente [1].
  • A empresa disse que todos os serviços de DNS autoritativo da GoDaddy foram afetados. Consultas que precisavam de resposta nova podiam falhar; respostas válidas em cache reduziram a percepção para outros usuários [1].
  • O relato público não traz o comando, o fluxo de aprovação, prefixos ou nós afetados, volume de falhas nem hashes de configuração. Essas lacunas devem permanecer explícitas.
  • RFCs da IETF explicam Anycast, DNS autoritativo, TTL e monitoramento multiponto, mas não provam o mecanismo não divulgado deste incidente [2][3][4][5].
  • Um controle defensável vincula o comando a objetos exatos e exclusões, começa com canário reversível, mede o efeito fora do plano de controle e comprova configuração e serviço após o rollback.

Fixar a fronteira factual

Este texto trata do evento de 12 de dezembro de 2025, não da ocorrência de DNS distinta vivida pela GoDaddy em 2012. Datas, registros públicos e limites operacionais são diferentes; causas e correções não podem ser transportadas entre os casos.

A GoDaddy publicou sua explicação em 15 de dezembro. O registro do operador afirma que um comando foi executado inadvertidamente, o acesso Anycast ao DNS autoritativo ficou indisponível por oito minutos, todos os serviços autoritativos foram afetados, o comando foi detectado e revertido e as tabelas de roteamento se atualizaram quando a rede voltou [1].

O texto não identifica o objeto do comando. Não diz se a ação atingiu política BGP, orquestração, acoplamento entre saúde e anúncio, prefixo agregador ou outro componente. Também não lista prefixos, nós, sistemas autônomos, regiões, domínios, taxa de falha, aprovações ou hashes de antes e depois.

Essa ausência não demonstra que determinado controle não existia nem sustenta culpa individual. Ela limita a conclusão. Fatos específicos ficam atribuídos à GoDaddy; padrões técnicos servem para definir provas necessárias, não para inventar a topologia do incidente.

DNS autoritativo e Anycast são estados separados

O DNS autoritativo fornece a resposta de referência para nomes delegados. Quando um resolvedor recursivo não tem uma resposta utilizável, precisa consultar a autoridade. A RFC 1034 explica que o TTL limita a permanência de um registro em cache [4]. Por isso, dois usuários podem vivenciar o mesmo intervalo de formas diferentes.

Anycast distribui o acesso a um endereço de serviço. A RFC 4786 descreve o mesmo endereço anunciado a partir de vários nós separados, com o sistema de roteamento levando a solicitação a um deles [2]. Correção da zona, saúde do servidor e presença da rota são relacionadas, mas não idênticas.

Uma zona correta pode ficar inalcançável. Um nó apto a responder pode perder o anúncio. Uma rota visível pode levar a um serviço indisponível. É preciso ligar execução, estado de rota e consulta real para dizer qual camada mudou.

A GoDaddy falou em interrupção do “acesso Anycast” e em atualização das tabelas de roteamento durante a recuperação [1]. Isso sustenta a perda de alcançabilidade, mas não prova retirada de todos os anúncios BGP nem revela o objeto exato.

Um comando global precisa de identidade precisa

“A rede DNS” é amplo demais como objeto. A solicitação deve se resolver em endereços, prefixos, grupos de nós, políticas e revisões. O seletor legível é expandido em uma lista verificável, congelada e vinculada a um hash. Se o inventário mudar após a revisão, a aprovação expira.

A prova inclui o que fica fora. Se a ação mira um nó de teste, deve mostrar que nós produtivos e prefixos globais não estão no conjunto. Se é regional, outras áreas de captação precisam conservar anúncios e respostas corretas.

O texto do comando não basta. Alias, tags, grupos dinâmicos e configuração gerada podem ampliar o alcance. A revisão deve analisar alvos resolvidos, estado corrente, delta renderizado e efeito esperado no roteamento.

Operações globais podem ser necessárias em crises. Por isso exigem classe superior: aprovação independente, rollback pré-calculado, critérios de parada, sondas externas e expansão gradual a partir de um alvo isolado.

Muitos nós não garantem independência

Anycast oferece distribuição geográfica, mas um controle compartilhado pode ser o verdadeiro domínio de falha. Se um seletor, gerador, credencial ou orquestrador altera todos os nós, a separação física não protege contra a ação comum.

A RFC 4786 discute o acoplamento entre disponibilidade e anúncio, riscos de prefixos que cobrem vários serviços e a dificuldade de observar Anycast de um único local [2]. Independência é comprovada por uma transição de falha, não pela quantidade de caixas num diagrama.

Um teste retira um nó ou conjunto de anúncios e confirma respostas corretas nos demais. Também verifica que a recuperação automática não amplia falha local e que um serviço compartilhando prefixo não remove os outros.

A expansão do seletor pode ser testada em ambiente isolado, rejeitando qualquer alvo extra. Em produção, um canário reversível altera apenas um grupo enquanto consultas sintéticas partem de diversas redes. A ampliação só ocorre com áreas não afetadas estáveis.

Cache muda a visibilidade, não a obrigação

A GoDaddy disse que o cache limitou boa parte do impacto aos usuários que precisavam de nova busca [1]. É uma qualificação importante: a queda da autoridade não necessariamente aparece como desligamento simultâneo de todos os sites.

Cache não é garantia. Nomes novos podem não estar armazenados, registros podem expirar e resolvedores aplicam políticas diferentes. A RFC 8767 descreve a possibilidade de servir dados vencidos em certas condições [5], mas não identifica quais resolvedores fizeram isso neste caso.

Métricas devem separar sucesso autoritativo, alcançabilidade do endereço, resposta em cache e acesso final. Uma cópia armazenada reduz o sintoma sem provar disponibilidade da autoridade.

A recuperação também tem relógios distintos: configuração, convergência, nova tentativa do resolvedor e aplicação. Além de 21h28 GMT, o fechamento deveria reter a distribuição observada em várias redes.

O registro de controle precisa coincidir com a rede em execução

Inventários, repositórios de políticas e plataformas de implantação são livros de registro necessários. Identificam objetos aprovados, responsáveis e estado desejado. Não são a rede. Um seletor aprovado pode expandir errado; uma API pode informar sucesso e produzir efeito incorreto; um registro de rollback não prova que consultas públicas voltaram.

Uma única identificação de mudança deve unir pedido, hash dos alvos, delta, revisor, execução, rotas por nó, consultas externas e restauração. Relógios comuns ordenam comando, mudança de rota e falha.

Evidência de execução mostra o que se tentou. Evidência de efeito mostra o que ocorreu. Se o cliente perde a resposta, parte da operação pode ter sido aplicada. Chave de idempotência e estado real devem ser reconciliados antes de reenviar.

Rollback não é só um segundo comando. Deve demonstrar estado anterior, anúncios esperados, respostas corretas, estabilidade externa e divergências residuais.

Pacote de evidência executável

Antes da ação, o pacote fixa consequência, endereços, nós, alcance local ou global, dependências, estado, delta, revisão, canário, paradas e rollback testado. Mudança nos alvos exige nova revisão.

Durante a execução, preserva em modo append-only identidade autenticada, bytes da solicitação, chave de idempotência, resposta por alvo e revisão. Observadores externos registram rotas, códigos DNS, conteúdo, latência e captação. A credencial que muda a rede não deve editar a evidência.

Depois, várias regiões consultam diretamente os endereços autoritativos. Nomes controlados sem cache ou com TTL curto evitam falso verde. Divergência entre saúde interna e alcançabilidade externa impede o fechamento.

O teste de recorrência cobre pelo menos: retirar um nó mantendo os demais, rejeitar seletor propositalmente amplo antes da execução e reconciliar resultado desconhecido sem repetição cega. Alvos, rotas, respostas, alertas e restauração ficam juntos.

Comunicação pública precisa sem expor segredos

A GoDaddy publicou data, duração, classe de serviço, categoria da ação, mecanismo de impacto, restauração e grupos de melhoria [1]. Uma atualização poderia dizer se o comando atingiu objeto global compartilhado, se havia canário e limite, como a perda foi detectada, se o rollback estava pré-aprovado e se um teste provou isolamento.

Não é necessário divulgar sintaxe, credenciais ou prefixos sensíveis. É necessário diferenciar melhoria planejada de controle testado. Clientes de DNS autoritativo não auditam o roteamento interno; um registro público delimitado permite avaliar a mudança de risco.

Limite de responsabilidade

A GoDaddy controlava a plataforma autoritativa descrita e o comando que afirmou ter executado inadvertidamente. Resolvedores, redes de acesso, navegadores e sistemas operacionais controlavam cache e repetição. O roteamento global conectava as partes. Esses limites explicam variação sem apagar a propriedade do controle inicial.

O operador deve limitar a ação aos objetos pretendidos, detectar perda inesperada de alcançabilidade e restaurar estado verificado. Resolvedores podem melhorar resiliência, mas não substituir indefinidamente uma autoridade alcançável.

A conclusão é sobre evidência: Anycast distribui serviço quando controles preservam nós independentes e alcançáveis. Cache alivia sintomas enquanto uma resposta é utilizável. Um comando global só merece confiança quando alvo, delta, aprovação, efeito e rollback estão unidos e testados contra a rede real.

Fontes

  1. https://www.godaddy.com/resources/news/understanding-godaddys-12-12-dns-interruption
  2. https://www.rfc-editor.org/rfc/rfc4786.html
  3. https://www.rfc-editor.org/rfc/rfc9199.html
  4. https://www.rfc-editor.org/rfc/rfc1034.html
  5. https://www.rfc-editor.org/rfc/rfc8767.html