DNS Over HTTPS Explicado: Privacidade vs Filtragem de WiFi Pública
O DNS over HTTPS encripta as consultas no tráfego da porta 443. Saiba o que esconde, por que razão pode contornar a filtragem de WiFi e como as redes mantêm o controlo.
Published 26 de outubro de 2026
O DNS over HTTPS envia pesquisas DNS dentro de tráfego HTTPS comum na porta 443, encriptado entre o dispositivo e o resolvedor, tendo-se tornado um padrão IETF em 2018.
Ativou o fornecimento de filtragem de conteúdos no seu WiFi de convidados, mas o navegador de um convidado continua a abrir uma categoria que pensava ter bloqueado. O firewall está a funcionar, as definições de rede parecem corretas e outro dispositivo recebe 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á a funcionar.
Para operadores de locais e responsáveis de IT, esse é o problema central do DoH. Protege uma pesquisa enquanto esta viaja, mas a escolha do destino por parte do navegador também pode mover essa pesquisa para fora da política de filtragem da sua rede.
Índice
- O que significa DNS over HTTPS em termos simples
- Como uma consulta DoH viaja do dispositivo para o resolver
- Quem pode ver as suas consultas quando o DoH está ativo
- Por que o DoH enfraquece a filtragem de DNS em WiFi partilhado
- O custo do DoH em velocidade e o que a filtragem ainda faz
- Verificar e alterar o DoH em dispositivos comuns
- Escolher e sobrepor os seus controlos de DoH
O Que Significa DNS over HTTPS em Termos Simples
DNS over HTTPS, normalmente abreviado como DoH, transporta perguntas e respostas de DNS através de uma ligação web encriptada. Um resolver DNS é o serviço ao qual um dispositivo pede para traduzir um nome de domínio num endereço de rede.
Pense no DNS como uma lista telefónica. Antes de abrir uma ligação, uma aplicação precisa de um endereço, embora possa já ter uma resposta utilizável na sua cache. O DNS tradicional envia comumente essa pergunta num formato legível.
Um postal é uma analogia útil: qualquer pessoa que o manuseie pode ler a mensagem. O DoH coloca a questão num envelope selado e transporta-a dentro do mesmo tipo de carrinha de entrega utilizado para o tráfego web seguro comum.
Compare o transporte, não apenas a encriptação
DNS over TLS, ou DoT, também sela o envelope, mas utiliza uma entrada de entrega rotulada em separado. Isso faz com que o seu tráfego seja mais fácil de identificar por um operador de rede através da sua porta de destino.
O RFC 8484 da IETF, publicado em outubro de 2018, define a troca HTTPS do DoH, utilizando normalmente a porta 443, ao contrário do DNS tradicional na porta 53.
Comparação entre DNS tradicional, DNS over TLS e DNS over HTTPS
| Funcionalidade | 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, partilha a porta 443 com o tráfego web |
| Fácil de bloquear pela porta | Sim | Sim | Não, pelo menos 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 utilizada por sites seguros também interromperia o tráfego web legítimo, pelo que o DoH requer controlos mais seletivos.
A encriptação não decide o que é filtrado. Um resolvedor pode desencriptar um pedido DoH de entrada, aplicar uma política de conteúdos ou ameaças e devolver a sua resposta de forma segura. As questões importantes são quem opera esse resolvedor e de quem é a política que ele segue.
Mantenha esta comparação à mão quando analisar os controlos. Uma regra que lida com DNS tradicional ou DoT não lida automaticamente com DoH.
Como uma Pesquisa DoH Viaja do Dispositivo para o Resolvedor
Um estafeta precisa de um endereço antes de entregar uma encomenda. Da mesma forma, um navegador precisa de um endereço de destino antes de se poder ligar a uma página de reserva de hotel, a menos que já tenha essa resposta em cache.
Este diagrama acompanha a pesquisa desde o navegador até ao resolvedor e vice-versa.
Siga o pedido e a resposta
O navegador precisa de um endereço. Verifica se já possui uma resposta utilizável para o site de reservas. Uma correspondência na cache pode evitar por completo uma nova pesquisa, pelo que a rede local não verá uma troca de DNS para essa ação.
Cria uma pergunta de DNS. Se precisar de uma resposta nova, o navegador prepara uma consulta que contém o nome de domínio. Neste ponto, a pergunta ainda está dentro do dispositivo, não estando a viajar através do WiFi.
Seleciona o resolvedor DoH. O navegador prepara um pedido HTTPS para o seu resolvedor configurado. A rede local pode observar o endereço de destino e os metadados da ligação, mas não consegue ler diretamente o domínio dentro da mensagem DNS encriptada.
Estabelece ou reutiliza uma ligação segura. Se necessário, o dispositivo conclui um handshake TLS antes de enviar o pedido protegido. Com uma ligação HTTP persistente, as consultas subsequentes podem reutilizar essa ligação; a rede vê o tráfego encriptado, incluindo a sua temporização e tamanho.
O resolvedor devolve a resposta. O resolvedor processa a pergunta e coloca a resposta de DNS dentro de uma resposta HTTP encriptada. A rede pode ver o tráfego a regressar do resolvedor, mas não o conteúdo legível da resposta.
O navegador liga-se ao site. Utiliza o endereço devolvido para iniciar a ligação ao site. A rede local pode observar esse novo destino, o que é independente de ler a pergunta de DNS anterior.
Para mais detalhes sobre caching e resolução, a explicação de o que faz uma pesquisa de DNS separa o processo de localização do endereço da própria ligação ao website.
Identifique o ponto de filtragem
Para uma nova ligação que exija resolução DNS, a pesquisa ocorre antes de o conteúdo da página ser carregado. Isso dá a um resolvedor aprovado a oportunidade de recusar um destino bloqueado antes de o navegador se ligar.
Um navegador configurado de forma independente pode enviar essa decisão para outro local. O resolvedor do local fica então sem qualquer pergunta para avaliar.
O vídeo de apoio oferece outra forma de acompanhar o processo.
Quem Pode Ver as Suas Pesquisas Quando o DoH Está Ativo
O DoH não esconde a navegação de toda a gente. Protege a troca de DNS contra observadores comuns entre o dispositivo e o resolver escolhido, mas esse resolver tem de ler a pergunta para lhe responder.
Essa distinção é importante no WiFi partilhado. Um convidado pode razoavelmente pretender proteção contra interceções locais, enquanto um hospital ou uma escola precisam de ter a certeza de que os seus controlos de segurança e de ameaças continuam a aplicar-se.
O DoH altera a entidade em quem confia a atividade de DNS; não elimina a necessidade de confiar em alguém.
Separe a visibilidade de DNS da visibilidade de navegação
A tabela descreve a utilização comum de DoH sem um relay de privacidade adicional, VPN ou sistema de interceção. Ler uma mensagem DNS e inferir um destino a partir de outra atividade de rede são capacidades diferentes.
Quem pode ver as pesquisas de DNS quando o DoH está a ser utilizado
| Observador | Vê nomes de domínio | Vê que o DoH está em uso | Por que motivo é importante |
|---|---|---|---|
| Outros dispositivos na mesma WiFi | Não, não a partir da consulta encriptada | Raramente através do acesso comum entre pares | A leitura passiva da mensagem DNS está bloqueada |
| Rede do local ou do ISP | Não, não dentro da troca DoH | Muitas vezes, através do tráfego para um endereço de resolver conhecido | Os controlos de DNS locais não conseguem avaliar consultas enviadas para outro local |
| Websites que visita | Apenas o site a que se liga | Não apenas a partir da ligação ao website | Um site não recebe as suas consultas de DNS não relacionadas |
| Operador do resolver DoH | Sim, todas as consultas que recebe | Sim | Uma ligação direta expõe essas consultas juntamente com o seu endereço de origem |
| Fornecedor do navegador ou SO | Apenas se operar o resolver ou receber telemetria relevante | O software conhece o seu modo configurado; relatórios do fornecedor exigem telemetria | A configuração do software não é o mesmo que a visibilidade automática do fornecedor |
O resolver não vê necessariamente todas as pesquisas feitas pelo dispositivo. Outra aplicação pode utilizar um resolver diferente, e as respostas em cache podem não exigir qualquer consulta. Vê apenas os pedidos que lhe são enviados.
Da mesma forma, o fornecedor do navegador não recebe automaticamente o histórico de DNS apenas por fornecer o navegador. A operação do resolver, as definições do software e a recolha de telemetria são funções distintas.
Torne a decisão de confiança explícita
Para instalações geridas do Firefox, a documentação da política de DNS over HTTPS da Mozilla fornece controlos para a configuração do resolvedor e se os utilizadores a podem alterar. Essa é uma forma prática de alinhar o comportamento do navegador com a governação de DNS da sua organização.
Um local ou ISP pode, ainda assim, observar os endereços de destino, a hora da ligação e os volumes de tráfego. Outros metadados do protocolo também podem ajudar a identificar um site, pelo que uma consulta DNS encriptada não é uma promessa de navegação anónima.
Utilize uma avaliação de confiança rápida antes de aprovar um resolvedor:
- Identifique o operador. Determine qual a organização que recebe as consultas, em vez de confiar na etiqueta predefinida de um navegador.
- Leia os termos de retenção. Verifique que informações de consulta e ligação são armazenadas, durante quanto tempo e com que finalidade.
- Verifique a jurisdição e o acesso. Compreenda onde o operador processa as informações e quem as pode obter.
- Ajuste a visibilidade à responsabilidade. Decida quais os eventos de segurança que a sua equipa de TI precisa de investigar e quais os detalhes de navegação que não deve reter.
A questão útil não é se a privacidade ou a capacidade de gestão são mais importantes em abstrato. É se o caminho de DNS escolhido concede aos utilizadores a confidencialidade adequada, permitindo ao mesmo tempo que a organização cumpra as suas responsabilidades declaradas.
Por Que Razão o DoH Enfraquece a Filtragem de DNS em WiFi Partilhado
Um hotel fornece aos hóspedes o número da receção para ajudar a encontrar serviços locais. A maioria dos hóspedes liga para a receção, mas outro hóspede utiliza uma aplicação de diretório. A receção pode controlar as suas próprias recomendações, mas não as respostas fornecidas por essa aplicação.
O DNS de rede funciona de forma semelhante. A sua rede fornece um resolvedor, mas um navegador com a sua própria configuração de DoH pode, em alternativa, consultar um serviço externo.
A ilustração mostra essa rota alternativa em redor do serviço de DNS da rede.
O bypass está relacionado com a rota
O problema não é que uma consulta encriptada nunca possa ser filtrada. O problema é que o seu filtro não pode aplicar políticas a uma consulta que nunca recebe.
Numa rede de convidados de uma atração familiar, isso pode significar que o bloqueio de conteúdo adulto não se aplica a um navegador específico. Numa rede de funcionários, uma aplicação maliciosa poderia resolver um domínio de comando e controlo através de um resolver não aprovado.
As consequências dependem de quais os controlos que confiam no DNS:
- Políticas específicas da rede. As regras atribuídas a um SSID ou VLAN não irão governar perguntas enviadas fora do caminho do resolver aprovado.
- Restrições de pesquisa. A aplicação de Safe Search baseada em DNS pode ser contornada, embora as restrições ao nível da conta ou do ponto final ainda se possam aplicar.
- Bloqueio de ameaças. Um filtro de DNS não pode recusar uma consulta não vista, mesmo que a sua lista de ameaças contenha o domínio solicitado.
Um estudo de medição da implementação de DNS encriptado relata dados de telemetria do Firefox nos quais aproximadamente 13,91% de 9,54 biliões de handshakes em computadores utilizaram DoH durante 2025. Também descreve um conjunto de dados de medição no qual o DoH foi aproximadamente 6,4 vezes mais prevalente do que o DoT.
Essas observações não estabelecem a percentagem de dispositivos que contornam o filtro do seu local. As predefinições do navegador, a implementação regional, a compatibilidade do resolver e as políticas do administrador afetam a ativação do DoH.
Teste a cobertura em vez de a presumir
Um bloqueio bem-sucedido no portátil de um colaborador não garante uma cobertura equivalente no telemóvel pessoal de um convidado. Os dispositivos podem utilizar navegadores, definições de DNS ou túneis diferentes.
Trate o seu filtro de conteúdos de WiFi como um controlo com um caminho de tráfego definido. Teste esse caminho utilizando os dispositivos e aplicações que os seus visitantes trazem consigo.
A filtragem baseada apenas no resolvedor fornecido pela rede já não garante uma cobertura completa por predefinição. Necessita de controlos de suporte e de um registo transparente do que permanece fora da política de segurança.
O Que o DoH Custa em Velocidade e O Que a Filtragem Ainda Faz
A encriptação adiciona trabalho, mas a questão prática é saber se os utilizadores notam uma sessão mais lenta. A configuração inicial da ligação e as pesquisas repetidas têm custos diferentes, pelo que testar um único pedido novo pode dar uma imagem enganadora.
Uma comparação empírica de transportes DNS relatou respostas UDP e TLS abaixo de 1 milissegundo na sua linha de base local sem atraso, enquanto o HTTP/2 se manteve consistentemente abaixo dos 10 milissegundos; os resultados abaixo mantêm o contexto experimental do estudo em vez de prever o desempenho no local.
Latência da pesquisa de 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, de forma consistente | A reutilização de ligações e a multiplexagem ajudam a reduzir os custos adicionais |
| HTTP/1.1 | Oscila substancialmente | Atribuído aos limites de pipelining |
| DoH público versus DNS tradicional | Mais lento por nome | Não se observou um aumento significativo no tempo total de carregamento da página |
Meça a sessão, não apenas o handshake
As ligações persistentes permitem que um cliente distribua os custos de configuração por consultas posteriores. A multiplexagem permite tratar de múltiplas trocas sem estabelecer uma ligação segura separada para cada questão.
O filtragem de DNS ainda pode recusar um domínio antes do início de uma nova ligação, desde que o pedido alcance o resolver de filtragem. O bloqueio de anúncios e rastreadores pode reduzir pedidos subsequentes, mas a encriptação 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 da ligação e novas tentativas.
- Taxas de cache-hit. Separe as respostas em cache da resolução nova.
- Tempo de resposta do resolutor. Meça o comportamento durante sessões de convidados com elevado tráfego.
- 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 em conjunto, não como verificações de aceitação separadas.
Um endpoint de resolvedor próximo e resiliente é um melhor ponto de partida do que escolher um protocolo apenas com base em pressupostos de latência. Confirme o resultado na sua rede sob uma carga realista.
Verificar e Alterar o DoH em Dispositivos Comuns
Uma definição do navegador pode explicar por que razão dispositivos na mesma rede WiFi se comportam de forma diferente. As etiquetas dos menus mudam entre versões, por isso utilize a pesquisa das Definições se o caminho abaixo não estiver visível.
Inspecione o navegador e o sistema operativo
- Chrome: Abra as Definições, Privacidade e segurança, Segurança e, em seguida, Utilizar DNS seguro. Verifique se segue o fornecedor atual ou se especifica outro serviço.
- Firefox: Abra as Definições, Privacidade e Segurança e, em seguida, DNS sobre HTTPS. Analise o modo de proteção, incluindo Desativado, Proteção Padrão ou Proteção Máxima, e o resolutor selecionado.
- Edge: Abra as Definições, Privacidade, pesquisa e serviços, Segurança e, em seguida, Utilizar DNS seguro. A política gerida pode bloquear esta definição.
- Android: Abra as Definições, Rede e internet e, em seguida, DNS privado. Esta definição utiliza DoT em vez de DoH; o DNS seguro ao nível do navegador requer uma verificação separada.
- iOS e macOS: Inspecione os perfis de configuração instalados, as definições de gestão de dispositivos e as aplicações relacionadas com DNS. Um perfil de DNS encriptado pode funcionar independentemente do navegador.
Verifique o caminho efetivo
Uma VPN de sistema pode transportar DNS através do seu próprio túnel, independentemente da definição do navegador. Verifique também se uma aplicação fornece um serviço de DNS encriptado separado.
Confirme qual o resolver que recebe uma nova pesquisa de teste a partir do navegador ou aplicação real. Utilize diagnósticos do navegador ou um teste de identificação de resolver juntamente com os registos de resolvers aprovados, em vez de confiar apenas no ecrã de definições.
Escolha e Sobreponha os Seus Controlos DoH
Aplique controlos em camadas segundo a propriedade do dispositivo e a necessidade de política. Os portáteis geridos dos colaboradores podem seguir uma configuração imposta; os telemóveis pessoais dos convidados geralmente não podem. Aplicar as mesmas restrições a ambos os grupos cria falhas evitáveis ou interrupções desnecessárias.
Pode permitir DoH externo e aceitar uma visibilidade reduzida do DNS local, restringi-lo e aceitar riscos de compatibilidade, ou combinar a política de dispositivos geridos com controlos seletivos na rede de convidados. A abordagem em camadas oferece-lhe uma declaração mais clara do que está e do que não está protegido.
Corresponda cada controlo ao seu âmbito real
Os controlos de rede são úteis, mas não tornam identificável todos os resolvers encriptados. Um resolver privado, um endereço em alteração ou um túnel VPN podem anular as premissas criadas em torno de uma lista de serviços conhecidos.
Controlos para DoH em redes partilhadas e geridas
| Controlo | O que bloqueia | Onde se aplica | Compromisso |
|---|---|---|---|
| Bloquear a porta de saída 853 | DNS over TLS em porta padrão | Firewall ou gateway | Não afeta o DoH sobre HTTPS comum |
| Forçar a porta 53 para o resolvedor de rede | Desvio de DNS simples | Aplicação na gateway, suportada por configuração DHCP | Ignora o DoH por completo; o DHCP por si só não força a conformidade |
| Bloquear endereços de resolvedores DoH públicos conhecidos | Ligações a resolvedores listados | Firewall ou gateway com capacidade | As listas ficam desatualizadas, surgem novos resolvedores, algumas aplicações deixam de funcionar |
| Desativar o DoH do navegador por política gerida | Desvio ao nível do navegador nos navegadores abrangidos | Laptops geridos e dispositivos de funcionários | Não alcança telemóveis pessoais no WiFi de convidados |
| Impor o resolvedor de rede através de MDM | Alterações de DNS não aprovadas abrangidas pela política do dispositivo | Dispositivos corporativos e de funcionários registados | Requer registo e suporte da plataforma; os convidados ficam de fora |
| Aceitar o DoH e filtrar no endpoint | Nada do lado da rede | Apenas endpoints geridos | Os dispositivos de convidados permanecem fora da política do endpoint |
Bloquear o endereço de um resolvedor também pode bloquear serviços não relacionados alojados nesse mesmo endereço. Evite tratar a categoria de DNS encriptado de uma firewall como um inventário permanente e exaustivo.
Quando precisar de controlo para além da resolução de domínios, avalie um secure web gateway em conjunto com as políticas de rede e de pontos de extremidade. Verifique cuidadosamente os requisitos de implementação, especialmente quando os dispositivos não são propriedade da organização.
Crie uma política operacional testável
Comece pelo serviço que precisa de fornecer. Uma rede de administração de funcionários, uma ligação de biblioteca pública e um local de atividades infantis podem, razoavelmente, necessitar de restrições diferentes e de explicações diferentes aos utilizadores.
Utilize esta lista de verificação de implementação:
- Liste as políticas necessárias. Identifique os SSIDs, VLANs e grupos de dispositivos que necessitam de controlos de conteúdo ou filtragem de ameaças, e atribua um responsável a cada um.
- Separe os dispositivos geridos do BYOD de convidados. Registe onde a política do navegador ou MDM pode ser aplicada e onde apenas estão disponíveis controlos de rede.
- Feche as rotas normais de desvio de DNS. Onde a sua política o exigir, bloqueie o DoT de saída e restrinja o DNS tradicional ao resolver aprovado. Cubra ambas as famílias de endereços de rede suportadas.
- Aplique a política de navegador gerido. Configure o caminho de DNS aprovado e evite sobreposições não suportadas por parte dos utilizadores no equipamento da equipa.
- Mantenha as restrições do resolver da rede de convidados. Reveja regularmente os endereços de resolver bloqueados, teste exceções e remova regras que causem bloqueios colaterais inaceitáveis.
- Publique um aviso claro para convidados. Explique quais as categorias filtradas, que informações de rede são registadas e quaisquer restrições ao uso de DNS encriptado ou VPN.
- Teste um dispositivo real em todas as redes. Verifique sites permitidos, categorias bloqueadas, destinos de teste de segurança aprovados, falhas no resolver e comportamento da VPN.
Antes do lançamento: Uma página de bloqueio prova que uma pedido específico foi filtrado, não que todas as aplicações no dispositivo sigam a mesma rota.
Torne o DNS encriptado parte dos testes de aceitação
Para utilizar o Shield, deve apontar o DNS da rede para o Shield. Respondemos a todas as consultas de DNS na rede que protegemos, em todos os dispositivos, sem nada no dispositivo para desativar; por isso, os caminhos de resolvedores externos e de túneis devem ser incluídos no plano de proteção da rede.
Antes de testar o Purple Shield, o nosso especialista mostra como a sua rede lida com VPNs e DNS encriptado. Utilize essa discussão para estabelecer quais os pedidos que alcançam o caminho de DNS protegido, quais os controlos que 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 de dispositivos repetíveis fornecem uma base mais sólida do que presumir que um filtro ativado vê tudo.
O Purple Shield oferece proteção de DNS, filtragem de conteúdos, defesa contra ameaças e bloqueio de anúncios sem instalar agentes nos dispositivos dos convidados. Visite o Purple Shield para agendar uma conversa prévia ao teste sobre os seus SSIDs, políticas de filtragem e como a sua rede lida com DNS encriptado e VPNs.