Zero Trust DNS: Controlo de Destinos por DNS no Windows 11

Uma política de filtragem DNS só protege enquanto o endpoint a respeitar. O dispositivo pode ficar apontado a outro servidor DNS, uma aplicação pode trazer um cliente DNS encriptado próprio que ignora o resolver da organização e o malware pode ligar-se directamente por endereço IP, sem resolver nome nenhum. O servidor DNS protegido continua a filtrar as consultas que lhe chegam, mas quem decide se elas lhe chegam é o dispositivo.

O Zero Trust DNS (ZTDNS) ataca exactamente este buraco. É uma funcionalidade nativa do Windows 11 Enterprise e do Windows 11 Education, anunciada em disponibilidade geral pela Microsoft em 2025, que integra o cliente DNS do Windows com a Windows Filtering Platform (WFP): bloqueia todo o tráfego IP de saída por defeito e só deixa passar destinos resolvidos por servidores DNS protegidos de confiança, através de DoH (DNS over HTTPS) ou DoT (DNS over TLS), ou aprovados manualmente pelo administrador (Microsoft Learn).

Este guia percorre a configuração completa numa máquina de teste: requisitos e licenciamento, adição do servidor DNS protegido, excepções de IP, activação em modo auditoria, leitura dos registos no Event Viewer e só depois o modo de aplicação efectiva. Tudo com o netsh, sem instalar nada — o ZTDNS vem integrado no sistema nas edições certas.

Neste artigo

1. Como o Zero Trust DNS Funciona no Dispositivo
2. Requisitos: Edições, Licenciamento e Servidor DNS Protegido
3. Passo 1 — Adicionar o Servidor DNS Protegido com DoH ou DoT
4. Passo 2 — Excepções para Aplicações que Não Usam DNS
5. Passo 3 — Activar o Modo Auditoria e Ler os Registos
6. Passo 4 — Activar o Modo de Aplicação (Enforcement)
7. Exportar, Replicar e Reverter a Configuração
8. O que o ZTDNS Quebra e Como Contornar
9. Erros Comuns
10. Checklist

1. Como o Zero Trust DNS Funciona no Dispositivo

O ZTDNS segue o princípio “negar por defeito, permitir por excepção e por tempo limitado”. Quando activo, o Windows bloqueia todo o tráfego de saída em IPv4 e IPv6, com três excepções logo no arranque: as ligações aos servidores DNS protegidos configurados, os intervalos IP aprovados manualmente pelo administrador e o tráfego essencial de descoberta de rede (DHCP, DHCPv6 e NDP). Tudo o resto fica bloqueado na Windows Filtering Platform antes de sair da máquina (Microsoft Learn).

O fluxo de tráfego passa a ser este: a aplicação pede um nome ao cliente DNS do Windows, o cliente envia a consulta por DoH ou DoT apenas aos servidores configurados como de confiança, e cada resposta com endereços IP cria uma excepção dinâmica para esses destinos, válida por tempo limitado. Só depois disso a ligação de saída é permitida. O tempo de vida desta lista dinâmica é controlado pelo parâmetro maxrecordage, com 86 400 segundos (24 horas) por defeito (referência dos comandos).

O gancho do mecanismo está no que fecha: resoluções de DNS que não venham do cliente do Windows não contam. Se uma aplicação usar o próprio cliente DNS (muitos browsers trazem um) ou ligar directamente a um IP fixo, a resposta ou o pacote nunca cria a excepção — e no modo de aplicação o tráfego é bloqueado. É isto que impede o contorno do servidor DNS da organização sem recorrer a inspecção profunda de pacotes ou a sinais em texto claro como o DNS simples ou o SNI (Server Name Indication), que são cada vez mais encriptados (Microsoft Learn).

Em contrapartida, as aplicações que descobrem destinos sem DNS precisam de atenção própria: os serviços Microsoft 365 com endereços fixos publicados e as aplicações de teleconferência que negociam IPs dentro de túneis TLS (WebRTC) exigem excepções manuais, cobertas no Passo 2.

2. Requisitos: Edições, Licenciamento e Servidor DNS Protegido

O direito de licenciamento vem com as licenças Windows Enterprise E3, Enterprise E5, Education A3 e Education A5 (Microsoft Learn). Não há nada a instalar: o ZTDNS faz parte do sistema nas edições Enterprise e Education mais recentes e está desactivado por defeito.

Do lado do servidor, o DNS protegido (PDNS, Protective DNS) tem de cumprir três requisitos (Microsoft Learn):

• DNS encriptado — tem de aceitar consultas por DoH ou por DoT.
• Aplicação de política — idealmente resolve apenas os nomes permitidos pela política da organização, com listas de permissão e bloqueio próprias.
• mTLS opcional — para políticas de resolução por cliente, pode aceitar autenticação mutua TLS com certificados de cliente.

No dispositivo, três pré-requisitos: a build mais recente do Windows 11 Enterprise ou Education, privilégios de administrador em todos os comandos e o servidor DNS encriptado alcançável a partir da máquina.

Falta um ajuste que a documentação marca como obrigatório: os navegadores têm de usar o cliente DNS do Windows em vez dos clientes DNS próprios. No Microsoft Edge e no Google Chrome, a política BuiltInDnsClientEnabled desactiva o cliente DNS interno do navegador (Microsoft Learn). Outras aplicações com clientes DNS próprios merecem a mesma revisão.

Quanto à gestão centralizada, no anúncio da disponibilidade geral, a Microsoft referia estar a desenvolver activamente uma experiência em Intune para o ZTDNS — à data da publicação desse anúncio, a configuração fazia-se por comandos netsh ou por ficheiro JSON. Antes de planear a gestão em Intune, confirmar na documentação actual do Intune se a experiência já está disponível (Microsoft Tech Community).

3. Passo 1 — Adicionar o Servidor DNS Protegido com DoH ou DoT

O primeiro passo é registar no ZTDNS os servidores a que o cliente DNS pode enviar consultas encriptadas. Para um servidor DoH:

netsh ztdns add server type=doh address=203.0.113.0 template=https://doh.resolver.example/dns-query priority=0

Para um servidor DoT, indicado como reserva do primeiro (Microsoft Learn):

netsh ztdns add server type=dot address=2001:db8::1 hostname=dot.resolver.example priority=1

A lista de servidores fica visível com:

netsh ztdns show server

O que cada parâmetro faz (referência dos comandos):

• type — protocolo encriptado da comunicação, doh ou dot.
• address — endereço IP do servidor. Pode ser IPv4 ou IPv6.
• template — modelo DoH do servidor, usado apenas no modo DoH (por exemplo https://doh.dominio.pt/dns-query).
• hostname — nome do servidor, usado apenas no modo DoT.
• priority — prioridade do servidor. A documentação diz que os de prioridade mais alta são consultados primeiro e o exemplo oficial rotula o servidor com priority=1 como reserva do principal, mas a própria documentação não descreve por extenso o comportamento de failover — validar num laboratório como o cliente escolhe entre servidores antes de contar com uma reserva garantida.
• port — opcional. Em falta, usa a porta por defeito do protocolo (no exemplo JSON da documentação, 853 para DoT e 443 para DoH).

Para validar antes de avançar: um ping ao endereço do servidor confirma alcançabilidade e um Resolve-DnsName -Name exemplo.pt -Server 203.0.113.0 confirma que responde a consultas. É o mesmo caminho que a documentação de troubleshooting recomenda (Microsoft Learn).

Dois avisos de configuração avançada, documentados como opcionais: o parâmetro set trustedca fixa os hashes dos certificados das autoridades certificadoras aceites para o certificado do servidor e o set clientcert configura o certificado de cliente para autenticação mTLS com políticas de resolução por dispositivo.

4. Passo 2 — Excepções para Aplicações que Não Usam DNS

Toda a aplicação que descubra destinos sem passar pelo DNS precisa de excepção manual, ou deixa de funcionar no modo de aplicação. Os casos documentados pela Microsoft são os serviços Microsoft 365 (Exchange, SharePoint, Teams e Office, com intervalos IP publicados na página oficial de URLs e endereços IP) e as aplicações de teleconferência como o Teams, que negoceiam os IPs dos pares dentro de um túnel TLS via WebRTC, sem visibilidade de DNS (Microsoft Learn).

Excepções de exemplo, com sub-redes de documentação (Microsoft Learn):

netsh ztdns add exception name=ServicosM365 description="Intervalos IP Microsoft 365" subnets=192.0.2.128/25,198.51.100.0/24
netsh ztdns add exception name=TeamsWebRTC description="Intervalos WebRTC do Teams" subnets=3fff::/48,3fff:123::/38

Inventário e limpeza das excepções:

netsh ztdns show exception
netsh ztdns delete exception name=TeamsWebRTC

O que cada linha faz:

• netsh ztdns add exception ... — adiciona um grupo de excepção com nome, descrição e sub-redes. O parâmetro subnets aceita endereços individuais e intervalos em notação CIDR, IPv4 e IPv6, separados por vírgulas. A partir daí, todo o tráfego de saída para esses destinos é permitido mesmo que o servidor de confiança nunca os resolva.
• netsh ztdns show exception — lista os grupos de excepção criados, cada um com o nome, a descrição e as sub-redes.
• netsh ztdns delete exception name=... — remove imediatamente o grupo indicado.

Aplicações internas com IPs fixos (um backup server, um ERP, um NAS) entram aqui da mesma forma. O modo auditoria do passo seguinte é o que revela exactamente que aplicações e destinos precisam destas excepções — anotar cada uma com a razão na description poupa o inventário futuro.

Dois cuidados com as excepções. Primeiro, as sub-redes destes exemplos são os espaços de endereçamento reservados para documentação (RFC 5737) e não representam serviços reais — em produção, substituí-las pelos intervalos reais do ambiente. Segundo, os intervalos do Microsoft 365 mudam com frequência — a página oficial publica as alterações e expõe os dados por um serviço web REST em JSON, pensado para scripts e dispositivos de rede consumirem as versões mais recentes, pelo que as excepções merecem revisão periódica (Microsoft Learn).

5. Passo 3 — Activar o Modo Auditoria e Ler os Registos

O ZTDNS tem dois modos de funcionamento e a documentação recomenda fortemente começar pelo modo auditoria: registam-se os bloqueios que aconteceriam, sem bloquear nada (Microsoft Learn).

netsh ztdns set state enable=yes audit=yes
netsh ztdns show state

O show state devolve o estado do serviço, incluindo o modo activo. Em auditoria, o comportamento esperado do ZTDNS fica registado sem cortar ligações, o que permite mapear os padrões de tráfego antes de qualquer impacto.

Os registos ficam no Event Viewer, em Applications and Service Logs > Microsoft > Windows > ZTDNS, com três categorias (Microsoft Learn):

O BlockedConnections é o mapa de trabalho da fase de auditoria: cada entrada é uma ligação que o modo de aplicação bloquearia. Identificar o processo, decidir se o destino é legítimo e criar a excepção ou confirmar que o domínio já é resolvido pelo servidor de confiança. Para validar que o caminho completo funciona, a sequência documentada é ping ao servidor, Resolve-DnsName -Name dominio.pt -Server 203.0.113.0 e depois ping ao domínio — a última usa o cliente DNS do Windows e o servidor de confiança de ponta a ponta (Microsoft Learn).

O PermittedConnections precisa de ser activado à mão (botão direito no registo, Enable Log) e vale o trabalho na validação final: confirma que as ligações esperadas passam e por que processos.

6. Passo 4 — Activar o Modo de Aplicação (Enforcement)

Com as excepções estabilizadas na auditoria, o modo de aplicação activa o bloqueio efectivo:

netsh ztdns set state enable=yes audit=no

A partir deste comando, todo o tráfego de saída para destinos fora das excepções dinâmicas e manuais é bloqueado, e o registo das ligações continua. A documentação recomenda reiniciar o dispositivo após activar: aplicações podem manter em cache endereços IP que o ZTDNS desconhece e ligações já estabelecidas fora da política (Microsoft Learn).

Quatro ajustes do set state merecem atenção nesta fase (referência dos comandos):

• maxrecordage — tempo máximo, em segundos, que um IP resolve pelo servidor de confiança permanece na lista de permissão dinâmica. O valor por defeito é 86 400 (24 horas). Intervalos mais curtos fecham mais depressa os destinos que deixaram de ser resolvidos.
• hostsfile — por defeito block, ou seja, os destinos do ficheiro hosts local não são permitidos. Com allow, as entradas do hosts passam a gerar tráfego permitido.
• localips — por defeito block para os endereços da própria máquina. Com allow, o tráfego para os endereços locais do dispositivo passa a ser permitido.
• forwarder — nem sequer se considera: é um parâmetro de teste, marcado pela Microsoft com “Don’t use it”, sem funcionalidade pronta. Fica aqui só para que ninguém o confunda com um ajuste suportado.

7. Exportar, Replicar e Reverter a Configuração

A configuração completa do ZTDNS (estado, servidores, excepções, certificados) sai em JSON com um comando e entra noutra máquina com outro (Microsoft Learn):

netsh ztdns show settings | Out-File ztdns_config.json
netsh ztdns set settings json=ztdns_config.json

O show settings devolve a configuração completa em JSON: os parâmetros de estado (enableZtdns, auditMode, maxRecordAge, allowHostsFile, blockLocalIps), as excepções em rules, os servidores em servers, cada um com protocolo, porta e prioridade, e os certificados. É a forma mais fiável de replicar a mesma configuração por vários postes de teste e de guardar o estado anterior a qualquer mudança.

No parâmetro de estado, o valor whenready merece nota para automatização: com enable=whenready, o ZTDNS activa-se sozinho quando os pré-requisitos estiverem cumpridos, por exemplo quando os certificados configurados ficarem instalados (referência dos comandos).

A reversão de emergência é um comando único, documentado como restauro imediato da conectividade normal:

netsh ztdns set state enable=no audit=no

Atenção ao caminho inverso: netsh ztdns delete server apaga todos os servidores de confiança de uma vez. Com o ZTDNS activo, o dispositivo fica sem servidores a quem fazer consultas até voltar a adicioná-los ou a desactivar o ZTDNS.

8. O que o ZTDNS Quebra e Como Contornar

O bloqueio por defeito alcança também serviços legítimos que descobrem destinos fora do DNS, e a página oficial de considerações do ZTDNS lista os impactos com os respectivos contornos (Microsoft Learn):

Duas famílias de tecnologias ficam fora do alcance do ZTDNS, e convém conhecê-las para não alimentar falsa sensação de cobertura total. As VPN e túneis SASE/SSE funcionam quando o gateway é resolvido pelo servidor de confiança, mas todo o tráfego em túnel aparece associado ao gateway — o controlo por nome tem de ser replicado no ponto de saída do túnel. E máquinas virtuais com pilha de rede própria ou tecnologias que contornam a WFP (XDP, DPDK) ignoram o ZTDNS, exigindo controlos próprios.

Erros Comuns

Checklist

• [ ] Build do Windows 11 Enterprise ou Education confirmada e licença E3, E5, A3 ou A5 atribuída
• [ ] Servidor PDNS com DoH ou DoT adicionado e alcançabilidade confirmada com ping
• [ ] Resolução de teste validada com Resolve-DnsName contra o servidor de confiança
• [ ] Política BuiltInDnsClientEnabled desactivada no Edge e no Chrome
• [ ] Excepções criadas para Microsoft 365, WebRTC do Teams e aplicações com IPs fixos
• [ ] Modo auditoria activado e registo BlockedConnections revisto até zero bloqueios inesperados
• [ ] Registo PermittedConnections activado para validação final
• [ ] Modo de aplicação activado com enable=yes audit=no
• [ ] Reinício do dispositivo feito após a activação
• [ ] Cada excepção documentada com nome, descrição e razão
• [ ] Plano de reversão anotado: netsh ztdns set state enable=no audit=no

Artigos Relacionados

• Zero Trust para PMEs em 2026: Implementar os 5 Pilares NIST com Entra ID e Cloudflare — o enquadramento dos pilares Zero Trust onde este controlo de destinos se encaixa
• Entra Internet Access: Zero Trust Web Filtering para PME — filtragem web Zero Trust no perímetro cloud, complemento do controlo ao nível do dispositivo
• AdGuard Home: Bloqueio de Anúncios e Malware via DNS para PME — filtragem DNS na rede local, a peça que o ZTDNS passa a fazer cumprir no endpoint
• DNS Públicos com Filtragem: Comparação dos Principais Providers em 2026 — resolvers com DoH e DoT e as suas políticas de filtragem
• Entra Private Access: Zero Trust a Apps Internas na PME — substituição da VPN por acesso Zero Trust, com o mesmo princípio de negar por defeito

Fontes Oficiais

• Zero Trust DNS — Microsoft Learn
• Deploying Zero Trust DNS — Microsoft Learn
• Zero Trust DNS commands — Microsoft Learn
• Troubleshooting Zero Trust DNS — Microsoft Learn
• Zero Trust DNS troubleshooting guidance — Microsoft Learn
• Considerations for running Zero Trust DNS — Microsoft Learn
• Zero Trust DNS is Here: Elevating Enterprise Security on Windows 11 — Microsoft Tech Community
• URLs e intervalos de endereços IP do Microsoft 365 — Microsoft Learn