DoH3, DoQ e DoT: o que muda no fim de 2025

Por CaptainDNS
Publicado em 1 de dezembro de 2025

#DNS
#DoH
#DoT
#DoQ
#Segurança

Esquema comparando DoH3, DoQ e DoT em uma arquitetura DNS moderna

TL;DR

DoT se tornou o alicerce amplamente implantado do DNS cifrado, enquanto DoH3 e DoQ levam o QUIC ao transporte das consultas.
No fim de 2025, cada vez mais sistemas operacionais, navegadores e resolvedores ativam DNS cifrado por padrão, reduzindo a visibilidade na porta 53 clássica.
Essas evoluções impactam diretamente a arquitetura DNS da empresa: resolvedores, firewalls, proxies, observabilidade e conformidade precisam ser ajustados.
A melhor abordagem não é “escolher um vencedor”, mas definir uma estratégia multitransporte: DoT como base, DoH3 e DoQ para casos em que latência, resiliência e mobilidade são críticos.

Contexto: do DNS em claro ao DNS cifrado

Por décadas, a resolução DNS ocorreu majoritariamente em claro, via UDP/TCP 53. Isso facilitava depuração e filtragem de rede, mas abria espaço para escuta, injeção de respostas e perfilagem massiva do tráfego.

Com a valorização da privacidade e a ubiquidade de TLS na web, o DNS seguiu a mesma trajetória: cifrar o “último milha” entre cliente (stub resolver) e resolvedor recursivo e, mais recentemente, adotar transportes modernos como QUIC.

No fim de 2025, três blocos estruturam o DNS cifrado no fluxo cliente → resolvedor: DoT, DoH (incluindo DoH3) e DoQ. Entender as diferenças é essencial para antecipar efeitos nas suas arquiteturas.

Lembrete rápido: DoT, DoH, DoH3 e DoQ

DNS clássico (UDP/TCP 53)

O DNS tradicional usa UDP 53 para a maioria das consultas, com fallback TCP 53 para transferências de zona (XFR) e respostas volumosas. É simples e rápido, mas totalmente em claro: um observador de rede pode ver os domínios resolvidos, injetar respostas falsas ou bloquear certas consultas.

DNS over TLS (DoT)

DoT encapsula o DNS em um fluxo TLS (geralmente em TCP 853) entre cliente e resolvedor. Padronizado no RFC 7858, ele busca impedir escuta e manipulação das consultas no caminho de rede.

Na prática, DoT:

usa um canal TCP/TLS dedicado (porta 853);
oferece propriedades de confidencialidade próximas às de um HTTPS “clássico”;
é amplamente suportado pelos grandes resolvedores públicos e por muitos resolvedores recursivos open source.

Hoje DoT é a base mais madura para DNS cifrado no lado de infraestrutura, principalmente por continuar conceitualmente próximo ao conhecido duo DNS + TLS.

DNS over HTTPS (DoH) e DoH3

DoH carrega as consultas DNS sobre HTTPS (RFC 8484), portanto na porta 443, em um canal HTTP/2 ou HTTP/3. A mensagem DNS fica no corpo da requisição HTTP, permitindo aproveitar toda a stack web: proxies HTTP, autenticação, CDN etc.

Quando DoH roda sobre HTTP/3 (que, por sua vez, usa QUIC), falamos de “DoH3”:

mesma semântica DNS do DoH;
mesma porta 443 do tráfego web, o que dificulta o filtro;
mesmos benefícios do QUIC: 0-RTT possível, melhor gestão de perdas, multiplexação eficiente.

DoH3 interessa especialmente a navegadores e algumas aplicações, pois permite ocultar o DNS no fluxo HTTPS existente e, ao mesmo tempo, aproveitar o QUIC.

DNS over QUIC (DoQ)

DoQ usa QUIC diretamente como transporte para o DNS, sem passar por HTTP. Definido no RFC 9250, ele busca combinar:

propriedades de confidencialidade semelhantes a um canal TLS (como DoT);
o desempenho e a resiliência do QUIC: sem head-of-line blocking no transporte, melhor recuperação em caso de perda de pacotes, suporte nativo a 0-RTT e mobilidade da conexão.

Na prática:

DoQ usa tipicamente a porta UDP 853, já historicamente associada a DNS-over-TLS/DTLS;
cada conexão QUIC pode carregar várias consultas DNS multiplexadas;
o protocolo é especialmente adequado a ambientes com latência variável (wifi denso, redes móveis etc.).

O que realmente muda no fim de 2025

A novidade não é a existência de DoT, DoH ou DoQ—todos padronizados há anos—mas seu nível de adoção e ativação por padrão.

Em resumo:

DoT é o “piso” do DNS cifrado para resolvedores recursivos e serviços gerenciados.
DoH é amplamente suportado por navegadores, SOs e bibliotecas aplicativas, com o modo HTTP/3 (DoH3) ganhando força.
DoQ sai do campo experimental e vira opção séria em vários servidores recursivos modernos, sobretudo em ambientes sensíveis à latência e à resiliência.

Essas tendências geram consequências concretas para as equipes de rede/DNS.

1. QUIC vira transporte DNS de primeira linha (DoH3 e DoQ)

A adoção de QUIC não se limita mais ao tráfego web: uma parcela crescente das resoluções DNS entre clientes e resolvedores passa agora por HTTP/3 (DoH3) ou por DoQ.

Impactos principais:

Latência: a combinação 0-RTT + ausência de head-of-line blocking no transporte melhora o tempo de resolução percebido, especialmente em redes com perda ou latência variável.
Estabilidade: QUIC lida melhor com troca de IP (roaming wifi ↔ 4G/5G), mantendo a conexão lógica.
Superfície de filtro: bloquear “o DNS” já não é só inspecionar UDP/TCP 53; é preciso considerar QUIC em 443 (DoH3) e UDP 853 (DoQ).

Em uma arquitetura corporativa, as decisões de filtragem DNS devem considerar os transportes, não apenas as portas históricas.

2. DNS cifrado vira padrão em SOs e navegadores

SOs modernos (desktop, mobile, servidor) já expõem opções nativas para ativar DoT ou DoH, às vezes no nível do sistema, às vezes por aplicação (navegador, cliente VPN, agente de segurança).

Consequências:

Alguns endpoints podem começar a contornar o resolvedor da empresa para consultar diretamente um resolvedor público em DoH3/DoT.
Dependendo da política, isso pode conflitar com exigências de logging, conformidade ou filtro (proxy de segurança, DLP etc.).
As equipes de TI precisam decidir claramente: quais fluxos são permitidos para resolvedores externos, em quais transportes e em quais casos?

3. Observabilidade e troubleshooting ficam mais complexos

Com DNS cifrado, não é mais possível inspecionar o conteúdo das consultas no nível de rede entre cliente e resolvedor sem uma terminação TLS/QUIC controlada.

Isso afeta:

ferramentas de captura/análise de tráfego (tcpdump, Wireshark, sondas NDR);
processos de debug “de emergência” (filtro inesperado, TTL incoerente, desvios de cache entre resolvedores internos e externos);
correlação entre logs DNS e logs aplicativos.

Abordagem recomendada: mover parte da observabilidade para o nível do resolvedor (logs estruturados, métricas, traces) em vez de depender apenas da camada de pacotes.

4. Implementações no servidor estão amadurecendo

Os grandes resolvedores recursivos open source (e comerciais) já trazem implementações estáveis de DoT, muitas vezes de DoH e, cada vez mais, de DoQ. Isso permite:

implantar um resolvedor interno ou “split-horizon” que aceite vários transportes (UDP/TCP 53, DoT, opcionalmente DoH/DoQ);
separar como os clientes se conectam de como você consulta os servidores autoritativos;
evoluir gradualmente os endpoints sem quebrar a arquitetura DNS como um todo.

Comparativo rápido DoT / DoH3 / DoQ

A seguir, uma tabela para posicionar esses três transportes no seu design.

Protocolo	Transporte subjacente	Porta típica	Multiplexação	Camuflado no tráfego web	Casos de uso típicos
DoT	TLS sobre TCP	853/TCP	Limitada ao fluxo TCP único	Não	Base de DNS cifrado entre clientes/forwarders e resolvedores corporativos ou públicos
DoH3	HTTP/3 (QUIC) sobre UDP	443/UDP	Sim, via HTTP/3	Sim (difícil de distinguir do HTTPS)	Navegadores, apps que querem se integrar à stack HTTP existente
DoQ	QUIC nativo sobre UDP	853/UDP	Sim, multiplexação QUIC	Não (mas lembra QUIC genérico)	Resolvedores recursivos modernos; ambientes sensíveis a latência e resiliência

Importante: nenhum deles substitui o DNSSEC (que protege a integridade dos dados DNS entre resolvedores e autoridades); eles complementam o DNSSEC ao proteger a confidencialidade e a integridade do transporte entre cliente e resolvedor.

Impactos arquiteturais na sua infraestrutura DNS

Fluxos DNS cifrados entre cliente, resolvedor da empresa e resolvedores públicos

Este diagrama mostra uma arquitetura típica no fim de 2025:

À esquerda, o cliente (endpoint, mobile, servidor) tem um stub resolver capaz de falar DNS clássico (UDP/TCP 53), DoT, DoH3 ou DoQ.
No centro, um ou mais resolvedores da empresa terminam esses transportes, aplicam cache, split-horizon e filtro.
À direita, os resolvedores públicos e os servidores autoritativos são alcançados via DNS clássico ou DNS cifrado, conforme a política.

A pergunta-chave passa a ser: quais fluxos cliente → resolvedor da empresa → resolvedores públicos são permitidos, cifrados e observáveis?

Resolvedores públicos vs. resolvedores da empresa

No fim de 2025, é comum que o mesmo endpoint possa:

usar o resolvedor interno da empresa em UDP/TCP 53 ou DoT;
em paralelo, consultar um ou mais resolvedores públicos em DoH3 ou DoQ por meio de apps específicos (navegador, agente de segurança, cliente VPN).

Decisões arquiteturais:

Os endpoints devem obrigatoriamente usar os resolvedores da empresa para todas as resoluções?
Os resolvedores da empresa vão expor DoT e/ou DoQ aos clientes internos?
Os fluxos DoH/DoH3 para resolvedores públicos são permitidos, bloqueados ou redirecionados (proxy, interceptação TLS controlada)?

Anycast, CDN e geolocalização

Com DNS cifrado, grandes resolvedores públicos usam intensamente Anycast e distribuem conexões QUIC/TLS conforme a localização do cliente. Isso pode gerar:

variações de resolução (diferentes pontos de entrada em CDN dependendo do IP de origem visto pelo resolvedor);
diferenças entre o que vê um cliente em DoH3/DoQ e outro em UDP 53 para um resolvedor distinto;
efeitos colaterais quando um proxy ou VPN altera o IP de origem.

Para apps sensíveis a latência ou geolocalização (vídeo, jogos, APIs críticas), pode valer a pena documentar claramente qual resolvedor é esperado e qual transporte é recomendado.

Observabilidade, logs e conformidade

Num cenário em que DNS é cifrado por padrão, a boa prática é:

centralizar logs no nível dos resolvedores (consultas, respostas, códigos de erro, tempos de resolução);
expor métricas (Prometheus, OpenTelemetry etc.) para acompanhar latência, falhas e volumes por transporte (UDP, DoT, DoH3, DoQ);
definir o que é registrado para respeitar LGPD/GDPR e políticas internas de privacidade.

Ou seja: em vez de “farejar a porta 53”, é preciso instrumentar os resolvedores.

Segurança e controle de acesso

Os controles de segurança precisam ser repensados:

filtragem de saída: quais portas/hosts são permitidos para DoT (853), DoQ (853/UDP), DoH3 (443/QUIC)?
segmentação: quais segmentos de rede podem sair para resolvedores públicos e quais devem obrigatoriamente passar por um resolvedor interno?
detecção: como identificar um endpoint que envia DNS cifrado não autorizado diretamente para a Internet?

Um design robusto normalmente combina:

um ou mais resolvedores internos expondo pelo menos DoT;
políticas claras (e aplicadas) sobre fluxos de DNS cifrado de saída;
monitoramento regular de tentativas de resolução “fora da política”.

Checklist técnica no fim de 2025

Esta checklist ajuda a avaliar rapidamente o nível de prontidão.

Camada	Ponto de controle	Pergunta a se fazer
Resolvedor interno	Suporte DoT (e eventualmente DoQ)	Meus resolvedores internos oferecem ao menos DoT para os clientes?
Firewall / proxy	Política sobre 53/853/443	Tenho regras explícitas para DNS cifrado (DoT, DoH3, DoQ) e não apenas para UDP/TCP 53?
Endpoints	Configuração de DNS	Quem controla as configurações DNS dos SOs e navegadores (GPO, MDM, scripts etc.)?
Observabilidade	Logs e métricas DNS	Consigo correlacionar uma falha de app com métricas de DNS cifrado (latência, timeouts, erros)?
Conformidade	Rastreabilidade	Tenho uma resposta clara para “quem resolveu o quê, quando e por qual resolvedor” respeitando a privacidade?

Também é possível baixar o comparativo em CSV (veja o bloco de download) para usá-lo em seus dashboards ou documentos internos.

Plano de ação recomendado para as equipes de infra

Mapear o que existe
- Quais resolvedores são usados (internos, externos)?
- Quais transportes já estão em produção (UDP/TCP 53, DoT, DoH, túneis VPN etc.)?
Definir um alvo claro
- DoT como base obrigatória entre endpoints e resolvedores internos.
- DoH3 e/ou DoQ ativados de forma controlada conforme o caso de uso (mobilidade, desempenho, restrições de aplicação).
Atualizar os resolvedores
- Ativar DoT prioritariamente, com certificados bem gerenciados.
- Avaliar DoQ em um ambiente piloto (latência, estabilidade, observabilidade).
Ajustar a filtragem de rede
- Formalizar uma política para fluxos de DNS cifrado de saída.
- Documentar exceções (relay DNS de parceiro, site remoto, agente de segurança).
Implantar observabilidade
- Centralizar logs DNS no nível dos resolvedores.
- Acompanhar volumes e latência por transporte (UDP, DoT, DoH3, DoQ).
Comunicar com os times de aplicação
- Explicar as mudanças (novas portas, novos resolvedores, possíveis comportamentos dos navegadores).
- Documentar boas práticas para escolha de resolvedores nas aplicações.
Testar regularmente
- Scripts ou jobs de monitoramento que testem resolução por cada transporte (UDP, DoT, DoH3, DoQ) para seus resolvedores principais.
- Analisar diferenças de latência e comportamento (timeouts, falhas esporádicas).

FAQ

Preciso migrar tudo para DoQ e abandonar DoT?

Não. DoQ não é uma substituição abrupta de DoT, e sim uma opção adicional. Na prática, a maioria das arquiteturas continuará multitransporte: UDP/TCP 53 para compatibilidade, DoT como base cifrada, DoH3 e/ou DoQ para perímetros específicos (mobilidade, desempenho, restrições aplicativas).

DoH3 e DoQ são mais seguros que DoT?

Em termos criptográficos, os três se baseiam em primitivas semelhantes (TLS ou QUIC sobre TLS) e oferecem um nível de confidencialidade comparável. As diferenças estão no transporte: multiplexação, gestão de perdas, camuflagem no tráfego web, capacidade de atravessar certos middleboxes.

Quais portas devo abrir nos firewalls para esses protocolos?

Em geral: DoT usa 853/TCP, DoQ 853/UDP, DoH/DoH3 a porta 443 (TCP e/ou UDP conforme HTTP/2 ou HTTP/3). É preciso pensar a política: abrir todas essas portas para a Internet permite que endpoints contornem os resolvedores internos.

DNS cifrado quebra meu filtro DNS atual?

Pode contorná-lo se endpoints falarem diretamente com resolvedores públicos em DoH3/DoT/DoQ. Por isso é crucial definir uma política clara: quais fluxos DNS cifrados são permitidos, quais devem obrigatoriamente passar por um resolvedor corporativo e como detectar desvios.

Como testar se meu resolvedor suporta DoT, DoH3 ou DoQ?

Em geral, cada implementação documenta comandos de exemplo (kdig, drill, curl para DoH ou clientes específicos DoQ). Você pode integrar esses testes em procedimentos de validação e scripts de monitoramento para garantir que cada transporte funcione como esperado.