- Em 8 de janeiro de 2026, uma atualização do serviço 1.1.1.1 da Cloudflare mudou a ordem dos registros nas respostas DNS, causando falhas de resolução DNS para alguns usuários no mundo todo
- A causa do problema foi uma mudança de código que moveu os registros CNAME para depois dos registros A/AAAA, porque algumas implementações de clientes DNS dependiam da ordem
- Em especial, a função
getaddrinfo da glibc e o processo DNSC de switches Cisco foram afetados; no segundo caso, houve até loop de reinicialização
- A RFC 1034 apenas afirma que um CNAME pode “vir antes” (
possibly preface), então não existe um padrão claro para a ordem dos registros
- A Cloudflare voltou a sempre posicionar o CNAME primeiro e enviou ao IETF um Internet-Draft para definir um padrão mais claro
1. Visão geral do incidente
- Em 8 de janeiro de 2026, foi distribuída uma atualização para reduzir o uso de memória do 1.1.1.1, o que alterou a ordem dos registros nas respostas DNS
- A mudança entrou no codebase em 2 de dezembro de 2025, foi implantada no ambiente de testes em 10 de dezembro e teve início de rollout global em 7 de janeiro de 2026
- Em 8 de janeiro, às 18:19 UTC, o incidente foi declarado; às 18:27 começou o rollback; às 19:55 a recuperação foi concluída
- A maioria dos clientes DNS modernos ignora a ordem dos registros na resposta, mas algumas implementações assumem que o CNAME sempre deve vir primeiro
- Quando essa ordem mudou, alguns clientes trataram a resposta como vazia, causando falha na resolução
2. Cadeia de CNAME e funcionamento do cache
- Em uma consulta de domínio, por exemplo,
www.example.com pode ser resolvido até o IP final passando por várias cadeias de CNAME
- Exemplo:
www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
- Cada elo do CNAME possui um TTL (Time-To-Live), e apenas parte da cadeia pode expirar
- O 1.1.1.1 reconsulta apenas a parte expirada e monta a resposta mesclando o cache existente com os novos registros
3. Detalhes da mudança de código
- No código antigo, a cadeia de CNAME era inserida primeiro, e depois os registros A/AAAA eram adicionados
answer_rrs.extend_from_slice(&self.records); // CNAMEs first
- No código alterado, o CNAME passou a ser adicionado por último
entry.answer.extend(self.records); // CNAMEs last
- Com isso, o CNAME foi movido para o final da resposta, e alguns clientes não conseguiram processá-lo
4. Exemplos de implementações afetadas
- A função
getaddrinfo da glibc faz o parsing da resposta em sequência e precisa que o CNAME apareça primeiro para conseguir seguir para o nome seguinte
- Se o CNAME vier depois, o “nome esperado” não é atualizado e o resultado fica vazio
- O processo DNSC de três modelos de switches Cisco Catalyst também foi afetado e, ao usar o 1.1.1.1, entrou em loop de reinicialização por erro fatal
- A Cisco publicou um documento de serviço relacionado
5. Implementações não afetadas
- O systemd-resolved faz o parsing da resposta em uma estrutura OrderedSet, o que permite percorrer o conjunto completo independentemente da posição do CNAME
- Por isso, continuou funcionando normalmente mesmo com a mudança na ordem dos registros
6. A ambiguidade da RFC 1034
- A RFC 1034 (1987) diz que a resposta pode ser prefaciada por um ou mais CNAMEs
- Porém, como não há palavras normativas como MUST/SHOULD, isso não constitui um requisito explícito
- Só após a RFC 2119 (1997) essas palavras-chave foram padronizadas, então o documento da época não expressa obrigações de forma clara
- A Cloudflare posicionava os CNAMEs primeiro em sua implementação inicial, mas não garantia isso por testes
7. Diferença entre RRset e seções da mensagem
- A RFC 1034 §3.6 afirma que a ordem dentro de um RRset (conjunto de registros com mesmo nome, tipo e classe) não é importante
- Porém, não menciona a ordem entre RRsets diferentes
- O exemplo da §6.2.1 também trata apenas de dois registros A com o mesmo nome, sem abordar a ordem relativa entre CNAME e A
- Portanto, a definição da ordem entre registros CNAME e A permanece em aberto
8. Problema da ordem dentro da cadeia de CNAME
- Quando há vários níveis de CNAME, mesmo que a ordem interna da cadeia fique embaralhada, o parsing sequencial falha
- Exemplo: se
cdn.example.com CNAME server.cdn-provider.com vier primeiro, não será possível encontrar www.example.com CNAME cdn.example.com
- A RFC 1034 também não define requisitos para a ordem dentro da cadeia de CNAME
9. Critério de funcionamento do resolvedor
- A RFC 1034 §5.2.2 especifica que, ao encontrar um CNAME, o resolvedor deve reiniciar a consulta com o novo nome
- Porém, isso descreve o comportamento do resolvedor completo (por exemplo, o 1.1.1.1),
enquanto resolvedores stub como a glibc não implementam essa lógica
- Como resultado, alguns resolvedores stub não seguem o comportamento esperado pela RFC
10. Comparação com a regra explícita do DNSSEC
- A RFC 4035 (DNSSEC) define com MUST a prioridade de inclusão de registros RRSIG
- Ainda assim, isso trata da inclusão, não da ordem
- O DNSSEC oferece regras claras de inclusão, mas em zonas não assinadas (Unsigned zones) a ambiguidade da RFC 1034 continua
11. Conclusões e medidas da Cloudflare
- Embora pela RFC a ordem do CNAME não seja obrigatória, alguns clientes partem dessa premissa, então a Cloudflare
voltou à política de sempre posicionar o CNAME primeiro
- Para evitar o mesmo problema no futuro, a empresa enviou um Internet-Draft ao IETF
- Com esse incidente, a Cloudflare confirmou que a ambiguidade de um protocolo com 40 anos de idade ainda impacta a operação prática
12. Informações adicionais
- A Cloudflare, por meio da Connectivity Cloud, incluindo o 1.1.1.1, oferece
proteção de redes corporativas, aceleração de aplicações em escala de internet, defesa contra DDoS e suporte à implementação de Zero Trust
- Com o app gratuito 1.1.1.1, é possível obter acesso à internet mais rápido e mais seguro
1 comentários
Comentários do Hacker News
Eu sinto que a redação da RFC não é tão ambígua assim
A expressão “possibly preface” pode ser lida como “se houver um registro CNAME, coloque-o antes”, e não como “se quiser, pode colocá-lo em qualquer lugar”
Mas a questão principal não é só interpretação de texto, e sim o fato de que a equipe que opera um dos servidores DNS mais importantes do mundo mudou a lógica de resposta de CNAME
Isso certamente deve ter quebrado nos testes, e é surpreendente que ninguém tenha perguntado “essa ordem importa?”
A Cloudflare tem sido transparente ao divulgar problemas recentemente, mas neste caso soa mais como “um fato curioso para compartilhar”
O fato de algo assim ter passado pelos testes em um sistema de grande escala parece um erro bem sério
Como o exemplo pode ser generalizado, há margem para interpretar isso como “a ordem não importa em nenhum caso”
No fim, o que para uma pessoa é “entendimento claro” para outra pode parecer “você leu a documentação inteira?”
Esse caso mostra a importância de uma linguagem normativa (normative language)
A discussão relacionada pode ser vista na lista de e-mails da IETF
A frase “diferenças de ordem não são significativas” se aplica apenas àquele exemplo específico, e não significa ignorar a regra geral
Dizem que a RFC 1034 definiu RRset, mas na prática esse termo não é definido ali
A interpretação da Cloudflare parece ter sido confundir uma exceção com a regra geral
Ainda assim, como não há uma regra explícita sobre a ordem da cadeia de CNAME, continua existindo um pouco de ambiguidade nessa parte
Parece um caso em que a Lei de Hyrum e a Lei de Postel atuaram ao mesmo tempo
O resultado de um conflito entre “se usuários suficientes usam uma API, alguém vai depender de todo comportamento observável do sistema” e o princípio de “seja conservador no que envia e liberal no que aceita”
Aqui o ponto foi que o resolver da glibc quebrou — não é uma situação rara de forma alguma
A verdadeira notícia é que a Cloudflare não testou isso direito
Esse bug me fez lembrar de algo antigo
Foi quando, em 2011, a Cloudflare ignorou a RFC e permitiu CNAME no apex do domínio
No post do blog da época eles diziam algo como “vamos ignorar a RFC e resolver o problema do mundo real”
Mas CNAME é um conceito de alias no nível do nome, então colocá-lo no apex quebra o cache de NS, MX e SOA
Muitos engenheiros alertaram na época, mas a postura era “move fast and break things”
Ainda assim, desta vez é possível ver evolução ao tratar com mais cuidado a ordem entre a cadeia de CNAME e o registro A
O conceito de CNAME e alias causa confusão há muito tempo, e a linguagem não normativa da RFC1034 aumentou essa confusão
Esse é o resultado acumulado dessas ambiguidades, mas continua difícil aceitar que um grande provedor de serviço tenha cometido esse tipo de erro
Eu diria que o problema era a própria especificação
É surpreendente que a busca DNS comum da glibc dependa da ordem dos registros
Impressiona que isso não tenha causado grandes problemas por mais de 20 anos
Provavelmente a maioria dos operadores de DNS aprendeu empiricamente nos testes que a ordem importava
Só ganhou atenção agora porque, no caso da Cloudflare, afetou centenas de milhões de dispositivos no mundo inteiro
Ainda assim, fico curioso se a Cloudflare enviou algum patch para resolvers open source como a glibc
CNAME é realmente algo muito chato de lidar (veja as notas do DJB)
Como resolvers simples como o da glibc não têm cache, implementar isso exigiria grandes mudanças de código
A alegação da Cloudflare de que “a RFC não exige ordem para CNAME” soa como jogo de palavras jurídico
Só porque não há “MUST” não significa que “qualquer ordem serve”
Admitir o erro e seguir em frente tornaria o mundo melhor
Escapar da responsabilidade por meio de disputa de linguagem acaba minando a confiança
A Cloudflare parece não ter entendido corretamente a RFC1034
A interface DNS deles bloqueia A e AAAA quando há CNAME, mas permite outros registros
Isso causa resultados dependentes de cache quando CNAME e TXT coexistem
O internet.nl também encontrou esse problema
Alguns usuários configuraram isso seguindo o guia do mxtoolbox, mas isso entra em conflito com a RFC1034
Uma sobre “como delegar um serviço DMARC com CNAME”, outra sobre “como hospedar diretamente”
Parece que a captura de tela gerou confusão
É razoável que a Cloudflare tenha chegado à conclusão de que “o CNAME deve vir antes dos outros registros”
Ao gerenciar DNS na empresa, senti na prática várias limitações do DNS
Especialmente quando ocorre SERVFAIL, o cliente não consegue distinguir qual servidor está com problema
Como resultado, vários servidores DNS e camadas de cache geram uma tempestade de tentativas desnecessárias
Além disso, o search path repete consultas NXDOMAIN para domínios errados
Segundo a seção 7.1 da RFC2308, é permitido fazer cache de respostas SERVFAIL
É um padrão antigo, mas continua sendo uma abordagem válida
A Cloudflare frequentemente quebra padrões e depois justifica isso escrevendo uma nova RFC
Casos como a RFC 8482 me parecem uma vergonha para o setor
A frase “desta vez também enviamos um novo Internet-Draft para evitar confusão” soa ironicamente apropriada
Um servidor DNS de grande escala como o 1.1.1.1 deveria ter testes de integração incluindo resolvers reais como a glibc
Então fica a dúvida de por que esse problema só foi descoberto em produção
Os testes individuais passaram, mas é bem possível que o caso em que as duas condições coincidiam tenha ficado de fora