A Cloudflare publicou em 27 de agosto de 2026 uma otimização de escala incomum no mecanismo que atende o 1.1.1.1: cinco mudanças na representação das entradas de cache liberaram aproximadamente 100 terabytes de memória e reduziram em 19% a latência interna de busca.
O resultado é relevante porque o cache é o caminho rápido de um resolvedor. Quando a resposta ainda está válida, o serviço não precisa repetir todo o percurso até os servidores autoritativos. Ele a encontra localmente, ajusta os campos necessários e responde ao usuário.
Mas o número de 19% precisa ser interpretado corretamente. A medição caiu de 828 para 670 nanossegundos dentro do processo de cache. Ela não afirma que a consulta completa do celular ao 1.1.1.1 ficou 19% mais rápida em todas as redes.
O tamanho do cache do 1.1.1.1
A plataforma de resolução da Cloudflare, chamada Big Pineapple, sustenta o 1.1.1.1, Gateway DNS, DNS Firewall, AS112 e outros serviços. Segundo a empresa, ela mantém mais de 250 bilhões de entradas de cache em um dado momento.
Nessa escala, um byte desperdiçado por entrada representa mais de 250 GB em toda a frota. A Cloudflare trabalhou na estrutura em Rust usada para guardar a chave da consulta, os registros da resposta, TTL, horário de criação, contadores e erros estendidos.
O benchmark usado no desenvolvimento aproximou a mistura de tráfego de produção:
- 56% de registros
A; - 25% de registros
AAAA; - 19% de registros
TXT, usados como aproximação para tipos de tamanho variável; - uma a quatro respostas por entrada.
Além do teste controlado, a equipe mediu a memória residente em instâncias de produção durante a implantação, iniciada em 18 de maio e concluída em 6 de julho de 2026.
O que mudou nos números
| Métrica | Antes | Depois | Mudança |
|---|---|---|---|
| Memória líquida por entrada | 953 bytes | 420 bytes | -56% |
| Alocações por entrada | 1,1 KB | 461 bytes | -58% |
| Inserções no cache | 625 mil/s | 893 mil/s | +43% |
| Latência de busca | 828 ns | 670 ns | -19% |
Em produção, a memória total do processo caiu menos que os 56%, porque inclui código e dados fora do cache. Ainda assim, no percentil 99, o consumo por instância passou de 9,3 GB para 5,3 GB. A redução agregada do conjunto de trabalho ficou perto de 100 TB, equivalente, segundo a Cloudflare, à RAM de 130 servidores de sua geração 13.
Como foi possível reduzir memória e ganhar velocidade
Normalmente, economizar memória pode acrescentar processamento. Neste caso, várias mudanças reduziram as duas coisas ao mesmo tempo.
Uma estrutura genérica pode reservar espaço suficiente para o maior tipo de registro mesmo quando guarda um A ou AAAA pequeno. Outras representações criam várias alocações separadas no heap. Isso desperdiça bytes e espalha dados, obrigando o processador a seguir ponteiros até regiões diferentes da memória.
O estágio final passou a guardar os dados de registros DNS em formato binário compacto e contíguo. Tipos comuns podem ser copiados quase diretamente para a resposta; apenas registros que contêm nomes, como CNAME, NS, MX e SOA, ainda exigem processamento para compressão de nomes.
Menos alocações e melhor localidade de memória explicam por que as inserções ficaram mais rápidas e a busca perdeu nanossegundos, mesmo usando menos RAM.
Isso deixa a internet do usuário mais rápida?
Pode contribuir, mas não na proporção direta de 19%. Uma consulta observada no celular costuma levar milissegundos, não nanossegundos. O tempo total inclui:
- Wi-Fi ou rede móvel até o roteador;
- rota da operadora até o ponto de presença anycast;
- processamento do resolvedor;
- em um cache miss, consultas à raiz, TLD e servidor autoritativo;
- validação DNSSEC e possíveis novas tentativas.
A economia de 158 nanossegundos é pequena diante de uma viagem de 10 ou 30 milissegundos pela rede. O efeito mais interessante pode vir depois: a Cloudflare pretende reinvestir a memória liberada para aumentar a capacidade do cache. Mais entradas podem elevar a taxa de acerto e evitar viagens externas, que custam muito mais.
Esse benefício também não é uniforme. TTLs curtos, nomes raros e respostas personalizadas com EDNS Client Subnet geram mais variantes e reduzem o reaproveitamento. Domínios populares com TTL adequado tendem a aproveitar melhor o cache.
Como procurar a diferença em um benchmark
Não compare uma única consulta feita antes da notícia com outra feita depois. Rota, congestionamento e estado do cache produzem variações maiores que a otimização interna.
Use um método repetível:
- faça várias rodadas no mesmo aparelho e conexão;
- compare Cloudflare, Google, Quad9 e o DNS da operadora na mesma janela;
- separe consultas quentes, repetidas, de nomes aleatórios que provocam cache miss;
- observe mediana, P95, jitter e taxa de sucesso;
- repita em horários diferentes e confirme que o endereço realmente alcançado é o esperado.
Uma melhora consistente no P95 ou na estabilidade é mais útil que uma diferença mínima na média. Para estruturar o teste, veja como comparar Cloudflare e Google DNS e como encontrar o DNS mais rápido.
O que a notícia realmente demonstra
A otimização não transforma o 1.1.1.1 em vencedor universal. O servidor mais rápido continua dependendo da operadora, localização, rota anycast, horário e tipo de consulta.
O resultado demonstra outra coisa: em um resolvedor global, eficiência de memória e desempenho estão ligados. Compactar centenas de bilhões de objetos deixa espaço para um cache maior, reduz pressão no alocador e economiza trabalho do processador. O ganho que chega ao usuário pode ser sutil por consulta, mas se multiplica na escala do serviço e pode melhorar capacidade e consistência.
