Defeito de cache DNS do Azure em 2021 e amplificação por novas

Resumo

Entre 21:21 UTC e 22:00 UTC em 1º de abril de 2021, o DNS do Azure apresentou um problema de disponibilidade de serviço. A Microsoft afirmou que a maioria dos serviços dependentes havia se recuperado por volta das 22:30 UTC. O aviso comunitário contemporâneo usou uma janela de impacto aproximada das 21:30 às 22:30, enquanto o monitoramento independente registrou um alarme por volta das 21:20. São observações diferentes, não necessariamente relógios contraditórios. [1][2]
A Microsoft descreveu um aumento anômalo de consultas DNS vindas de todo o mundo, com alvo em um conjunto de domínios hospedados no Azure. Ela não identificou publicamente um atacante, intenção, botnet ou campanha confirmada de negação de serviço distribuída. O aumento inicial precisa permanecer sem explicação além da descrição da Microsoft. [2][4][5]
A Microsoft afirmou que uma sequência específica de eventos expôs um defeito de código que reduziu a eficiência dos caches de borda do DNS do Azure. O registro público não revela o caminho de código, a chave de cache, a taxa de acertos, a população de borda afetada ou o trabalho de backend criado por cada erro de cache. [2][4][5]
À medida que o serviço DNS ficava sobrecarregado, os clientes tentavam novamente as requisições com mais frequência. A Microsoft afirmou que o sistema de mitigação de picos volumétricos considerou essas novas tentativas legítimas e, portanto, não as descartou. Isso sustenta um ciclo de realimentação de amplificação por novas tentativas, mas não uma reconstrução precisa no nível de pacotes. [2][4]
A Microsoft afirmou que o monitoramento detectou menor disponibilidade, engenheiros foram acionados e o serviço DNS se recuperou automaticamente às 22:00 UTC. Ela reconheceu que o tempo de recuperação excedeu sua meta de projeto. Em seguida, mudou a lógica de mitigação para proteger contra novas tentativas excessivas e listou o reparo do defeito de cache, além de melhor detecção de tráfego anômalo, como próximos passos. [2][4][5]
O incidente afetou um plano de controle de rede, e não uma única aplicação. Os usuários tiveram dificuldade intermitente para resolver nomes usados pelo Azure, Dynamics, Xbox Live e outros serviços da Microsoft. Um registro de serviço correto não bastava quando o caminho autoritativo em execução não devolvia respostas confiáveis. [1][3][6]
A documentação atual do Azure descreve uma rede global de DNS anycast, recursos de confiabilidade e controles do cliente. Esses materiais explicam arquitetura e responsabilidade, mas não podem ser usados como prova da implementação exata de 2021 nem da conclusão da remediação. [7]-[13]
Os padrões de DNS separam o serviço autoritativo da resolução recursiva e documentam como cache, ausência de resposta e novas tentativas moldam a carga. A RFC 4697 é especialmente relevante porque o comportamento de novas tentativas dos resolvedores pode impor trabalho excessivo aos servidores autoritativos. Os padrões não mostram quais clientes ou resolvedores contribuíram com qual parcela durante este incidente. [14]-[22]
A responsabilidade acompanha o controle. A engenharia do DNS do Azure controlava o código de cache, a capacidade de borda, a modelagem de tráfego, a classificação da mitigação e a automação de recuperação. As equipes de serviços da Microsoft controlavam as dependências compartilhadas de DNS. Operadores de resolvedores e clientes controlavam o comportamento de novas tentativas e de cache. Os clientes controlavam algumas escolhas de monitoramento e delegação, mas não podiam inspecionar nem reparar o defeito interno do Azure.
Um reparo confiável exige evidências limitadas no tempo: taxas de acerto de cache por classe de consulta, taxas de novas tentativas, saturação de borda, mudanças de catchment anycast, comportamento das regras de mitigação, sondas de resolução de validade conhecida, recuperação por serviço e testes de recorrência. Nada disso deve ser inferido apenas de um rótulo de status.

A linha do tempo contém vários relógios

Relatórios de incidentes muitas vezes ficam mais limpos com o tempo. O registro do DNS do Azure deve resistir a essa limpeza quando ela apaga distinções úteis.

A narrativa posterior do incidente da Microsoft situou o problema de disponibilidade do serviço DNS do Azure entre 21:21 UTC e 22:00 UTC em 1º de abril de 2021. Ela afirmou que a maioria dos serviços se recuperou até as 22:30 UTC. A Exoprise reproduziu esse relato e informou que seu próprio monitoramento de DNS e servidores gerou um alarme por volta das 21:20. [2] Um aviso comunitário contemporâneo de um funcionário da Microsoft, publicado enquanto a resposta ainda estava em andamento, descreveu impacto ao cliente entre aproximadamente 21:30 UTC e 22:30 UTC.

Uma atualização posterior de outro funcionário da Microsoft na mesma página afirmou que os servidores DNS da Microsoft haviam visto um pico de tráfego e que recursos resilientes de DNS haviam sido acionados. [1]

Esses registros de horário medem coisas diferentes:

a primeira observação de falha de um monitor externo;
o horário de início posterior definido pelo provedor para a condição do serviço DNS;
o horário em que o provedor considerou o DNS automaticamente recuperado;
o período em que os clientes tiveram acesso intermitente;
o horário em que a maioria dos serviços dependentes se recuperou.

O relato contemporâneo do The Register citou o início aproximado das 21:30 UTC e informou que a Microsoft havia redirecionado o tráfego para recursos resilientes de DNS enquanto investigava. Ele descreveu efeitos nas principais regiões geográficas, excluindo a nuvem governamental da Microsoft e os serviços da China do escopo relatado. [3] O TechCrunch, separadamente, relatou falhas que atingiram vários produtos da Microsoft e citou a Microsoft reconhecendo um problema no Portal do Azure e nos serviços do Azure. [6]

As evidências públicas não estabelecem um momento universal de recuperação para todos os nomes, resolvedores, regiões ou serviços. Caches de DNS podem fazer com que falha e recuperação apareçam em momentos diferentes. Um resolvedor com uma resposta em cache ainda pode continuar servindo um nome depois que a disponibilidade autoritativa cai. Outro resolvedor com cache frio pode falhar imediatamente. Quando o serviço autoritativo melhora, estados negativos ou de falha em clientes e resolvedores intermediários ainda podem atrasar a recuperação visível.

A própria Microsoft distinguiu a recuperação automática do DNS às 22:00 da recuperação da maioria dos serviços às 22:30. [2]

Essa distinção importa para a responsabilização. Um provedor não deve definir recuperação apenas por uma métrica interna de servidor se os usuários ainda não conseguem resolver nomes críticos. Nem um alarme externo deve ser tratado automaticamente como o início da causa raiz. Uma linha do tempo reconciliada precisa de pelo menos quatro trilhas: saúde do serviço autoritativo, resultados dos resolvedores recursivos, recuperação dos serviços dependentes e alcançabilidade visível ao usuário.

Um aumento anômalo não é um ataque comprovado

A Microsoft afirmou que o DNS do Azure recebeu um aumento anômalo de consultas vindas de todo o mundo, com alvo em um conjunto de domínios hospedados no Azure. [2][4] Isso é uma descrição de volume e distribuição de alvos. Não estabelece, por si só, quem gerou o tráfego, se a intenção era maliciosa, se os endereços de origem foram falsificados ou se o evento atendeu a uma classificação específica de negação de serviço.

Parte da cobertura usou linguagem de ataque. O registro técnico citado aqui não fornece amostra de pacotes, relatório de atribuição ou declaração da Microsoft nomeando uma campanha de DDoS. O padrão probatório futuro é, portanto, restrito:

Confirmado pelo relato da Microsoft: um aumento global de consultas teve como alvo um conjunto de domínios hospedados no Azure.
Confirmado pelo relato da Microsoft: esperava-se que os caches normais e a modelagem de tráfego do serviço atenuassem tal aumento.
Confirmado pelo relato da Microsoft: um defeito de código reduziu a eficiência do cache de borda sob uma sequência específica.
Desconhecido: o que iniciou o aumento.
Desconhecido: se um ator coordenado pretendia negar o serviço.
Desconhecido: se o tráfego foi falsificado, refletido, gerado por dispositivos comprometidos, causado por comportamento de software ou combinou várias fontes.
Desconhecidos: os nomes, tipos de consulta, taxas e distribuições geográficas envolvidos.

Essa fronteira não é cautela semântica por si só. O reparo depende do mecanismo. A validação de endereço de origem pode restringir tráfego falsificado, mas não impede que clientes legítimos tentem novamente. Um limitador de taxa pode suprimir alto volume, mas pode rejeitar resolução válida. Mais capacidade de cache pode ajudar perguntas repetidas, mas pode não ajudar uma carga dominada por nomes únicos ou combinações de consulta que ignoram cache. Melhor distribuição anycast pode espalhar o trabalho e, ao mesmo tempo, deslocar a sobrecarga entre bordas.

Chamar o aumento de ataque sem evidências faria uma explicação parecer resolvida e poderia direcionar a responsabilidade para fora. O próprio relato da Microsoft identifica um defeito interno e uma lacuna de classificação da mitigação, independentemente da fonte inicial. Mesmo que o primeiro tráfego tenha sido malicioso, o serviço ainda precisava lidar com o modo de falha suportado: menor eficiência de cache seguida de novas tentativas legítimas que seu controle volumétrico não removeu.

O defeito de cache mudou o custo de cada consulta

O cache não é apenas uma otimização de desempenho no DNS autoritativo. Ele pode determinar quanto trabalho uma borda realiza para perguntas repetidas e quanta carga atinge componentes mais profundos do serviço.

A Microsoft afirmou que a eficiência do cache de borda do DNS caiu porque um defeito de código foi exposto por uma sequência específica de eventos. [2][4][5] A frase é informativa, mas incompleta. Ela não diz se as consultas afetadas erraram um cache de respostas, ignoraram um cache negativo, causaram buscas repetidas no backend, disputaram estado compartilhado, invalidaram entradas ou consumiram outro recurso escasso. Ela não identifica se todas as bordas eram vulneráveis ou apenas um subconjunto alcançado por caminhos anycast específicos.

A reconstrução responsável deve evitar preencher esses detalhes. Ainda pode mostrar por que a eficiência importa.

Suponha uma borda simplificada que recebe perguntas repetidas. Com alta taxa de acerto de cache, a maioria das respostas é servida a partir de estado já disponível. O trabalho marginal por consulta permanece relativamente baixo. Se um defeito empurra mais consultas para um caminho mais lento, cada requisição pode consumir mais tempo de CPU, memória, sincronização, trabalho de rede ou capacidade de backend. A latência aumenta. Os clientes esperam mais ou não recebem resposta. Eles tentam novamente. A população de novas tentativas então eleva a taxa de entrada mesmo que o aumento original pare de crescer.

Este é o ciclo de realimentação central sustentado pela narrativa da Microsoft:

Um aumento anômalo de consultas chega ao DNS do Azure.
Uma sequência específica expõe um defeito de eficiência de cache.
Mais requisições exigem tratamento caro ou esperam mais.
A disponibilidade do serviço DNS diminui.
Os clientes tentam novamente as requisições sem resposta.
O sistema volumétrico trata essas novas tentativas como legítimas.
O tráfego de novas tentativas adiciona carga ao serviço já prejudicado.

O ciclo não exige que nenhum cliente se comporte de modo irracional. Uma nova tentativa pode ser individualmente razoável. A falha sistêmica vem do comportamento agregado e da incapacidade do operador de classificar ou modelar esse trabalho com segurança.

A RFC 1034 e a RFC 1035 estabelecem o cache como parte fundamental da operação do DNS. [17][18] A RFC 2308 define cache negativo para que resolvedores não perguntem repetidamente a mesma questão de inexistência sem limite. [19] Padrões posteriores, como a RFC 8020 e a RFC 8198, descrevem formas de reduzir tráfego desnecessário de consultas negativas em condições específicas. [21][22] Nenhum desses documentos prova que o defeito do Azure dizia respeito a respostas negativas. Eles mostram apenas que reutilização de consultas, estado de cache e erros repetidos são variáveis operacionais reconhecidas.

Novas tentativas legítimas ainda podem ser inseguras em conjunto

A admissão mais consequente da Microsoft foi que as novas tentativas de clientes foram consideradas tráfego DNS legítimo e, portanto, não foram descartadas pelos sistemas de mitigação de picos volumétricos. [2][4]

"Legítimo" pode significar várias coisas. Um pacote pode ter uma origem plausível. Uma consulta pode estar em conformidade com o protocolo. Um cliente pode estar autorizado a usar um resolvedor recursivo. Um domínio solicitado pode existir. Nada disso garante que um fluxo agregado ilimitado de novas tentativas seja seguro para um serviço autoritativo prejudicado.

A RFC 4697 documenta comportamento de resolvedores que pode impor carga excessiva de consultas aos servidores autoritativos. Ela descreve padrões em que resolvedores tentam novamente de modo agressivo, consultam vários servidores ou continuam trabalhando quando uma resposta mais disciplinada reduziria a carga. [20] O documento antecede o incidente do Azure em muitos anos. Sua relevância não é que o Azure tenha necessariamente violado um algoritmo prescrito. Ela estabelece que a amplificação por novas tentativas na fronteira resolvedor-autoritativo é uma classe conhecida de falha operacional.

O registro do Azure deixa várias perguntas sem resposta:

Quais clientes ou implementações recursivas tentaram novamente?
As novas tentativas estavam concentradas em componentes de serviço operados pela Microsoft, resolvedores públicos, resolvedores empresariais ou dispositivos de usuários finais?
Qual resposta ou tempo limite acionou a tentativa seguinte?
Os intervalos de novas tentativas eram aleatórios ou sincronizados?
Os clientes alternavam entre endereços anycast ou repetiam na mesma borda alcançada?
Quais classes de consulta geraram o maior custo após o surgimento do defeito de cache?
As novas tentativas válidas se tornaram distinguíveis do aumento inicial por nome, horário, rede de origem ou resposta anterior?

Sem essas medições, "novas tentativas excessivas" é uma categoria útil, mas não um diagnóstico completo.

O desafio da mitigação também é real. Descartar todas as novas tentativas pode prolongar uma indisponibilidade e negar clientes cujo primeiro pacote foi meramente perdido. Permitir todas as novas tentativas pode sustentar a sobrecarga. O operador precisa de admissão limitada: proteger trabalho válido conhecido suficiente para preservar a recuperação, limitando padrões que consomem recursos desproporcionais.

A Microsoft afirmou que atualizou a lógica de mitigação volumétrica imediatamente após o incidente para proteger o serviço DNS contra novas tentativas excessivas. [2][4] Um relato verificável mostraria qual sinal mudou, como a nova regra distingue uma nova tentativa inofensiva de comportamento agregado prejudicial, quais testes de falsos positivos foram executados e como os operadores podem desativar ou ajustar o controle se ele bloquear nomes legítimos.

Serviço autoritativo e resolução recursiva são domínios de controle diferentes

A consulta DNS de um usuário atravessa sistemas operados por partes diferentes.

O resolvedor stub em um dispositivo normalmente pergunta a um resolvedor recursivo. O resolvedor recursivo pode responder a partir do cache. Se não tiver uma resposta utilizável, ele segue delegações e pergunta aos servidores autoritativos da zona relevante. A RFC 1034 e a RFC 1035 definem esses papéis e as trocas de mensagens entre eles. [17][18]

O DNS do Azure operava a camada autoritativa para os domínios afetados hospedados no Azure. Ele controlava a implementação de borda do serviço, o comportamento de cache, a capacidade, a modelagem de tráfego e as respostas autoritativas. Os resolvedores recursivos controlavam o estado em cache, a seleção de servidores, a interpretação de tempos limite e o comportamento de novas tentativas. As aplicações controlavam se e como suas próprias chamadas tentavam novamente após uma falha de resolução de nomes. Redes de acesso e roteamento da internet influenciavam qual borda do Azure uma consulta anycast alcançava.

O mesmo sintoma pode, portanto, ter causas diferentes:

Um resolvedor pode expirar porque a borda autoritativa alcançada está sobrecarregada.
Um caminho pode descartar pacotes mesmo que a borda esteja saudável.
Um resolvedor pode reter um resultado negativo ou um estado de novas tentativas esgotado depois que o serviço autoritativo melhora.
Uma aplicação pode transformar uma falha de resolvedor em muitas novas tentativas paralelas.
Uma página de status pode ser, ela mesma, difícil de alcançar porque seu nome de host depende da camada prejudicada.

A RFC 8906 explica que um servidor autoritativo sem resposta pode ser indistinguível da perda de pacotes do ponto de vista do resolvedor. [16] Essa ambiguidade afeta tanto o comportamento automatizado quanto a comunicação do incidente. Um resolvedor pode razoavelmente tentar outro endereço autoritativo, mas muitos resolvedores tomando a mesma decisão podem mover ou multiplicar a carga.

A responsabilização não deve achatar esses papéis. O Azure não pode controlar todos os algoritmos de clientes. Os operadores de resolvedores não podem consertar o código de cache do Azure. Os clientes não podem inspecionar a telemetria interna da borda. Mas o Azure controlava a fronteira do serviço que aceitava consultas e a lógica de mitigação que classificava o tráfego de novas tentativas. Isso lhe confere a responsabilidade primária de demonstrar que o serviço autoritativo podia degradar sem transformar comportamento válido de recuperação em sobrecarga sustentada.

Anycast distribui consultas, mas não torna todas as bordas equivalentes

A documentação atual da Microsoft afirma que o DNS do Azure usa uma rede global de servidores de nomes e anycast para direcionar cada consulta a um servidor DNS disponível próximo. [7] A orientação de anycast do Windows Server da Microsoft explica o padrão geral: vários locais anunciam o mesmo endereço de serviço e o roteamento seleciona um caminho. [9]

Esses documentos descrevem a arquitetura atual e a prática geral. Eles não provam a topologia exata de 2021, a política de rotas nem o comportamento de retirada. Essa fronteira temporal deve permanecer explícita.

A RFC 9199 explica por que grandes serviços autoritativos costumam usar múltiplos servidores, anycast e balanceamento de carga. Ela também alerta contra assumir um único modelo universal de implantação. A localização dos resolvedores, o roteamento, o peering e a forma do catchment afetam qual instância recebe o tráfego. [14]

Durante um aumento de consultas, o anycast pode distribuir a carga. Também pode produzir experiência desigual:

um catchment pode receber uma parcela maior de uma carga direcionada;
mudanças de rota podem mover consultas hostis e legítimas para outra borda;
um nó pode permanecer alcançável enquanto sua camada de aplicação está sobrecarregada;
a retirada pode proteger um local enquanto concentra tráfego em outro;
resolvedores recursivos em redes diferentes podem alcançar bordas diferentes e relatar disponibilidade diferente.

A RCA pública da Microsoft não revela se o defeito de cache afetou todas as bordas, se as rotas mudaram, se os recursos resilientes de DNS significaram movimento de catchment ou se alguns servidores tiveram melhor eficiência de cache do que outros. [1][2]

A frase "tráfego redirecionado para nossos recursos resilientes de DNS" apareceu em relatórios de status contemporâneos. [3] Ela é ampla demais para estabelecer o que mudou. Um relato técnico confiável conectaria a frase a evidências:

quais rotas ou endpoints de serviço mudaram;
quais catchments se moveram;
se o estado de cache se moveu ou foi aquecido;
como as taxas de resposta e tempo limite mudaram em cada etapa;
se a mudança reduziu o volume de novas tentativas;
quais sondas externas confirmaram a recuperação.

Anycast é infraestrutura, não absolvição. Seu valor é medido pela continuidade observada sob a carga real de trabalho.

Servir dados obsoletos é uma opção, não uma cura presumida

Quando servidores autoritativos não conseguem responder, um resolvedor recursivo pode ter uma cópia expirada de uma resposta anteriormente válida. A RFC 8767 define um método limitado para servir dados obsoletos a fim de melhorar a resiliência sob condições especificadas. [15]

Esse mecanismo é relevante para continuidade, mas não deve ser importado para o incidente como um controle ausente. As fontes públicas não dizem quais resolvedores mantinham respostas obsoletas, quais registros eram estáveis o suficiente para servir, se as respostas haviam expirado ou se o serviço de dados obsoletos estava habilitado.

Servir dados obsoletos envolve compensações:

Pode manter um nome de serviço estável alcançável durante uma falha autoritativa curta.
Pode preservar um endereço que o operador precisa alterar com urgência.
Pode mascarar a deterioração autoritativa contínua para alguns usuários.
Não ajuda uma consulta inicial sem resposta em cache.
Não repara a borda autoritativa nem reduz todas as classes de consulta.
Sua utilidade depende do estado de cache anterior e dos limites configurados.

O cache negativo tem limites semelhantes. A RFC 2308 reduz consultas repetidas para respostas negativas conhecidas. A RFC 8020 permite que um resolvedor pare abaixo de um ramo NXDOMAIN validado. A RFC 8198 permite o uso agressivo de registros de negação autenticados por DNSSEC para sintetizar respostas negativas adicionais. [19][21][22]

Esses mecanismos podem reduzir trabalho upstream desnecessário. Eles não provam que o aumento do Azure consistiu em nomes inexistentes aleatórios nem que o defeito exposto envolvia cache negativo. Também não podem ser recomendados com segurança sem conhecer a distribuição de consultas e o estado de DNSSEC.

A questão orientada por evidências não é "Por que todos os resolvedores falharam em servir dados obsoletos?" É:

Quais nomes afetados tinham respostas em cache utilizáveis?
Quanto tráfego de novas tentativas veio de estados de cache frios, positivos, negativos ou expirados?
Qual comportamento de resiliência reduziu o trabalho autoritativo sem preservar estado obsoleto inseguro?
Qual comportamento de aplicação ocorreu quando os resolvedores devolveram respostas obsoletas, com falha ou atrasadas?

Essas medições transformariam uma discussão geral de padrões em uma decisão de controle específica do incidente.

A concentração de dependências fez uma falha de DNS parecer muitas falhas de serviço

O incidente ficou visível por meio do Azure, Dynamics, Xbox Live e outros serviços da Microsoft porque a resolução de nomes estava abaixo de vários caminhos de serviço. O aviso de perguntas e respostas da Microsoft nomeou Azure, Dynamics e Xbox Live. [1] A Exoprise reproduziu uma comunicação do Microsoft 365 que listava o Teams e um conjunto mais amplo de produtos dependentes. [2] O The Register e o TechCrunch descreveram, de forma independente, reclamações generalizadas de acesso nas propriedades da Microsoft. [3][6]

As evidências não mostram que todas as aplicações subjacentes falharam. Um usuário que não consegue resolver um nome de serviço experimenta um serviço indisponível mesmo que computação, armazenamento e processos de aplicação permaneçam saudáveis. Essa distinção importa tanto para o diagnóstico quanto para a recuperação.

O DNS faz parte da identidade de rede. Ele mapeia nomes usados por usuários e software para endpoints alcançáveis. Um registro pode permanecer armazenado corretamente enquanto o serviço que responde por ele fica indisponível. O usuário não vê benefício prático do registro correto se nenhuma resposta chega.

A dependência compartilhada cria várias questões de responsabilização:

Os caminhos de status público, suporte, gerenciamento e autenticação dependiam da mesma camada de DNS autoritativo?
Os responsáveis internos conseguiam alcançar as ferramentas necessárias para diagnosticar e comunicar?
Quais equipes de serviço monitoravam o DNS de forma independente, fora da rede da Microsoft?
Quais proprietários de serviço sabiam que seus nomes compartilhavam uma única implementação de cache de borda?
Havia caminhos estáticos de comunicação de emergência fora do namespace afetado?
A recuperação do serviço dependia da expiração ou atualização dos caches dos resolvedores após a recuperação autoritativa?

A Exoprise relatou dificuldade com as páginas de status do Azure durante o evento e descreveu a Microsoft direcionando usuários para superfícies de status alternativas. [2] Esse relato deve ser tratado como uma observação independente, não como prova de que todos os endpoints de status falharam pelo mesmo motivo. Ainda assim, expõe uma questão de governança: um canal de comunicação de incidente não deve compartilhar uma dependência não examinada com o serviço sobre o qual ele informa.

O reparo não é necessariamente um segundo provedor de DNS para cada nome. Ele começa com um grafo de dependências preciso e observação independente. Os proprietários de serviços da Microsoft precisam saber quais nomes, caminhos autoritativos, resolvedores recursivos e ações de plano de controle permanecem comuns.

O monitoramento detectou degradação, mas detecção não é contenção

A Microsoft afirmou que a menor disponibilidade do serviço acionou sistemas de monitoramento e mobilizou engenheiros. [2] A Exoprise afirmou que seu monitor externo alertou por volta das 21:20, próximo ao início posterior da janela DNS do provedor, às 21:21. [2]

Esse horário sugere que a detecção não era o único problema. O serviço se recuperou automaticamente às 22:00, mas a Microsoft reconheceu que a duração excedeu sua meta de projeto. A questão relevante passa a ser o que os operadores podiam fazer após a detecção.

Um sistema de detecção útil deve separar pelo menos estes sinais:

taxa de consultas recebidas;
taxa de acerto e erro de cache por classe de consulta;
custo por requisição respondida ou com falha;
profundidade de fila e saturação do servidor;
taxa de respostas válidas;
taxa de tempo limite e erro de resolvedores externos;
volume de novas tentativas e distribuição de origem das novas tentativas;
movimento de catchment anycast;
sucesso de resolução de nomes específico por serviço.

Um alarme agregado de tráfego pode não perceber uma mudança no trabalho por consulta. Um defeito de cache pode transformar uma taxa de consultas familiar em um problema de capacidade. Um alarme de disponibilidade pode disparar somente depois que os usuários já estão falhando. Um detector volumétrico pode classificar novas tentativas como válidas enquanto seu efeito agregado impede a recuperação.

O relato público afirma que os engenheiros prepararam capacidade adicional de atendimento e a capacidade de responder consultas DNS a partir do sistema de mitigação volumétrica, caso novas ações fossem necessárias. [2] Ele não diz se alguma dessas etapas foi de fato aplicada antes da recuperação automática, qual limite a teria acionado ou se a capacidade teria rompido o ciclo de realimentação.

Esta é uma distinção de controle:

Detecção responde se algo está errado.
Diagnóstico identifica o mecanismo.
Contenção limita a realimentação prejudicial.
Recuperação restaura a resolução válida.
Verificação mostra que usuários externos e serviços dependentes se recuperaram.

Um alarme rápido não desculpa contenção fraca. Nem a recuperação automática prova que o serviço poderia se recuperar de forma confiável de um aumento mais longo ou repetido.

A recuperação excedeu a meta de projeto

A declaração da Microsoft de que a recuperação excedeu sua meta de projeto é incomumente útil porque revela um padrão interno sem divulgar a meta numérica. [2][5]

A declaração levanta quatro perguntas.

Primeiro, o que a meta de projeto media? Podia se referir à disponibilidade de respostas autoritativas, ao tempo para recuperação automática, ao tempo para intervenção do operador ou à restauração completa do serviço de ponta a ponta. Essas coisas não são intercambiáveis.

Segundo, qual mecanismo deveria alcançá-la? Um cache pode se recuperar à medida que a carga diminui. Um local anycast pode se retirar. Capacidade pode ser adicionada. Uma regra de mitigação pode mudar. Sem um responsável pelo controle e um gatilho, "meta de projeto" permanece uma aspiração.

Terceiro, a meta foi testada contra uma falha combinada? Um teste de carga normal pode medir capacidade de consulta com eficiência de cache saudável. Um teste de cache pode não incluir novas tentativas sincronizadas. Um teste de mitigação volumétrica pode modelar pacotes hostis, mas permitir novas tentativas válidas sem limite. O evento de 2021 uniu essas condições.

Quarto, como o reparo foi validado? A Microsoft listou o reparo do defeito de código para que as requisições pudessem ser tratadas com eficiência no cache e a melhoria da detecção e mitigação automáticas de tráfego anômalo. [2][4] Uma lista de itens de trabalho não é evidência de conclusão.

O encerramento apropriado vincularia cada medida a um teste:

Medida	Evidência exigida
Reparo do defeito de cache	Teste de reprodução da sequência desencadeadora, eficiência de cache antes e depois, identificadores de código e implantação
Proteção contra novas tentativas	Carga controlada de novas tentativas, preservação de respostas legítimas, taxa de falsos positivos, limite de reversão
Detecção de anomalias	Latência de detecção entre classes de consulta, sensibilidade e evidência de falsos alarmes
Capacidade de borda	Margem de saturação por borda sob eficiência de cache degradada
Recuperação automática	Execuções repetidas de injeção de falhas e distribuição de tempo até a recuperação
Recuperação de serviço	Sondas externas para nomes representativos da Microsoft e de clientes em redes de resolvedores

Sem essas evidências, os leitores podem saber o que a Microsoft pretendia melhorar, mas não quanto risco foi removido.

O SLA não substitui evidências de incidente

O Azure publica um SLA para zonas de DNS. O documento atual define disponibilidade de serviço e possíveis créditos de serviço sob condições contratuais especificadas. [13] Ele é útil para identificar a fronteira jurídica e comercial hoje.

Ele não estabelece quais contratos de 2021 se aplicavam, se um cliente específico atendeu às condições de reclamação, se o tempo de inatividade medido ultrapassou um limite ou se a Microsoft tinha responsabilidade legal. As fontes públicas neste pacote não contêm reclamações específicas de clientes, decisão de regulador ou decisão judicial.

Um SLA também pode medir um objeto mais estreito do que o dano ao cliente. Um cálculo de disponibilidade de DNS pode não capturar recuperação atrasada de aplicações, acesso à página de status, trabalho operacional ou transações perdidas porque um resolvedor não conseguiu obter uma resposta. Por outro lado, um relato de dificuldade de serviço por um cliente não prova automaticamente violação de SLA.

O registro de responsabilização deve, portanto, manter três livros separados:

Disponibilidade técnica: o que os sistemas autoritativos e recursivos devolveram.
Impacto no cliente: quais funções falharam, para quem e por quanto tempo.
Reparação contratual: quais termos, medições e procedimentos de reclamação se aplicaram.

Misturá-los exagera a responsabilidade ou minimiza o dano. Os limites, portanto, importam mais do que escolher uma medida como todo o incidente.

Os clientes controlavam a arquitetura, não o defeito do Azure

A orientação atual de confiabilidade do Azure descreve responsabilidades do provedor e do cliente. O Azure opera a plataforma de DNS, enquanto os clientes configuram zonas, registros, delegação e algumas escolhas de resiliência. [8][12]

Os clientes podem tomar medidas úteis:

monitorar nomes críticos a partir de resolvedores e redes fora do Azure;
inventariar quais caminhos de controle e de usuário dependem de zonas hospedadas no Azure;
escolher TTLs deliberadamente;
testar o comportamento da aplicação quando a resolução falha;
preservar caminhos de acesso e comunicação de emergência;
avaliar diversidade de provedor autoritativo para sistemas que justifiquem sua complexidade;
entender operações de DNSSEC e delegação se as utilizarem.

Esses controles não transferem a responsabilidade pelo defeito de cache do Azure aos clientes. Um cliente não pode inspecionar a implementação de borda, mudar a classificação volumétrica ou adicionar capacidade do provedor. Também não se deve dizer que uma única arquitetura é universalmente correta.

DNS autoritativo com múltiplos provedores pode reduzir um modo comum, mas adiciona riscos de sincronização de zona, delegação, DNSSEC, controle de acesso e failover. A RFC 9199 enfatiza o contexto em vez de um projeto obrigatório. [14] Um segundo provedor que compartilha roteamento, acesso ao registrador, automação ou equipe operacional pode não ser independente nas dimensões que importam.

A decisão relevante do cliente é uma aceitação de risco documentada:

Quais falhas de resolução de nomes o serviço deve sobreviver?
Quais domínios de falha são realmente independentes?
Com que rapidez o estado de delegação ou do provedor pode mudar?
Que estado obsoleto ou conflitante um failover poderia criar?
Quem tem autoridade para executar e reverter a mudança?
Que teste comprova que o caminho funciona a partir de redes reais de usuários?

A resiliência do cliente é uma camada de defesa. Não é desculpa para um operador de infraestrutura deixar seu próprio defeito e comportamento de mitigação sem medição.

A responsabilidade acompanha o controle e o acesso às evidências

O registro público sustenta uma alocação baseada em controle.

Engenharia do DNS do Azure

A engenharia do DNS do Azure controlava o serviço autoritativo, a implementação do cache, a implantação da borda, a modelagem de tráfego, a lógica de mitigação volumétrica e a automação de recuperação. Ela tinha o melhor acesso às distribuições de consultas, métricas de cache e estado dos servidores. Seu dever não era impedir todo aumento de consultas. Era projetar e testar o comportamento de degradação para que um defeito de cache não permitisse que novas tentativas válidas sustentassem a sobrecarga, e reter evidências mostrando o que aconteceu.

Gerenciamento de incidentes da Microsoft

O gerenciamento de incidentes controlava escalonamento, coordenação e comunicação pública. A diferença entre a atualização preliminar de "pico" e o relato posterior do defeito de cache é razoável durante a investigação, desde que o registro mostre o que mudou. Ele deve preservar uma sequência com carimbo de tempo de hipóteses, evidências e ações corretivas, em vez de apresentar a narrativa final como se fosse conhecida desde o início.

Proprietários de serviços da Microsoft

As equipes que executam Azure, Dynamics, Xbox Live, Microsoft 365 e superfícies de controle relacionadas controlavam o projeto de dependências e o monitoramento externo. Elas não controlavam o defeito de DNS, mas podiam identificar se nomes críticos, páginas de status e ferramentas de recuperação compartilhavam o mesmo caminho autoritativo.

Operadores de resolvedores recursivos e clientes

Desenvolvedores de resolvedores e clientes controlavam intervalos de novas tentativas, comportamento de cache e tratamento de falhas. A RFC 4697 mostra por que a disciplina de novas tentativas é uma responsabilidade compartilhada reconhecida há muito tempo. [20] O registro não identifica quais implementações geraram a maior parte do tráfego, portanto nenhum operador específico deve ser acusado. Uma post-mortem completa forneceria distribuições agregadas que permitissem ao ecossistema reparar padrões prejudiciais.

Clientes

Os clientes controlavam algumas escolhas de zona, TTL, monitoramento e diversidade de provedores. Sua responsabilidade depende da criticidade do serviço, das opções contratuais disponíveis e da viabilidade de DNS independente. Eles não possuíam as informações nem a autoridade necessárias para corrigir o cache de borda ou o classificador de mitigação do Azure.

Essa alocação é assimétrica porque controle e evidências eram assimétricos. O Azure detinha as evidências operacionais centrais e os meios para mudar o serviço com falha.

Contrafactuais mostram quais controles importam

A análise contrafactual ajuda a separar o gatilho, as condições contribuintes e o reparo.

Se o aumento anômalo tivesse ocorrido sem o defeito de cache

A Microsoft afirmou que caches normais e modelagem de tráfego atenuariam o aumento. [2][4] Se essa afirmação for correta, o serviço deveria ter mantido maior eficiência de cache e menor trabalho por consulta. Isso torna o defeito uma condição contribuinte ou candidato a causa raiz, não apenas um bug de fundo.

Se o defeito de cache tivesse aparecido sem um aumento

O serviço poderia ter capacidade ociosa suficiente para absorver a eficiência reduzida. Isso tornaria o aumento uma condição desencadeadora. O registro público não revela a margem, portanto a interação é mais defensável do que atribuir um único fator como toda a causa raiz.

Se as novas tentativas tivessem sido limitadas imediatamente

O ciclo de realimentação poderia ter enfraquecido. Mas um filtro de novas tentativas amplo demais poderia ter negado tráfego legítimo de recuperação. O controle correto precisaria preservar requisições válidas representativas e demonstrar baixa taxa de falsos positivos.

Se todos os resolvedores servissem respostas obsoletas

Alguns nomes estáveis poderiam ter permanecido alcançáveis, enquanto usuários com cache frio e registros alterados ainda falhariam. Servir dados obsoletos universalmente também poderia preservar estado inseguro. Este não é um reparo contrafactual completo.

Se os clientes usassem dois provedores autoritativos

Alguns nomes poderiam ter mantido um caminho independente, desde que delegação, dados de zona, DNSSEC e política de saúde fossem coordenados. Outras dependências compartilhadas ou comportamentos de resolvedores ainda poderiam falhar. Diversidade é arquitetura testável, não um slogan.

Se houvesse mais capacidade de borda disponível

Capacidade poderia ter atrasado a saturação. Ela não removeria necessariamente o defeito de cache nem classificaria novas tentativas. Um sistema maior com o mesmo ciclo de realimentação pode falhar mais tarde e em escala maior.

Esses contrafactuais sustentam uma conclusão em camadas: o aumento inicial desencadeou o evento; o defeito de cache aumentou o trabalho por consulta; o comportamento de novas tentativas ampliou a carga; a classificação da mitigação falhou em romper o ciclo; a concentração de dependências propagou o impacto; e os controles de recuperação levaram mais tempo do que a meta de projeto do provedor.

O que as evidências públicas ainda não podem provar

As fontes estabelecem um esboço útil, mas deixam o registro interno decisivo indisponível.

Elas não estabelecem:

a fonte, a intenção ou a propriedade do aumento inicial de consultas;
se o aumento foi um ataque coordenado;
volume de consultas, taxa de pacotes ou distribuição de tipos de consulta;
os domínios e registros visados;
a implementação de cache ou o caminho de código que falhou;
taxas de acerto de cache antes, durante e depois do incidente;
o número ou a localização das bordas de DNS afetadas;
mudanças de rota ou de catchment anycast;
quais resolvedores recursivos ou clientes produziram novas tentativas;
intervalos de novas tentativas, sincronização ou fator de amplificação;
a regra exata de mitigação volumétrica antes e depois do reparo;
impacto por serviço e por região;
perdas de clientes, créditos de SLA ou responsabilidade legal;
a data de conclusão e a validação independente da remediação;
se a mesma sequência desencadeadora foi testada desde então.

A documentação atual da Microsoft não pode preencher essas lacunas históricas. Ela descreve o serviço de hoje e as práticas recomendadas. [7]-[13] As RFCs definem comportamento de protocolo e opções operacionais. [14]-[22] Relatórios independentes preservam declarações e sintomas, mas não têm a telemetria interna do Azure. [2]-[6]

A ausência de detalhes públicos não prova ocultação nem negligência. Ela limita a confiança em qualquer conclusão causal ou legal. A constatação mais forte é que o próprio relato da Microsoft identifica um defeito interno de cache, um ciclo de realimentação de novas tentativas legítimas e uma lacuna de mitigação. A distribuição precisa da responsabilidade além do serviço controlado pela Microsoft permanece parcialmente desconhecida.

Um reparo deve ser auditável como sequência

Um programa de remediação verificável preservaria um teste comum de incidente, em vez de uma lista de melhorias desconectadas.

Reproduzir

Criar uma carga de trabalho segura correspondente à sequência relevante de consultas e estado de cache. Registrar a versão do software, o formato da zona, os tipos de registro, o estado do cache e a topologia da borda. Provar que o sistema anterior à correção exibe o declínio de eficiência.

Medir

Capturar taxas de acerto e erro de cache, custo por consulta, latência de resposta, taxa de tempo limite, profundidade de fila, saturação de borda e volume de novas tentativas. Separar o tráfego inicial das novas tentativas quando as evidências permitirem.

Conter

Aplicar modelagem limitada de novas tentativas e controles de tráfego anômalo. Testar nomes de validade conhecida, estados de cache frios e quentes, respostas negativas, respostas DNSSEC e múltiplos comportamentos de resolvedores. Medir falsos positivos.

Recuperar

Demonstrar que a disponibilidade autoritativa retorna dentro da meta de projeto sem esperar apenas pela queda do tráfego externo. Confirmar o comportamento de anycast e rotas em redes independentes.

Verificar serviços dependentes

Sondar nomes representativos do Azure, do plano de controle da Microsoft e de clientes a partir de vários resolvedores recursivos e redes de acesso. Distinguir recuperação de DNS de recuperação de aplicação.

Reverter

Mostrar que os controles de emergência têm responsáveis, condições de expiração e configuração reversível. Uma mitigação que permanece indefinidamente pode se tornar uma nova fonte de negação.

Reter evidências

Vincular os resultados dos testes a identificadores de código, implantação e configuração. Publicar um resumo limitado com medições suficientes para mostrar que o ciclo de realimentação específico foi removido sem expor detalhes sensíveis da infraestrutura.

Essa sequência responde à pergunta central: não se a Microsoft adicionou "mais resiliência", mas se a mesma interação entre cache e novas tentativas ainda pode ultrapassar o limite de falha.

Conclusão

A indisponibilidade do DNS do Azure de abril de 2021 não foi explicada apenas pelo volume de tráfego.

A Microsoft afirmou que um aumento anômalo de consultas expôs um defeito de código que reduziu a eficiência do cache de borda do DNS. O serviço degradado fez os clientes tentarem novamente. Essas novas tentativas eram tráfego legítimo, portanto a mitigação volumétrica inicialmente não as descartou. O serviço se recuperou automaticamente, mas não dentro da meta de projeto. A Microsoft então mudou a proteção contra novas tentativas e afirmou que repararia o defeito de cache e melhoraria a detecção de anomalias. [2][4][5]

Essa sequência identifica um problema de responsabilização de infraestrutura de rede com várias camadas:

O aumento foi o gatilho descrito pela Microsoft, não uma atribuição comprovada de ataque.
O defeito de cache foi uma condição contribuinte interna que aumentou o trabalho.
O comportamento legítimo de novas tentativas ampliou a carga na fronteira resolvedor-autoritativo.
A lógica de mitigação inicialmente não conteve esse tráfego válido agregado.
A dependência compartilhada de DNS transformou uma falha de resolução em muitas indisponibilidades aparentes de serviço.
As métricas de recuperação não se alinharam claramente com a experiência de cada usuário.

A conclusão responsável não é que novas tentativas de DNS sejam ruins, que o anycast tenha falhado ou que os clientes devam sempre usar um segundo provedor. Cada afirmação ultrapassaria as evidências.

O padrão mais forte é o comportamento de degradação mensurável. Um operador de DNS autoritativo deve saber como a eficiência do cache muda sob sequências incomuns de consultas, como novas tentativas legítimas afetam a capacidade, qual mitigação protege respostas válidas, como os catchments anycast respondem e quais sondas externas comprovam a recuperação. Operadores de resolvedores e clientes devem limitar novas tentativas e comportamento de cache. Proprietários de serviços devem identificar dependências críticas de nomes e preservar comunicação independente de incidentes.

Os clientes devem testar as decisões de continuidade que realmente podem controlar.

Registros, descrições de serviço e avisos de status fazem parte das evidências. Eles não são o serviço em execução. Em 1º de abril de 2021, nomes podiam permanecer configurados corretamente enquanto os usuários não conseguiam resolvê-los de forma confiável. A responsabilização começa onde esses dois estados divergem.

A prova final é um teste repetível vinculado ao reparo real: recriar a sequência, medir a eficiência do cache, induzir novas tentativas limitadas, ativar a mitigação, preservar respostas de validade conhecida, recuperar dentro da meta de projeto e confirmar os resultados a partir de redes independentes. Sem essas evidências, o público tem uma narrativa plausível. Com elas, os operadores podem mostrar que o ciclo de realimentação foi fechado.