Precisa de criptografar consultas DNS no seu ambiente Windows Server hoje? Este guia explica o status de suporte a DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT), como influenciar o roadmap e, principalmente, como habilitar DoH/DoT sem quebrar o Active Directory.
Resumo executivo: DoH/DoT no Windows Server
Organizações vêm adotando DoH e DoT para elevar a privacidade, cumprir regulações e mitigar spoofing ou inspeção indevida de DNS. No entanto, o papel DNS Server do Windows Server (incluindo 2022 e a pré‑versão 2025) ainda não atende consultas nativamente via DoH/DoT. A boa notícia é que existem padrões de arquitetura maduros que preservam o AD e permitem oferecer DoH/DoT a clientes internos e externos com controles de segurança, observabilidade e desempenho.
Pergunta
O papel DNS Server do Windows Server (incluindo as versões 2022 e a pré‑versão 2025) permite atender consultas usando DoH ou DoT? Caso não haja suporte, como inserir essa funcionalidade no roadmap?
Resposta / solução
| Situação | Detalhes |
|---|---|
| Suporte nativo | Inexistente até a pré‑versão pública do Windows Server 2025. |
| Roadmap oficial | Nenhuma indicação pública de que DoH/DoT entrará em releases próximas. |
| Ação recomendada | Registrar a demanda nos canais oficiais (Feedback Hub, Windows Insider Program, portal de feedback do Windows Server). A Microsoft prioriza recursos conforme o número e a qualidade dos votos. |
Por que DoH/DoT importa
- Privacidade e compliance: as consultas DNS passam por túneis TLS (porta 853 no DoT; HTTPS 443 no DoH), reduzindo a exposição a inspeção e requisitos de mascaramento de PII.
- Confiabilidade em cenários de rede complexos: DoH opera sobre HTTP/2 ou HTTP/3, atravessando middleboxes com maior previsibilidade; DoT simplifica o controle L4 e políticas de firewall.
- Integridade: o uso de TLS diminui riscos de spoofing e man-in-the-middle.
Alternativas enquanto o recurso nativo não chega
Abaixo, três caminhos práticos, com prós, contras e exemplos de configuração.
Proxy TLS/HTTPS na borda
Coloque um terminador de DoH/DoT entre os clientes e o seu DNS do Windows. Esse componente recebe as consultas criptografadas, valida TLS e encaminha a carga desemcapsulada ao Windows DNS (UDP/TCP 53). Existem dois padrões:
- DoT na borda → DNS/TCP para o Windows: um proxy L4 com terminação TLS (ex.: HAProxy em modo TCP ou Nginx
stream) aceita conexões na porta 853 e repassa o fluxo pós‑TLS ao backend 127.0.0.1:53 (TCP). É simples, estável e com baixa latência. - DoH na borda → DNS/UDP ou DNS/TCP para o Windows: utilize um componente consciente de DoH (ex.: dnsdist ou AdGuard Home/dnsproxy) que entende a rota
/dns-query, valida content-typeapplication/dns-messagee traduz para DNS padrão no backend.
Vantagens
- Preserva a infraestrutura existente do AD DS (zonas integradas, atualizações dinâmicas, GPOs e auditoria).
- Permite ativar DoH/DoT de forma incremental, por site ou por segmento de rede.
- Flexibilidade para políticas de acesso (mTLS, SNI, ACL por IP) e rate limiting.
Cuidados
- Certificados: use nomes FQDN estáveis no SAN (ex.:
dns.corp.exemplo) e gire chaves com automação. - Firewall: abra 443 (DoH) e/ou 853 (DoT); mantenha 53 interno apenas entre proxy e DNS do Windows.
- Observabilidade: registre métricas e logs no proxy e no DNS para correlação de latência e falhas.
Exemplo de configuração: HAProxy como terminador de DoT
# /etc/haproxy/haproxy.cfg (trecho)
global
maxconn 20000
tune.ssl.default-dh-param 2048
defaults
mode tcp
timeout connect 5s
timeout client 30s
timeout server 30s
log global
frontend dot\_in
bind :853 ssl crt /etc/ssl/private/dns.pem
default\backend win\dns\_tcp
backend win\dns\tcp
server win\_dns 127.0.0.1:53 check Como funciona: clientes falam DoT com o HAProxy; o HAProxy desemcapsula TLS e envia a mesma mensagem DNS (com enquadramento TCP) ao serviço DNS do Windows na porta 53/TCP.
Exemplo de configuração: Nginx stream como terminador de DoT
# /etc/nginx/nginx.conf (trecho)
stream {
upstream dns_tcp {
server 127.0.0.1:53;
}
server {
listen 853 ssl;
proxypass dnstcp;
ssl_certificate /etc/ssl/certs/dns.pem;
sslcertificatekey /etc/ssl/private/dns.key;
}
}
Exemplo de configuração: dnsdist servindo DoH e DoT
-- /etc/dnsdist/dnsdist.conf (trecho)
setACL({"10.0.0.0/8", "192.168.0.0/16"}) -- limite a clientes internos
newServer({address="127.0.0.1:53", name="win", qps=0})
addTLSLocal("0.0.0.0:853", "/etc/ssl/certs/dns.pem", "/etc/ssl/private/dns.key")
addDOHLocal("0.0.0.0:443", "/etc/ssl/certs/dns.pem", "/etc/ssl/private/dns.key",
{ paths={"/dns-query"} })
addAction(AllRule(), PoolAction(""))
\-- opcional: amostre e exporte métricas
carbonServer("127.0.0.1", 2003, "dnsdist") Exemplo de configuração: AdGuard Home / dnsproxy
# Exemplo minimalista com dnsproxy (engine do AdGuard Home)
Aceita DoH e DoT e encaminha para o Windows DNS local
dnsproxy \
--https-port 443 \
--tls-port 853 \
--upstream 127.0.0.1:53 \
--bootstrap 127.0.0.1:53 \
--all-servers
Quando preferir DoT vs. DoH?
- DoT facilita controle e troubleshooting L4; ótimo para redes corporativas e peering interno.
- DoH contorna proxies e middleboxes exigentes e funciona bem com HTTP/3; preferível para endpoints móveis ou filiais com NATs agressivos.
Servidores DNS de terceiros
Se você deseja disponibilizar DoH/DoT diretamente no servidor recursor, observe as opções a seguir (em VM, contêiner ou WSL2) e deixe o Windows Server responder apenas pelas zonas internas do AD.
| Software | Suporte DoH/DoT | Onde rodar | Uso típico |
|---|---|---|---|
| CoreDNS | Nativo (com plugins) | Contêiner, VM ou WSL2 | Recursor moderno; integra filtros, cache e forward por DoT/DoH a provedores externos. |
| BIND 9.18+ | Nativo | Linux/FreeBSD/WSL2 | Recursor/autoridade com recursos amplos; integra-se bem a dnsdist para DoH. |
| Knot Resolver | Nativo | Linux/contêiner | Alto desempenho e extensões em LUA; DoH/DoT maduros. |
| PowerDNS Recursor | Nativo | Linux/contêiner | Excelente telemetria; frequentemente combinado com dnsdist na borda. |
Topologia recomendada: mantenha o Windows DNS como autoridade das zonas do AD (_msdcs, SRV, etc.) e aponte suas forwarders para o recursor de terceiros (que falará DoH/DoT externamente). Para clientes, publique o terminador DoH/DoT e/ou o recursor de terceiros como alvo preferencial; o Windows DNS continua atendendo internamente as zonas do AD sem criptografia na LAN, mas o salto para a internet passa a ser cifrado.
Serviços DNS gerenciados
- Provedores públicos como Cloudflare, Google Public DNS e Quad9 já expõem DoH/DoT; podem ser configurados como forwarders seguros a partir do seu terminador ou recursor.
- Combine com split DNS para manter as zonas internas no AD e somente recursão externa no serviço gerenciado.
Integração com Active Directory sem dores
O segredo é separar funções:
- Autoridade interna: o Windows DNS continua como autoridade para as zonas AD‑integrated e aceita atualizações dinâmicas dos controladores e clients.
- Recursão/saída segura: um recursor com DoH/DoT (ou um terminador proxy) lida com consultas externas. Use Conditional Forwarders ou Forwarders padrão no Windows para enviar “All other DNS queries”.
- Publicação para clientes: via DHCP ou GPO, aponte os endpoints ao serviço DoH/DoT interno (nome e portas) ou mantenha o DNS do Windows e deixe o path de saída cifrado pelo terminador.
Checklist de configuração no Windows DNS
- Em DNS Manager → Server Properties → Forwarders, aponte para o IP do seu recursor/terminador.
- Em Advanced, confirme Enable recursion conforme sua estratégia (recursão local vs. forward-only).
- Crie Conditional Forwarders para domínios parceiros, se necessário.
- Restrinja a escuta do serviço a interfaces internas; o proxy/terminador atende clientes.
- Audite logs de consultas e events de DNS para correlação com o proxy DoH/DoT.
Segurança, desempenho e observabilidade
| Tópico | Recomendações |
|---|---|
| Certificados e TLS | Use TLS 1.2+ e preferencialmente 1.3; renove certificados automaticamente; inclua FQDNs em SAN; se expor externamente, considere mTLS para segmentos sensíveis. |
| Firewall e NAC | Abra 443/853 apenas aos blocos de clientes; feche 53 externo; mantenha 53 interno entre proxy e DNS do Windows. |
| Latência e cache | Mensure p95/p99; ative cache consistente no recursor; posicione terminadores próximos dos endpoints (site‑aware). |
| Alta disponibilidade | Implemente pelo menos dois terminadores por site com health-checks e failover; para DoH, suporte HTTP/2 e HTTP/3. |
| Telemetria | Coleta de métricas (QPS, tempo de resolução, taxas de TLS, erros por código); logs de consultas com anonimização conforme LGPD/GPDR. |
| Resiliência | Defina política de fail-open vs. fail-closed; avalie circuit breakers entre proxy e Windows DNS. |
Boas práticas ao enviar feedback à Microsoft
| Passo | Porquê |
|---|---|
| Descrever cenário de uso | Demonstra valor de negócio (privacidade, compliance, mitigação de spoofing) e casos concretos (filiais, home office, BYOD). |
| Quantificar impacto | Número de endpoints beneficiados, requisitos regulatórios, ganho esperado (ex.: reduzir 80% de inspeção indevida de DNS). |
| Engajar comunidade | Mais votos elevam a prioridade interna da equipe de produto. |
Modelo de mensagem para Feedback Hub
Título: Habilitar atendimento nativo a DoH/DoT no papel DNS Server
Cenário: Ambiente AD com N endpoints distribuídos em S sites. Necessidade de cifrar consultas DNS cliente <> servidor para atender {regulação/compliance}, reduzir spoofing e evitar inspeção indevida.
Impacto: X% dos endpoints já suportam DoH/DoT. Implementar nativamente no DNS Server reduziria complexidade (menos proxies), melhoraria observabilidade e facilitaria governança via GPO.
Métricas de sucesso: 1) Suporte a DoH (HTTP/2/3) e DoT (TLS 1.2/1.3); 2) Políticas por interface/zona; 3) Logs e contadores por protocolo; 4) Compatibilidade com zonas AD-integrated. Testes rápidos e validação
- Testar DoT:
openssl sclient -connect dns.exemplo.corp:853 -tls13 -briefdeve mostrar handshake ok; em seguida,kdig @dns.exemplo.corp +tls A www.exemplo.comdeve retornar resposta válida. - Testar DoH: com uma ferramenta que suporte HTTP/2/3, envie
application/dns-messageparahttps://dns.exemplo.corp/dns-query; com dnsdist, observe contadores de acertos/erros. - Failover: desligue um terminador e confirme que o cliente alterna para o secundário sem perda perceptível.
FAQ
Posso expor DoH/DoT diretamente do Windows DNS?
Não no estado atual. Use um terminador/proxy ou um recursor de terceiros.
Devo permitir DoH “direto à internet” nos endpoints?
Em ambientes corporativos, prefira enforcement via GPO para apontar os clientes ao seu resolver corporativo com DoH/DoT, garantindo política e auditoria centralizadas.
Existe perda de desempenho?
Há sobrecusto de TLS, mas com conexão persistente, HTTP/2/3 e cache adequado, o impacto tende a ser pequeno. Posicione terminadores próximos aos usuários e habilite TCP Fast Open/QUIC quando disponível.
E se eu só quiser cifrar a “saída” para a internet?
Use um proxy do tipo egress (ex.: cloudflared como cliente DoH ou um recursor com forward via DoT) entre seu DNS interno e provedores públicos. Os clientes continuam falando DNS “tradicional” com o Windows, mas o salto externo fica cifrado.
Recomendações finais
- Segurança: se implementar proxy ou servidor de terceiros, garanta políticas de firewall e TLS corretas, além de certificados confiáveis.
- Latência e cache: avalie impactos de performance ao introduzir camadas adicionais ou servidores externos.
- Monitoramento: acompanhe anúncios em eventos como o Microsoft Ignite e notas de versão das futuras builds de 2025. Instrumente o ambiente desde o primeiro dia e acompanhe erros por código DNS e por estágio (handshake TLS, HTTP/2/3, recursão).
Arquiteturas de referência
| Arquitetura | Descrição | Quando usar | Pontos de atenção |
|---|---|---|---|
| Terminador DoT → Windows DNS | Proxy L4 com TLS na 853, back-end 53/TCP local. | Ambientes que preferem simplicidade L4 e baixa latência. | Garantir que clientes usem TCP para consultas grandes; ajustar timeouts. |
| Terminador DoH → Windows DNS | dnsdist ou AdGuard Home recebe /dns-query e traduz. | Ambientes com middleboxes restritivos; endpoints móveis. | Gerenciar HTTP/2/3, cabeçalhos, buffers e métricas. |
| Recursor de terceiros | BIND/Knot/PowerDNS/CoreDNS com DoH/DoT nativos. | Times com skills Linux e necessidade de controles avançados. | Operação adicional (patching, hardening e observabilidade). |
| Serviço gerenciado | Encaminhar recursão a provedores públicos via DoH/DoT. | Quando o foco é reduzir run e acelerar adoção. | Governança de dados, latência WAN e dependência de terceiros. |
Plano de implantação em quatro fases
- Descoberta & desenho: inventarie quem resolve o quê; defina nomes e certificados para os terminadores; selecione a arquitetura.
- Piloto controlado: implemente um par de terminadores; ative para um OU de testes; colete métricas e compare latências.
- Escalonamento: propague por site; automatize deploy e rotação de certificados; amplie monitoramento.
- Endurecimento: ajuste quotas/QPS, ACLs, listas de domínios sensíveis, proteção contra amplificação e limites de payload.
Conclusão
Embora o Windows DNS ainda não atenda nativamente por DoH/DoT, é totalmente viável oferecer criptografia de consultas hoje mesmo, sem reescrever sua base de AD. A estratégia com terminadores na borda ou recursão terceirizada preserva compatibilidade, melhora postura de segurança e prepara o caminho para uma eventual adoção nativa — enquanto você influencia o roadmap com feedbacks de alto impacto.