Guia para escolher um resolvedor DNS público

 (evilbit.de)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Ao escolher um resolvedor DNS público, é preciso olhar além da velocidade e considerar também privacidade, filtragem, jurisdição, operador e transporte criptografado; este guia compara 30 serviços globais por requisitos
  • A ferramenta de seleção usa DoH, DoT, DoQ, DNSCrypt, validação DNSSEC, IPv6, jurisdição, tipo de operador e EDNS Client Subnet como filtros rígidos, e pontua prioridades conforme o objetivo
  • O teste de latência DoH no navegador mostra a velocidade relativa a partir da localização atual, mas inclui overhead de TLS/HTTP e não consegue medir resolvedores que oferecem apenas DNS em texto claro
  • DNS criptografado reduz interceptação e adulteração por intermediários, mas o provedor do resolvedor escolhido ainda pode ver os domínios consultados, então também é preciso considerar políticas sem logs e designs oblivious
  • Na escolha prática, é preciso pesar conjuntamente DNSSEC, a troca entre velocidade e privacidade do ECS, desempenho do DoQ, características do DNSCrypt, limites da análise de tráfego, diferenças de conformidade com padrões, jurisdição e riscos de centralização

Critérios comparados pela ferramenta de seleção

  • Resolvedores DNS públicos são comparados por um método em que o usuário marca as condições que considera importantes
  • Condições usadas como filtros rígidos
    • Transporte criptografado: DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), DNSCrypt
    • Suporte a validação DNSSEC
    • Disponibilidade de endereços de resolvedor IPv6
    • Jurisdição do operador
    • Tipo de operador: sem fins lucrativos, comunidade ou interesse público; comercial; todos
    • EDNS Client Subnet (ECS): não usa, usa, indiferente
  • Itens incluídos na pontuação de prioridade
    • Máxima privacidade e ausência de logs ou logs mínimos
    • Bloqueio de malware e phishing
    • Bloqueio de anúncios e rastreadores
    • Controle parental e bloqueio de conteúdo adulto
    • Sem filtragem, retornando exatamente as respostas DNS publicadas
    • Listas e regras de bloqueio personalizadas por meio de conta
    • Baixa latência baseada em Anycast global
    • Operador não comercial

Teste de velocidade DoH com base na localização atual

  • O teste integrado mede, no navegador, o tempo de ida e volta até cada resolvedor com suporte a DoH
  • Resolvedores que oferecem apenas DNS em texto claro não podem ser testados por esse método
  • Os resultados são uma referência relativa e incluem overhead de TLS e HTTP, portanto pressupõem várias execuções
  • Como o navegador consulta cada resolvedor diretamente, o endereço IP do usuário é exposto a esse resolvedor
  • A implementação do teste foi inspirada no DNS Speed Test open source de Silviu Stroe, mas é uma implementação independente e só é executada quando a página é servida via HTTPS

Diferenças de desempenho e transporte criptografado

  • Transportes criptografados como DoH e DoT adicionam latência por consulta, mas o tempo total de carregamento de páginas muitas vezes fica próximo ao do DNS em texto claro, e o overhead de DoH também se mostra pequeno em ambientes reais
  • Em links com perda ou alta latência, o Do53 em texto claro ainda leva vantagem
  • O desempenho varia conforme provedor e região, então o resolvedor mais rápido depende da localização do usuário
  • Em medições de larga escala ponta a ponta de DNS criptografado, as consultas tiveram probabilidade muito menor de serem interceptadas ou alteradas em trânsito do que no DNS em texto claro, e o overhead foi pequeno
  • Porém, nesse estudo, cerca de 25% dos provedores DoT ofereciam certificados TLS inválidos, então é importante escolher um provedor com boa qualidade operacional

Limites reais da privacidade

  • DNS criptografado oculta as consultas na rede, mas o provedor do resolvedor escolhido pode ver todos os domínios consultados
  • Se isso for um problema, é preciso escolher um operador sem logs ou considerar designs oblivious, como ODoH, em que um proxy separa a identidade da consulta
  • Cloudflare e Apple são exemplos de implantação de ODoH
  • DNS criptografado sozinho não oculta completamente os sites visitados
    • Mesmo usando DoH, a análise de tráfego pode identificar domínios visitados com alta precisão
    • O padding EDNS padrão também não impede isso completamente
    • Se esse modelo de ameaça se aplicar, não dependa apenas de padding; use também Tor ou designs oblivious

DNSSEC, ECS e jurisdição

  • Somente resolvedores que fazem validação DNSSEC protegem contra registros falsificados
  • Google, Cloudflare e Quad9 validam DNSSEC e lidaram com o primeiro rollover da KSK da zona raiz sem causar falhas aos usuários
  • Se integridade for importante, a validação DNSSEC deve ser tratada como requisito obrigatório
  • EDNS Client Subnet (ECS) envia parte do IP a CDNs para melhorar o roteamento geográfico
    • Google e OpenDNS enviam ECS para um mapeamento de CDN mais preciso
    • Cloudflare e o Quad9 padrão desativam ECS por privacidade
  • A localização jurídica do operador afeta medidas que podem ser impostas e logs
  • Um pequeno número de provedores processa uma grande fatia do tráfego DNS recursivo mundial
  • A NSA dos EUA alertou que resolvedores externos contornam a filtragem e a inspeção de DNS internas, então é preciso ponderar o equilíbrio entre conveniência e controle

DoQ e DNSCrypt

  • Em uma medição de DoQ de 2022, DNS-over-QUIC superou tanto DoT quanto DoH em tempo de resposta
  • No entanto, por causa da limitação de validação de endereço do QUIC, cerca de 40% dos handshakes ficaram mais lentos
  • Se cliente e resolvedor forem compatíveis, DoQ é a opção criptografada preferível
    • Exemplos com suporte: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS e grandes serviços chineses
  • DNSCrypt é uma opção de criptografia mais antiga que DoH, DoT e DoQ; a versão 2 saiu em 2013
  • O DNSCrypt criptografa desde o primeiro pacote com a chave pública pré-compartilhada do resolvedor, portanto não há consulta de nome de host em texto claro nem dependência de autoridades certificadoras
  • O modo Anonymized DNS de 2019 também oculta o IP do cliente
  • Entre os serviços comparados, os provedores de DNSCrypt são Quad9, OpenDNS, AdGuard, NextDNS, Control D e Yandex
  • Faltam números confiáveis de uso, e medições em larga escala como as da APNIC Labs rastreiam DoH e DoT, mas não DNSCrypt

Qualidade de implementação dos resolvedores e dados operacionais

  • Em um estudo de 2023 sobre Extended DNS Errors, os principais resolvedores apresentaram relatórios de erros diagnósticos inconsistentes em 94% dos casos de teste
  • A Cloudflare apresentou o relatório de erros mais preciso nesse estudo
  • Diferenças de qualidade de implementação e conformidade com padrões entre resolvedores afetam a solução de problemas e a confiabilidade
  • Dados operacionais e comunitários que podem ser usados como referência

Resolvedores pequenos, comunitários e regionais

  • Fora da tabela comparativa, também há resolvedores de hobby, comunitários e específicos por país; é preciso verificar o estado atual e as políticas antes de usar
  • Itens europeus estão organizados em European Alternatives
  • Resolvedores em regiões com forte censura ou sanções podem aplicar regras locais de conteúdo ou ser operados para contornar bloqueios geográficos, portanto exigem ainda mais cautela
  • Exemplos de serviços
    • DNS4all: resolvedor europeu sem filtragem, com foco em neutralidade e desempenho
    • BlahDNS: projeto open source de hobby para bloqueio de anúncios, operado em pequenos servidores regionais, com suporte a DoH, DoT e DoQ
    • LibreDNS: resolvedor comunitário da LibreOps, com bloqueio de anúncios, política sem logs e suporte a DoH e DoT
    • Dismail.de: resolvedor comunitário alemão com foco em privacidade, sem logs e com suporte a DoH e DoT
    • IIJ Public DNS: resolvedor público DoH e DoT da Internet Initiative Japan, com bloqueio de domínios de material de abuso sexual infantil
    • DNS for Family: DoH com filtragem familiar, incluindo pornografia, jogos de azar, malware, anúncios e rastreadores, além de busca segura
  • Serviços legados ou descontinuados mencionados como a evitar incluem Oracle Dyn, Level3 (4.2.2.x), Freenom World, dns0.eu e Norton ConnectSafe

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões no Hacker News

  • Toda vez que vejo listas como esta ou o anúncio de um novo serviço, isso não me impressiona muito, e no Hacker News parece haver, surpreendentemente, muitas reações parecidas
    Venho operando meu próprio serviço de DNS proxy há quase 25 anos e já usei três conjuntos de software em seis sistemas operacionais; tudo o que aparece na aba de filtros eu consigo fazer por conta própria, e de fato faço
    O interessante nesta lista não são tanto as opções, mas o que ela revela. Por exemplo, todos os itens marcados como “China” dizem “operado sob regulamentação chinesa”, algo que, em 2026, preocupa não só no caso da China, mas também para usuários no meu continente
    A frase “operado por 1 indivíduo na Dinamarca” é uma informação interessante por revelar o bus factor, mas não dá para presumir que os outros itens sejam melhores só porque não dizem isso. Há muito menos informação sobre quem está por trás do DNS.Watch do que sobre Thomas Steen Rasmussen, e ele parece ter ficado fora do ar pelo menos uma vez nos últimos anos, então é uma preocupação legítima
    O Quad101 parece ter restrições de regiões onde está disponível, e há muitos fatores que não aparecem nesta lista, mas que podem ser importantes para os usuários, como o fato de a Gcore ser uma empresa de IA

    • “Operado por 1 indivíduo na Dinamarca” é mais interessante do ponto de vista de supervisão organizacional do que pelo bus factor
      Quando várias pessoas participam da operação, elas fiscalizam umas às outras e podem levantar problemas se virem algo estranho, como o resolvedor DNS fazendo logging seletivo ou interferindo nos resultados. Se uma única pessoa opera tudo, não há ninguém para contê-la
      Pode-se pensar “essa pessoa tem princípios, então jamais faria isso”, mas a pressão das autoridades policiais pode ser forte
    • Há uns 2 anos configurei meu próprio resolvedor, e ele simplesmente funciona bem. Nunca tive nenhum problema

  • Ao usar o DNS oficial do ISP, você consegue a rota mais curta possível a partir do ponto de handoff do ISP até uma CDN ou um tronco internacional. A ideia é não usar um DNS genérico que não conhece a estrutura do ISP
    ISP: 1 ms até a Cloudflare
    Cloudflare: 10 ms até a Cloudflare
    Porém, esse conselho vale para países com boas leis de privacidade e sem vigilância estatal. Ou seja, não para os EUA

    • Se você precisa de DNS sem censura, esse método não é bom
    • Na prática, é bem possível que usar um DNS que bloqueia servidores de anúncios ofereça melhor desempenho geral
    • Não sei se países assim ainda existem de fato. E isso não é só uma questão de privacidade: quase todos os países tentam impedir que usuários acessem lugares que eles não querem que sejam acessados, geralmente de um jeito tosco em que o DNS padrão do ISP manda você para uma página de aviso em vez do site que você queria abrir
      Por isso, mudar para um DNS como 8.8.8.8 se torna um primeiro grande passo para melhorar a experiência de navegação, mesmo que isso não aumente necessariamente a privacidade
    • A Cloudflare, como é bem conhecido, usa anycast, então a resposta DNS é a mesma independentemente de onde você venha. É difícil atribuir os números apresentados ao DNS
      Na verdade, a Cloudflare pode acelerar consultas recursivas para seus próprios serviços, tornando a etapa de resolução de nomes mais rápida, e, se necessário, também pode usar eDNS Client Subnet para roteamento baseado em localização
    • Trocar o DNS quase não tem efeito sobre a privacidade. Ainda é possível ler as consultas DNS e o SNI

  • Preciso de conselhos sobre como usar resolvedores DNS em Wi‑Fi público
    Muitos Wi‑Fis públicos exigem que você use o DNS deles para redirecionar para a tela de aceite dos termos, e às vezes pedem uma nova autorização a cada 30–60 minutos
    Quando dá problema, você percebe que a internet parou, manda ping para google.com e espera o timeout, tenta adivinhar se é problema do ISP, então se dá conta de que talvez a sessão do Wi‑Fi tenha expirado, muda o DNS e limpa o cache, acessa um domínio que não seja TLS, aprova o portal e depois precisa voltar o DNS
    Com certeza deveria existir algo que gerenciasse isso

    • No macOS, talvez dê para resolver com /etc/resolver
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      Usei esse método quando sites internos da universidade só eram resolvidos pelo nameserver da rede. Pensei que isso também poderia ser aplicado à URL que o macOS usa para detectar portais cativos, e preciso testar da próxima vez que for a um café
    • No macOS e no iOS, é possível criar um perfil que especifica o servidor DNS a ser usado sempre. Ele também se aplica a outras redes Wi‑Fi e aos dados móveis
      https://doh.lvv.me/
      Uso isso há alguns anos e nunca tive problemas em hotspots públicos
    • Basta colocar um endereço IP na barra de endereços. Normalmente eles interceptam todo o tráfego da porta 80
    • Isso é algo que o sistema operacional deveria tratar como parte do suporte a portais cativos. Seria bom contatar o fabricante do sistema operacional e registrar um bug

  • Uso o Unbound localmente como servidor DoH. O pacote Unbound do Alpine Linux é compilado com a libnghttp2, necessária para o listener DoH embutido, e isso já é suficiente para habilitar ECH
    A cada hora, faço pré-cache via cron de todos os domínios que uso com frequência. Meu ISP provavelmente não vai mexer nas minhas consultas DNS, e os funcionários de lá são mais esquisitos do que eu. Se eu começar a navegar na web pelo celular, vou criar meu próprio servidor DoH público. Leva poucos minutos e, ao depurar problemas estranhos, ainda tenho meus logs de consultas
    [1] - https://tls-ech.dev/

    • Há cerca de 3 anos opero meu próprio powerdns, dnsdist público, com instâncias recursivas/autoritativas, via DoH, DoT, DoQ, TCP e UDP
      Antes eu usava bind, unbound e dnsmasq, então a configuração levou algum tempo. É muito estável, funciona em dispositivos móveis e antigos, e também pode ser usado como resolvedor para unbound, adguard/dnsproxy e o resolve.conf local
    • Fiquei curioso para saber por que fazer pré-cache. Se for por velocidade, não seriam no máximo 30–50 ms? Também fico curioso se, quando o TTL do servidor autoritativo é menor que 60 minutos, você força para 3600
      Também me pergunto se você audita as conexões de todos os sites que visita para coletar até os domínios que hospedam assets e colocar tudo em pré-cache, ou se só os domínios principais dos sites, que mais afetam a latência percebida, importam
    • O Unbound tem prefetch, que atualiza registros em cache próximos da expiração, e várias opções de ajuste relacionadas a cache e TTL. O serve-expired também pareceu funcionar bem
    • Fiquei curioso sobre como é, na prática, “fazer pré-cache a cada hora via cron de todos os domínios que uso com frequência”. É um shell script que consulta uma lista de hostnames? E qual é o critério para “domínios que uso”?
    • Aqui também rodo Unbound. Gosto do fato de poder usar curingas para bloqueio de domínios. Uso uma lista grande de bloqueio e, por cima dela, uma lista de permissões com exceções
      Também tenho uma pequena ferramenta que simplifica entradas como ayt7.ads.acme.com, afi6.ads.acme.com, foi5.ads.acme.com para ads.acme.com
      Tenho ainda um script que gera variações dos domínios que uso. Por exemplo, se o domínio legítimo é mybank.com, bloqueio myb4nk.com, mibank.com, mybank.{todos os outros TLDs} etc.
      Gero centenas de milhares dessas variações e bloqueio todas no Unbound. Fiz isso depois que meu banco enviou um exemplo de site de phishing muito convincente
      Uso essa configuração há anos, e um milhão de domínios bloqueados roda bem até em um Pi 3 antigo. Em um computador mais potente, o Unbound provavelmente consegue lidar com listas de bloqueio de milhões, talvez dezenas de milhões de domínios. Ainda não migrei para uma abordagem baseada apenas em lista de permissões
      Também bloqueio todos os domínios Unicode. Domínios que usam caracteres Unicode no nome não são acessíveis, e não me importo

  • Uso o NextDNS com satisfação. Há muitas possibilidades de configuração, como quais listas de filtros ativar e como fazer logging
    É confiável e rápido em quase qualquer lugar. Isso é mais difícil de alcançar operando um resolvedor próprio na nuvem, e, de todo modo, não quero fazer essa manutenção

    • Eu também uso bem o NextDNS. Fiquei especialmente mais satisfeito depois de mexer com Pi-hole por alguns anos e me cansar da manutenção. Também é fácil usá-lo junto com a Mullvad VPN quando necessário
    • Para mim também foi bastante bom

  • Não sei por que só 29
    O autor está dizendo que esse é o número real de resolvedores abertos na internet hoje?
    Pergunto-me como é possível considerar “privacidade” ou “segurança” no DNS sem considerar também SNI
    O SNI permite que terceiros vejam a qual nome de domínio, em um endereço público, o usuário pretende se conectar, e também permite que interfiram nessa conexão
    O DNS só permite que terceiros vejam qual endereço público o usuário está consultando para determinado nome de domínio. Para associar tráfego que não é DNS a essa consulta, é preciso fazer suposições sobre como aquele software funciona
    Portanto, não surpreende que empresas de publicidade que dominam navegadores populares queiram que o usuário escolha DoH dentro do navegador ou em sistemas operacionais corporativos. Ao chamar isso de forma enganosa de “DNS privado”, terceiros conseguem correlacionar com mais eficácia as consultas com tráfego não DNS de software executado no navegador ou no sistema operacional corporativo
    Essas afirmações enganosas podem até gerar processo. Por exemplo, usuários já venceram uma ação por alegações enganosas sobre “navegação privada”

    • Esses 29 são serviços nos quais muitas pessoas confiam, em alguma medida, para entregar suas consultas DNS. Além disso, esses 29 divulgam informações sobre as características do serviço
      Se você ler a página inteira, há também uma lista separada de outros resolvedores DNS públicos dignos de menção
      Para a longa cauda desconhecida de resolvedores DNS abertos, use o Shodan. Mas eu não recomendaria confiar o uso da internet a algo que você encontrou no Shodan
      SNI é, sim, uma questão geral de privacidade na internet, mas não é uma propriedade do DNS. Pelo lado positivo, o ECH passou pelo IETF e será disponibilizado aos poucos para usuários comuns
      — autor
    • ECH não está amplamente disponível para usuários comuns da web, exceto em alguns sites de “teste”
      Também não está claro a quem o “you” da resposta do autor se refere
      No meu caso, só uso DNS remoto quando busco periodicamente dados DNS em massa. Ao acessar servidores HTTP, não faço solicitações DNS remotas. Já tenho as informações de endereço IP necessárias, e esse método é mais rápido e confiável
      Mantenho dados DNS em massa obtidos de várias fontes carregados na memória de um proxy de encaminhamento TLS local
      Os usuários são todos diferentes, e cada um precisa pensar por si mesmo

  • Para usuários no Canadá, a CIRA opera um resolvedor público via IPv4, IPv6, DoH e DoT
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • Não sei por que canadenses deveriam confiar mais na CIRA do que em outras alternativas. Ainda assim, é bem provável que seja melhor do que usar o DNS padrão do ISP

  • O DNScryptProxy mantém uma lista enorme de servidores DNS públicos. Também indica se há suporte a DNSSEC, filtragem e logging
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • Seria bom se um site desses oferecesse um teste básico de comparação de velocidade com base na rede local
    Seria interessante poder comparar o tempo de resposta P90 e o tempo de resposta mediano para consultas aleatórias

    • Sou o autor e acabei de adicionar isso: https://evilbit.de/dns-resolver-guide2.html#speedtest
      Mas funciona apenas com DoH
    • Se você clonar este repositório e ajustar os nomes de domínio e os resolvedores como quiser, consegue obter algo parecido com o que procura
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • Estou rodando localmente uma instância do smokeping para esse fim. Ela faz ping em vários servidores DNS, no DNS do ISP e em alguns sites importantes, e, com base nos resultados, atualiza periodicamente os upstreams do servidor DNS local
      No meu ambiente, todos os grandes servidores DNS ficam na faixa de 5–6 ms, mas nem sempre foi assim. O DNS do ISP também tem média parecida, mas a variação é grande e há picos que chegam a 50 ms. Isso mesmo estando no local onde ele deveria ser o mais rápido

  • DNS é um tema muito importante para privacidade e segurança. Em vez de escolher um DNS público, acho melhor hospedar infraestrutura própria
    Você não precisa de uma instância pública. Basta rodar ADGUARD, unbound, dnsmasq ou dnsdist em modo recursivo no roteador ou em uma máquina
    Também dá para configurar restrições e listas de bloqueio conforme suas necessidades

    • Ainda assim, o ISP pode registrar todas as consultas