Cloudflare corta 100 TB de memória do cache DNS do 1.1.1.1 reescrevendo estruturas em Rust

A Cloudflare reescreveu a representação em memória do cache DNS usado pelo resolver público 1.1.1.1 e conseguiu reduzir o tamanho médio de cada entrada em 56%, de 953 para 420 bytes, segundo reportagem da InfoQ. O ganho, aplicado em produção entre 18 de maio e 6 de julho de 2026 em toda a frota que roda o Big Pineapple (plataforma de DNS da empresa), liberou aproximadamente 100 TB de working-set memory, sem trocar hardware nem mudar a lógica de resolução de nomes.

O cache em questão não é pequeno: o Big Pineapple mantém mais de 250 bilhões de entradas simultâneas. Isso muda a escala do problema. Uma economia que pareceria irrelevante num serviço pequeno, quando multiplicada por 250 bilhões de registros, vira uma diferença de dezenas de terabytes. "Não é todo dia que você consegue economizar 100 terabytes de memória", resumiu o engenheiro de sistemas da Cloudflare Sebastiaan Neuteboom em post no LinkedIn citado pela InfoQ.

As cinco mudanças na representação de dados

O trabalho não foi uma reescrita única, mas cinco alterações sucessivas na forma como cada entrada de cache é guardada em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →:

1. Trocar Vec e String por Box<[T]> e Box nos campos que não mudam depois da inserção no cache. Vec e String carregam capacidade extra (ponteiro, tamanho e capacidade alocada, geralmente maior que o necessário) porque foram desenhados para crescer. Uma vez que o dado está fixo, essa folga é desperdício puro. Só essa troca economizou 64 bytes por entrada e mais de 15 TB em toda a frota.
2. Unificar as listas de registros answer, authority e additional numa única lista com offsets compactos, em vez de três coleções separadas com seus próprios cabeçalhos de alocação.
3. Empacotar booleanos em bitflags, técnica clássica de compactação: em vez de vários campos bool (cada um ocupando ao menos 1 byte, às vezes mais por alinhamento), os flags viram bits dentro de um único inteiro.
4. Omitir o nome do dono do registro quando ele coincide com o domínio consultado, reconstruindo essa informação a partir da própria chave de cache no momento da leitura, em vez de armazená-la duplicada em cada entrada.
5. Substituir os enums de tipo de registro por um buffer de bytes contíguo em formato wire do DNS.

O gargalo que os enums escondiam

A quinta mudança foi a mais trabalhosa e é a que mais interessa a quem programa em Rust e lida com structs que crescem em produção. A abordagem natural para representar diferentes tipos de registro DNS (A, AAAA, CNAME, MX, e por aí vai) é um enum, com cada variante carregando os dados específicos daquele tipo. O problema é que variantes de tamanho muito diferente fazem o enum inteiro ocupar o espaço da maior delas.

A solução inicial da Cloudflare foi colocar as variantes maiores atrás de Box, movendo-as para o heap e deixando só um ponteiro no enum. Funciona para reduzir o tamanho do enum em si, mas troca um problema por outro: cada variante boxed vira uma alocação separada no heap, e alocações espalhadas prejudicam localidade de memória, o que é ruim justamente para acesso em cache de alta frequência, cheio de cache misses de CPU.

O desenho final abandona o enum e guarda os dados do registro como um buffer de bytes contíguo, no próprio formato wire do DNS (o formato binário que trafega na rede). Isso elimina de vez a sobrecarga de alocação por registro e melhora localidade, porque os bytes ficam um do lado do outro na memória em vez de espalhados por ponteiros. Tipos de registro usados com frequência podem ser copiados direto do cache para a resposta, sem parsing. Registros que carregam nomes de domínio dentro do payload (como CNAME ou MX) ainda precisam ser interpretados na hora de montar a resposta, por causa da compressão de nomes do protocolo DNS.

Os números da produção

O impacto medido em produção, com o rollout completo entre maio e julho de 2026:

• Memória residente por instância no p99: caiu de 9,3 GB para 5,3 GB.
• No p90: caiu de 6,5 GB para 3,8 GB.
• Alocações por entrada: de 1,1 KB para 461 bytes.
• Throughput de inserção no cache: alta de 43%.
• Latência de leitura (lookup): queda de 19%.

A Cloudflare afirma que vai usar a memória liberada para aumentar a capacidade do cache sem elevar o consumo total, o que na prática significa mais entradas guardadas (mais respostas servidas do cache em vez de ir buscar de novo na origem) pelo mesmo custo de infraestrutura.

Nem toda escala precisa disso

Um comentário no Reddit citado pela InfoQ traz um contraponto importante para quem for tentado a replicar essas técnicas: "muitos desses truques de memória só compensam quando você está no volume de requisições da Cloudflare; em escala menor, a indireção extra de colocar variantes em Box pode prejudicar a localidade de cache mais do que ajudar". É um lembrete direto de que boxing de enum, buffer wire manual e bitflags são otimizações que trocam legibilidade e manutenibilidade por desempenho, e essa troca só vale a pena quando o número de acessos por segundo e o volume de entradas justificam.

Como outros resolvers DNS resolvem o mesmo problema

A InfoQ contextualiza a escolha da Cloudflare comparando com dois resolvers recursivos populares em infraestrutura self-hosted. Segundo a reportagem, o Unbound mantém caches separados (mensagem, RRset, chave e cache negativo), cada um com tamanho e configuração de slab próprios, permitindo ajuste fino por tipo de dado; essa descrição não foi confirmada em documentação oficial do projeto entre as fontes consultadas. Ainda de acordo com a InfoQ, o PowerDNS Recursor usa múltiplos tipos de cache, incluindo cache de pacote e cache de registro, informação também não verificada diretamente na documentação do PowerDNS. A diferença de abordagem da Cloudflare, segundo a reportagem, não está em ter múltiplos caches especializados, mas em atacar o overhead de representação e alocação dentro de cada entrada individual do cache, o que faz sentido quando a entrada em si é o gargalo, não a arquitetura de camadas.

O que fica para quem escreve Rust em produção

O caso é um roteiro replicável para qualquer serviço em Rust com estruturas de dados de vida longa em memória, mesmo fora da escala de bilhões de entradas: revisar se Vec/String são realmente necessários (ou se um Box<[T]>/Box bastaria depois que o dado para de mudar), medir se enums com variantes de tamanhos muito diferentes estão inflando o tipo, e considerar formatos binários compactos quando o dado já tem um formato de serialização natural, como é o caso do wire format do DNS. O ponto central que o caso da Cloudflare deixa é que a otimização de memória em produção raramente vem de uma mudança grande e sim de uma sequência de ajustes de representação, cada um medido isoladamente antes do próximo, com benchmark de tamanho de entrada e alocação acompanhando cada etapa.

Fonte: InfoQ