Privacy-by-Design: O Que Nossas Edge Nodes Não Escrevem em Disco e Por Que é Mais Complexo do Que Parece
Explore as estratégias de privacidade implementadas em nível de edge para proteger dados de usuários de DNS, focando em o que não é armazenado em disco e os desafios técnicos envolvidos.
MundiX News·28 de maio de 2026·8 min de leitura·👁 15 views
No mundo da cibersegurança, a privacidade não é apenas um recurso de marketing, mas uma necessidade arquitetural fundamental, especialmente para serviços que lidam com dados sensíveis como resoluções DNS. O VantageDNS, um resolvedor DNS recursivo com filtragem, adota uma abordagem "privacy-by-design" desde o início, garantindo que as promessas de privacidade sejam sustentadas por garantias arquiteturais. Este artigo detalha as medidas específicas tomadas nas edge nodes do VantageDNS para minimizar o armazenamento de dados em disco, incluindo o uso de buffers circulares para logs de consulta, o gerenciamento de crash dumps e como os usuários podem verificar essas garantias através de ferramentas como strace.
Um dos principais pontos de preocupação em provedores de DNS é o "query log", que tipicamente armazena informações como o nome de domínio consultado (qname), timestamp e o endereço IP do cliente. Se não for gerenciado adequadamente, esse log pode se tornar um vazamento significativo de privacidade. Outros pontos de vazamento comuns incluem mapeamentos de config_id para e-mail, logs de acesso HTTP antes do endpoint DoH, crash dumps que podem conter sessões DNS ativas, backups e agregadores de logs, e até mesmo dados de fingerprinting de TLS como JA3 e ALPN. A filosofia "privacy-by-design" exige que cada um desses pontos seja abordado. No caso do VantageDNS, a estratégia é clara: ou esses dados não existem no disco da edge node, ou são armazenados em jurisdições com leis de proteção de dados rigorosas (como a União Europeia), com tempo de retenção limitado e criptografia "at rest", ou são explicitamente declarados em relatórios de transparência com acesso restrito.
Para mitigar o risco de vazamento de query logs, o VantageDNS implementou um buffer circular em memória nas suas edge nodes. Em vez de escrever logs diretamente em arquivos de disco, os eventos de consulta (contendo ConfigID, QName, QType e Action, mas notavelmente sem o IP do cliente, pois ele não é necessário após a resposta) são enviados para um canal. Um worker periodicamente envia esses eventos em lotes para o ClickHouse em Helsinque via gRPC. Crucialmente, se a conexão com o plano de controle falhar por mais de alguns minutos, o buffer se enche e os eventos mais antigos são descartados. Essa é uma decisão consciente para priorizar a ausência de um arquivo de evidência no disco da edge node em detrimento da completude exata das métricas ou de um pequeno lapso no dashboard do usuário. Além disso, o VantageDNS evita o uso de servidores proxy como Nginx ou Caddy antes do endpoint DoH, que poderiam registrar logs de acesso contendo IPs de usuários e config_id. A terminação TLS e o processamento HTTP/2 e HTTP/3 são feitos diretamente no processo Go do vdns-edge. A configuração do TLS é rigorosamente verificada para garantir que KeyLogWriter não esteja habilitado, e fingerprints JA3 e ALPN não são calculados ou armazenados. Crash dumps são desativados através de configurações do systemd (LimitCORE=0, Environment=GOTRACEBACK=none) e o uso de diretórios temporários é restrito (PrivateTmp=true). O sistema de arquivos raiz é montado como somente leitura (ProtectSystem=strict), com exceções apenas para a rotação de certificados. Para minimizar o uso de memória, debug.FreeOSMemory() é chamado após grandes flushes de dados, e o cache de DNS armazena respostas com base apenas em (qname, qtype), não incluindo o IP do cliente, o que beneficia tanto a privacidade quanto a performance.
Em termos de o que é fundamentalmente ausente nas edge nodes, o VantageDNS não armazena logs em arquivos (o stderr é enviado para o journald do systemd, e apenas agregados de erro/aviso são enviados para Helsinque, sem detalhes de consulta), não faz backup do estado de configuração no disco (configurações são puxadas via gRPC do plano de controle), e não utiliza bancos de dados locais como SQLite ou BoltDB, nem SDKs de monitoramento como Sentry com dados de requisição. No plano de controle, os query logs são armazenados no ClickHouse na Finlândia, com retenção de 24 horas para planos gratuitos e até 30 dias para planos pagos, com criptografia "at rest" e acesso restrito ao fundador. Para verificação, os usuários podem usar strace para monitorar os arquivos abertos pela edge node, confirmando que não há escrita em locais sensíveis. Um "warrant canary" é publicado semanalmente para indicar a ausência de ordens judiciais secretas. O artigo conclui reconhecendo as limitações, como a possibilidade de comprometimento do plano de controle ou a exploração de zero-days, mas reafirma que a privacidade é um compromisso arquitetural contínuo e verificável.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
No mundo da cibersegurança, a privacidade não é apenas um recurso de marketing, mas uma necessidade arquitetural fundamental, especialmente para serviços que lidam com dados sensíveis como resoluções DNS. O VantageDNS, um resolvedor DNS recursivo com filtragem, adota uma abordagem "privacy-by-design" desde o início, garantindo que as promessas de privacidade sejam sustentadas por garantias arquiteturais. Este artigo detalha as medidas específicas tomadas nas edge nodes do VantageDNS para minimizar o armazenamento de dados em disco, incluindo o uso de buffers circulares para logs de consulta, o gerenciamento de crash dumps e como os usuários podem verificar essas garantias através de ferramentas como strace.
Um dos principais pontos de preocupação em provedores de DNS é o "query log", que tipicamente armazena informações como o nome de domínio consultado (qname), timestamp e o endereço IP do cliente. Se não for gerenciado adequadamente, esse log pode se tornar um vazamento significativo de privacidade. Outros pontos de vazamento comuns incluem mapeamentos de config_id para e-mail, logs de acesso HTTP antes do endpoint DoH, crash dumps que podem conter sessões DNS ativas, backups e agregadores de logs, e até mesmo dados de fingerprinting de TLS como JA3 e ALPN. A filosofia "privacy-by-design" exige que cada um desses pontos seja abordado. No caso do VantageDNS, a estratégia é clara: ou esses dados não existem no disco da edge node, ou são armazenados em jurisdições com leis de proteção de dados rigorosas (como a União Europeia), com tempo de retenção limitado e criptografia "at rest", ou são explicitamente declarados em relatórios de transparência com acesso restrito.
Para mitigar o risco de vazamento de query logs, o VantageDNS implementou um buffer circular em memória nas suas edge nodes. Em vez de escrever logs diretamente em arquivos de disco, os eventos de consulta (contendo ConfigID, QName, QType e Action, mas notavelmente sem o IP do cliente, pois ele não é necessário após a resposta) são enviados para um canal. Um worker periodicamente envia esses eventos em lotes para o ClickHouse em Helsinque via gRPC. Crucialmente, se a conexão com o plano de controle falhar por mais de alguns minutos, o buffer se enche e os eventos mais antigos são descartados. Essa é uma decisão consciente para priorizar a ausência de um arquivo de evidência no disco da edge node em detrimento da completude exata das métricas ou de um pequeno lapso no dashboard do usuário. Além disso, o VantageDNS evita o uso de servidores proxy como Nginx ou Caddy antes do endpoint DoH, que poderiam registrar logs de acesso contendo IPs de usuários e config_id. A terminação TLS e o processamento HTTP/2 e HTTP/3 são feitos diretamente no processo Go do vdns-edge. A configuração do TLS é rigorosamente verificada para garantir que KeyLogWriter não esteja habilitado, e fingerprints JA3 e ALPN não são calculados ou armazenados. Crash dumps são desativados através de configurações do systemd (LimitCORE=0, Environment=GOTRACEBACK=none) e o uso de diretórios temporários é restrito (PrivateTmp=true). O sistema de arquivos raiz é montado como somente leitura (ProtectSystem=strict), com exceções apenas para a rotação de certificados. Para minimizar o uso de memória, debug.FreeOSMemory() é chamado após grandes flushes de dados, e o cache de DNS armazena respostas com base apenas em (qname, qtype), não incluindo o IP do cliente, o que beneficia tanto a privacidade quanto a performance.
Em termos de o que é fundamentalmente ausente nas edge nodes, o VantageDNS não armazena logs em arquivos (o stderr é enviado para o journald do systemd, e apenas agregados de erro/aviso são enviados para Helsinque, sem detalhes de consulta), não faz backup do estado de configuração no disco (configurações são puxadas via gRPC do plano de controle), e não utiliza bancos de dados locais como SQLite ou BoltDB, nem SDKs de monitoramento como Sentry com dados de requisição. No plano de controle, os query logs são armazenados no ClickHouse na Finlândia, com retenção de 24 horas para planos gratuitos e até 30 dias para planos pagos, com criptografia "at rest" e acesso restrito ao fundador. Para verificação, os usuários podem usar strace para monitorar os arquivos abertos pela edge node, confirmando que não há escrita em locais sensíveis. Um "warrant canary" é publicado semanalmente para indicar a ausência de ordens judiciais secretas. O artigo conclui reconhecendo as limitações, como a possibilidade de comprometimento do plano de controle ou a exploração de zero-days, mas reafirma que a privacidade é um compromisso arquitetural contínuo e verificável.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
