DNS Over HTTPS Explicado: Privacidade vs Filtragem de WiFi Pública
O DNS over HTTPS criptografa consultas dentro do tráfego da porta 443. Saiba o que ele oculta, por que ele pode burlar a filtragem de WiFi e como as redes mantêm o controle.
Published 26 de outubro de 2026
O DNS over HTTPS envia consultas de DNS dentro do tráfego HTTPS comum na porta 443, criptografado entre o dispositivo e o resolvedor, e se tornou um padrão IETF em 2018.
Você ativou a filtragem de conteúdo no seu WiFi de visitantes, mas o navegador de um visitante ainda abre uma categoria que você achava que tinha bloqueado. O firewall está em execução, as configurações de rede parecem corretas e outro dispositivo exibe a página de bloqueio esperada. A diferença pode estar em qual resolvedor o navegador consulta, e não se o seu filtro está funcionando.
Para operadores de locais e líderes de TI, esse é o ponto central em relação ao DoH. Ele protege a busca durante o trajeto, mas a escolha de destino do navegador também pode mover essa busca para fora da política de filtragem da sua rede.
Índice
- O que DNS over HTTPS significa em termos simples
- Como uma consulta DoH viaja do dispositivo até o resolvedor
- Quem pode ver suas consultas quando o DoH está ativado
- Por que o DoH enfraquece a filtragem de DNS em WiFi compartilhado
- O custo do DoH em velocidade e o que a filtragem ainda faz
- Verifique e altere o DoH em dispositivos comuns
- Escolha e estruture seus controles DoH em camadas
O que DNS over HTTPS significa em termos simples
DNS over HTTPS, geralmente abreviado como DoH, transporta perguntas e respostas de DNS por meio de uma conexão web criptografada. Um resolvedor DNS é o serviço que um dispositivo consulta para traduzir um nome de domínio em um endereço de rede.
Pense no DNS como uma lista telefônica. Antes de abrir uma conexão, um aplicativo precisa de um endereço, embora já possa ter uma resposta útil em seu cache. O DNS tradicional comumente envia essa pergunta em formato legível.
Um cartão-postal é uma analogia útil: qualquer pessoa que o manuseie pode ler a mensagem. O DoH coloca a pergunta em um envelope lacrado e a transporta dentro do mesmo tipo de van de entrega usado para o tráfego web seguro comum.
Compare o transporte, e não apenas a criptografia
O DNS over TLS, ou DoT, também sela o envelope, mas usa uma porta de entrega rotulada separadamente. Isso torna seu tráfego mais fácil de ser identificado por um operador de rede por meio de sua porta de destino.
A RFC 8484 do IETF, publicada em outubro de 2018, define a troca HTTPS do DoH, usando tipicamente a porta 443, ao contrário do DNS tradicional na porta 53.
Comparativo entre DNS tradicional, DNS over TLS e DNS over HTTPS
| Recurso | DNS Tradicional | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| Transporte | UDP ou TCP | TLS | HTTPS |
| Porta habitual | 53 | 853 | 443 |
| Legível pela rede local | Sim | Não | Não |
| Fácil de identificar pela porta | Sim | Sim | Não, compartilha a porta 443 com o tráfego web |
| Fácil de bloquear pela porta | Sim | Sim | Não, não seletivamente apenas pela porta |
| Definido em | Especificações originais de DNS | Especificação DNS over TLS | RFC 8484 |
Bloquear uma porta DNS dedicada é simples. Bloquear a porta usada por sites seguros também interromperia o tráfego web legítimo, portanto, o DoH exige controles mais seletivos.
A criptografia não decide o que é filtrado. Um resolvedor pode descriptografar uma solicitação DoH de entrada, aplicar uma política de conteúdo ou de ameaças e retornar sua resposta com segurança. As perguntas importantes são quem opera esse resolvedor e qual política ele segue.
Mantenha esta comparação à mão ao revisar os controles. Uma regra que lida com DNS tradicional ou DoT não lida automaticamente com DoH.
Como uma consulta DoH viaja do dispositivo para o resolvedor
Um entregador precisa de um endereço antes de entregar um pacote. Da mesma forma, um navegador precisa do endereço de destino antes de poder se conectar a uma página de reserva de hotel, a menos que já tenha essa resposta em cache.
Este diagrama acompanha a consulta desde o navegador até o resolvedor e de volta.
Acompanhe a solicitação e a resposta
O navegador precisa de um endereço. Ele verifica se já possui uma resposta útil para o site de reservas. Um hit no cache pode evitar totalmente uma nova busca, para que a rede local não veja uma troca de DNS para essa ação.
Ele constrói uma pergunta DNS. Se precisar de uma resposta nova, o navegador prepara uma consulta contendo o nome do domínio. Neste ponto, a pergunta ainda está dentro do dispositivo, sem trafegar pela WiFi.
Ele seleciona o resolvedor DoH. O navegador prepara uma requisição HTTPS para o seu resolvedor configurado. A rede local pode observar o endereço de destino e os metadados da conexão, mas não consegue ler diretamente o domínio dentro da mensagem DNS criptografada.
Ele estabelece ou reutiliza uma conexão segura. Se necessário, o dispositivo conclui um handshake TLS antes de enviar a requisição protegida. Com uma conexão HTTP persistente, as consultas subsequentes podem reutilizar essa conexão; a rede vê o tráfego criptografado, incluindo seu tempo e tamanho.
O resolvedor retorna a resposta. O resolvedor processa a pergunta e coloca a resposta DNS dentro de uma resposta HTTP criptografada. A rede pode ver o tráfego retornando do resolvedor, mas não o conteúdo legível da resposta.
O navegador se conecta ao site. Ele usa o endereço retornado para iniciar a conexão com o site. A rede local pode observar esse novo destino, o que é diferente de ler a pergunta DNS anterior.
Para mais detalhes sobre cache e resolução, a explicação sobre o que uma busca de DNS faz separa o processo de localização do endereço da própria conexão com o site.
Identifique o ponto de filtragem
Para uma nova conexão que exige resolução de DNS, a busca ocorre antes do carregamento do conteúdo da página. Isso dá a um resolvedor aprovado a oportunidade de recusar um destino bloqueado antes que o navegador se conecte.
Um navegador configurado de forma independente pode enviar essa decisão para outro lugar. O resolvedor do local, portanto, não recebe nenhuma consulta para avaliar.
O vídeo que acompanha oferece outra maneira de acompanhar o processo.
Quem pode ver suas consultas quando o DoH está ativado
O DoH não oculta a navegação de todos. Ele protege a troca de DNS contra observadores comuns entre o dispositivo e o resolver escolhido, mas esse resolver precisa ler a pergunta para respondê-la.
Essa distinção é importante no WiFi compartilhado. Um convidado pode razoavelmente querer proteção contra interceptação local, enquanto um hospital ou escola precisa ter a certeza de que seus controles de proteção e de ameaças ainda se aplicam.
O DoH altera em quem você confia em relação à atividade de DNS; ele não remove a necessidade de confiar em alguém.
Separe a visibilidade do DNS da visibilidade de navegação
A tabela descreve o uso comum do DoH sem um relay de privacidade adicional, VPN ou sistema de interceptação. Ler uma mensagem de DNS e inferir um destino a partir de outra atividade de rede são capacidades diferentes.
Quem pode ver as buscas DNS quando o DoH está em uso
| Observador | Vê nomes de domínio | Vê que o DoH está em uso | Por que isso importa |
|---|---|---|---|
| Outros dispositivos na mesma WiFi | Não, não a partir da consulta criptografada | Raramente por meio de acesso comum entre pares | A leitura passiva da mensagem DNS é bloqueada |
| Rede do local ou do provedor de internet | Não, não dentro da troca de DoH | Muitas vezes, por meio do tráfego para um endereço de resolvedor conhecido | Os controles locais de DNS não podem avaliar consultas enviadas para outros lugares |
| Websites que você visita | Apenas o site ao qual você se conecta | Não apenas pela conexão com o website | Um site não recebe suas consultas DNS não relacionadas |
| Operador do resolvedor DoH | Sim, todas as consultas que recebe | Sim | Uma conexão direta expõe essas consultas juntamente com seu endereço de origem |
| Fornecedor do navegador ou sistema operacional | Apenas se operar o resolvedor ou receber telemetria relevante | O software conhece seu modo configurado; relatórios do fornecedor exigem telemetria | A configuração do software não é o mesmo que visibilidade automática do fornecedor |
O resolver não vê necessariamente todas as consultas feitas pelo dispositivo. Outro aplicativo pode usar um resolver diferente, e respostas em cache podem não exigir nenhuma consulta. Ele vê apenas as solicitações que são enviadas a ele.
Da mesma forma, o fornecedor do navegador não recebe automaticamente o histórico de DNS só porque fornece o navegador. A operação do resolver, as configurações do software e a coleta de telemetria são funções distintas.
Torne a decisão de confiança explícita
Para instalações gerenciadas do Firefox, a documentação da política de DNS over HTTPS da Mozilla fornece controles para a configuração do resolvedor e para permitir ou não que os usuários a alterem. Essa é uma maneira prática de alinhar o comportamento do navegador com a governança de DNS da organização.
Um local ou provedor de Internet ainda pode observar os endereços de destino, o tempo de conexão e o volume de tráfego. Outros metadados de protocolo também podem ajudar a identificar um site, portanto, uma consulta de DNS criptografada não é uma garantia de navegação anônima.
Use uma breve avaliação de confiança antes de aprovar um resolvedor:
- Identifique o operador. Estabeleça qual organização recebe as consultas, em vez de confiar no rótulo padrão de um navegador.
- Leia os termos de retenção. Verifique quais informações de consulta e conexão são armazenadas, por quanto tempo e com qual finalidade.
- Verifique a jurisdição e o acesso. Entenda onde o operador processa as informações e quem pode obtê-las.
- Ajuste a visibilidade à responsabilidade. Decida quais eventos de segurança sua equipe de TI precisa investigar e quais detalhes de navegação ela não deve reter.
A questão útil não é se a privacidade ou a gerenciabilidade importa mais no abstrato. É se o caminho de DNS escolhido oferece aos usuários a confidencialidade adequada, permitindo ao mesmo tempo que a organização cumpra suas responsabilidades declaradas.
Por que o DoH enfraquece a filtragem de DNS no WiFi compartilhado
Um hotel fornece aos hóspedes o número da recepção para ajudar a encontrar serviços locais. A maioria dos hóspedes liga para a recepção, mas outro hóspede usa um aplicativo de diretório. A recepção pode controlar suas próprias recomendações, mas não as respostas fornecidas por esse aplicativo.
O DNS da rede funciona de maneira semelhante. A sua rede fornece um resolvedor, mas um navegador com a sua própria configuração de DoH pode, em vez disso, consultar um serviço externo.
A ilustração mostra essa rota alternativa ao redor do balcão de DNS da rede.
O bypass é sobre a rota
O problema não é que uma consulta criptografada nunca possa ser filtrada. É que seu filtro não pode aplicar políticas a uma consulta que ele nunca recebe.
Em uma rede de convidados de uma atração familiar, isso pode significar que um bloqueio de conteúdo adulto não se aplica a um navegador específico. Em uma rede de funcionários, um aplicativo malicioso pode resolver um domínio de comando e controle por meio de um resolvedor não aprovado.
As consequências dependem de quais controles se baseiam em DNS:
- Políticas específicas por rede. Regras atribuídas a um SSID ou VLAN não governarão consultas enviadas fora do caminho do resolvedor aprovado.
- Restrições de busca. A aplicação do Safe Search baseada em DNS pode ser ignorada, embora as restrições em nível de conta ou ponto de extremidade ainda possam ser aplicadas.
- Bloqueio de ameaças. Um filtro DNS não pode recusar uma consulta não vista, mesmo que sua lista de ameaças contenha o domínio solicitado.
Um estudo de medição da implementação de DNS criptografado relata telemetria do Firefox na qual aproximadamente 13,91% de 9,54 trilhões de handshakes de desktop usaram DoH durante 2025. Ele também descreve um conjunto de dados de medição no qual o DoH foi aproximadamente 6,4 vezes mais prevalente que o DoT.
Essas observações não estabelecem a proporção de dispositivos que ignoram o filtro do seu local. Padrões do navegador, implantação regional, compatibilidade do resolver e políticas do administrador afetam se o DoH está ativo.
Testa a cobertura em vez de apenas presumi-la
Um bloqueio bem-sucedido no laptop de um funcionário não garante uma cobertura equivalente no celular pessoal de um visitante. Os dispositivos podem usar navegadores, configurações de DNS ou túneis diferentes.
Trate seu filtro de conteúdo WiFi como um controle com um caminho de tráfego definido. Teste esse caminho usando os dispositivos e aplicativos que seus visitantes trazem consigo.
A filtragem baseada apenas no resolvedor fornecido pela rede não oferece mais cobertura completa por padrão. Ela precisa de controles de suporte e de uma avaliação transparente do que permanece fora da política.
O que o DoH custa em velocidade e o que a filtragem ainda faz
A criptografia adiciona processamento, mas a questão prática é se os usuários percebem uma sessão mais lenta. A configuração inicial da conexão e as consultas repetidas têm custos diferentes, portanto, testar uma única requisição nova pode fornecer uma impressão enganosa.
Uma comparação empírica de transportes DNS relatou respostas UDP e TLS abaixo de 1 milissegundo em sua linha de base local sem atraso, enquanto o HTTP/2 permaneceu consistentemente abaixo de 10 milissegundos; os resultados abaixo mantêm o contexto experimental do estudo em vez de prever o desempenho no local.
Latência de consulta DNS por protocolo no estudo citado
| Protocolo | Resultado reportado | Contexto |
|---|---|---|
| UDP | Abaixo de 1 ms | Linha de base local sem atraso |
| TLS | Abaixo de 1 ms | Linha de base local sem atraso |
| HTTP/2 | Abaixo de 10 ms, consistentemente | A reutilização de conexão e a multiplexação ajudam a reduzir a sobrecarga |
| HTTP/1.1 | Oscila substancialmente | Atribuído a limites de pipelining |
| DoH público versus DNS tradicional | Mais lento por nome | Nenhum aumento significativo no tempo total de carregamento da página foi observado |
Meça a sessão, e não apenas o handshake
Conexões persistentes permitem que o cliente distribua os custos de configuração entre consultas posteriores. A multiplexação permite lidar com múltiplas trocas sem estabelecer uma conexão segura separada para cada pergunta.
O filtro de DNS ainda pode recusar um domínio antes que uma nova conexão seja iniciada, desde que a solicitação alcance o resolvedor de filtragem. O bloqueio de anúncios e rastreadores pode reduzir solicitações subsequentes, mas a criptografia por si só não remove anúncios nem acelera uma página.
Acompanhe os sinais operacionais que revelam problemas reais:
- Falhas de handshake. Procure erros de configuração de conexão e tentativas de rediscagem.
- Taxas de cache hit. Separe as respostas em cache da resolução recente.
- Tempo de resposta do resolvedor. Meça o comportamento durante sessões de visitantes movimentadas.
- Comportamento de fallback. Verifique se as falhas fazem com que os dispositivos parem de resolver ou mudem para outro caminho sem aviso prévio.
Regra prática: Teste a navegação, a aplicação de políticas e a recuperação de falhas juntos, e não como verificações de aceitação separadas.
Um endpoint de resolvedor próximo e resiliente é um ponto de partida melhor do que escolher um protocolo baseado apenas em suposições de latência. Confirme o resultado em sua rede sob uma carga de tráfego realista.
Verifique e altere o DoH em dispositivos comuns
Uma configuração do navegador pode explicar por que dispositivos na mesma rede WiFi se comportam de maneira diferente. Rótulos de menu mudam entre versões, portanto, use a pesquisa das Configurações se o caminho abaixo não estiver visível.
Inspecione o navegador e o sistema operacional
- Chrome: Abra Configurações, Privacidade e segurança, Segurança e, em seguida, Usar DNS seguro. Verifique se ele segue o provedor atual ou especifica outro serviço.
- Firefox: Abra Configurações, Privacidade e Segurança e, em seguida, DNS sobre HTTPS. Revise o modo de proteção, incluindo Desativado, Proteção padrão ou Proteção máxima, e o resolvedor selecionado.
- Edge: Abra Configurações, Privacidade, pesquisa e serviços, Segurança e, em seguida, Usar DNS seguro. A política gerenciada pode bloquear essa configuração.
- Android: Abra Configurações, Rede e internet e, em seguida, DNS privado. Essa configuração usa DoT em vez de DoH; o DNS seguro no nível do navegador precisa de uma verificação separada.
- iOS e macOS: Inspecione os perfis de configuração instalados, as configurações de gerenciamento de dispositivos e os aplicativos relacionados ao DNS. Um perfil de DNS criptografado pode operar independentemente do navegador.
Verifique o caminho efetivo
Uma VPN de sistema pode transportar o DNS por meio do seu próprio túnel, independentemente da configuração do navegador. Verifique também se um aplicativo fornece um serviço de DNS criptografado separado.
Confirme qual resolvedor recebe uma nova busca de teste a partir do navegador ou aplicativo real. Use diagnósticos do navegador ou um teste de identificação de resolvedor junto com os logs do resolvedor aprovado, em vez de confiar apenas na tela de configurações.
Escolha e aplique seus controles DoH em camadas
Aplique controles em camadas de acordo com a propriedade do dispositivo e a necessidade de políticas. Laptops gerenciados de funcionários podem seguir uma configuração imposta; celulares pessoais de visitantes geralmente não podem. Aplicar as mesmas restrições a ambos os grupos gera brechas evitáveis ou interrupções desnecessárias.
Você pode permitir DoH externo e aceitar uma visibilidade reduzida do DNS local, restringi-lo e aceitar riscos de compatibilidade, ou combinar políticas para dispositivos gerenciados com controles seletivos na rede de visitantes. A abordagem em camadas oferece uma definição mais clara do que está protegido e do que não está.
Mapeie cada controle para seu escopo real
Os controles de rede são úteis, mas não tornam todos os resolvers criptografados identificáveis. Um resolver privado, um endereço em mudança ou um túnel VPN podem burlar premissas baseadas em uma lista de serviços conhecidos.
Controles para DoH em redes compartilhadas e gerenciadas
| Controle | O Que Ele Impede | Onde Se Aplica | Trade-off |
|---|---|---|---|
| Bloquear porta de saída 853 | DNS over TLS na porta padrão | Firewall ou gateway | Não afeta o DoH sobre HTTPS comum |
| Forçar porta 53 para o resolvedor da rede | Bypass de DNS simples | Aplicação no gateway, suportada por configuração DHCP | Ignora o DoH completamente; o DHCP sozinho não força a conformidade |
| Bloquear endereços de resolvedores DoH públicos conhecidos | Conexões com resolvedores listados | Firewall ou gateway compatível | As listas ficam desatualizadas, novos resolvedores aparecem e alguns aplicativos param de funcionar |
| Desativar o DoH do navegador por política gerenciada | Bypass no nível do navegador nos navegadores abrangidos | Laptops gerenciados e dispositivos de funcionários | Não consegue alcançar telefones pessoais na WiFi de visitantes |
| Impor o resolvedor da rede por meio de MDM | Alterações de DNS não aprovadas cobertas pela política do dispositivo | Funcionários cadastrados e dispositivos corporativos | Requer cadastro e suporte da plataforma; visitantes ficam de fora |
| Aceitar o DoH e filtrar no endpoint | Nada do lado da rede | Apenas endpoints gerenciados | Dispositivos de visitantes permanecem fora da política de endpoint |
Bloquear o endereço de um resolvedor também pode bloquear serviços não relacionados hospedados nesse mesmo endereço. Evite tratar a categoria de DNS criptografado de um firewall como um inventário permanente e exaustivo.
Quando você precisar de controle além da resolução de domínio, avalie um secure web gateway juntamente com políticas de endpoint e de rede. Verifique os requisitos de implantação com cuidado, especialmente quando os dispositivos não forem de propriedade da organização.
Crie uma política operacional testável
Comece pelo serviço que você precisa fornecer. Uma rede de administração de funcionários, uma conexão de biblioteca pública e um espaço de atividades infantis podem razoavelmente precisar de restrições e explicações diferentes para os usuários.
Use esta lista de verificação de implantação:
- Liste as políticas necessárias. Identifique os SSIDs, VLANs e grupos de dispositivos que precisam de controles de conteúdo ou filtragem de ameaças e atribua um responsável para cada um.
- Separe os dispositivos gerenciados do BYOD de visitantes. Registre onde a política de navegador ou MDM pode ser aplicada e onde apenas os controles de rede estão disponíveis.
- Feche as rotas comuns de desvio de DNS. Onde sua política exigir, bloqueie o DoT de saída e restrinja o DNS tradicional ao resolvedor aprovado. Cubra ambas as famílias de endereços de rede suportadas.
- Aplique a política de navegador gerenciado. Configure o caminho de DNS aprovado e evite substituições não suportadas pelo usuário em equipamentos da equipe.
- Mantenha as restrições do resolvedor da rede de visitantes. Revise regularmente os endereços de resolvedores bloqueados, teste exceções e remova regras que causem bloqueios colaterais inaceitáveis.
- Publique um aviso claro para visitantes. Explique quais categorias são filtradas, quais informações da rede são registradas e quaisquer restrições ao uso de DNS criptografado ou VPN.
- Teste um dispositivo real em cada rede. Verifique sites permitidos, categorias bloqueadas, destinos de teste de segurança aprovados, falhas de resolvedor e comportamento de VPN.
Antes do lançamento: Uma página de bloqueio prova que uma solicitação específica foi filtrada, não que todos os aplicativos no dispositivo sigam a mesma rota.
Faça do DNS criptografado parte dos testes de aceitação
Para usar o Shield, você direciona o DNS da rede para o Shield. Nós respondemos a cada consulta de DNS na rede que protegemos, em todos os dispositivos, sem nada a ser desativado no dispositivo; portanto, caminhos de resolvedores externos e túneis devem ser incluídos no projeto de proteção da rede.
Antes de testar o Purple Shield, nosso especialista mostra como sua rede lida com VPNs e DNS criptografado. Use essa discussão para estabelecer quais solicitações alcançam o caminho de DNS protegido, quais controles o impõem e o que acontece quando um dispositivo tenta outra rota.
Defina critérios de aceitação antes de alterar o acesso de convidados. Um resolver aprovado, um processo de exceção documentado e testes repetíveis em dispositivos fornecem uma base mais sólida do que presumir que um filtro ativado veja tudo.
O Purple Shield oferece DNS de proteção, filtragem de conteúdo, defesa contra ameaças e bloqueio de anúncios sem a necessidade de instalar agentes nos dispositivos dos visitantes. Acesse o Purple Shield para agendar uma conversa pré-teste sobre seus SSIDs, políticas de filtragem e como sua rede lida com DNS criptografado e VPNs.