MENU
  1. Início
  2. Windows
  3. Windows Server
  4. Windows DNS: exceção de encaminhamento para um único host com PowerShell (DNS Policies opcional)

Windows DNS: exceção de encaminhamento para um único host com PowerShell (DNS Policies opcional)

Windows Server

Precisa que apenas host1.abc.com aponte para um IP interno, enquanto todo o restante de *.abc.com continua indo para um forwarder externo? Veja como construir essa exceção com segurança, via PowerShell, e sem quebrar o encaminhamento existente.

Índice

Visão geral e objetivo

O cenário é comum em ambientes híbridos: seu servidor Windows DNS usa conditional forwarding para resolver abc.com em um servidor externo, mas um único nome — host1.abc.com — deve responder com um endereço IP interno. O desafio é fazer o override desse FQDN sem transformar o servidor em autoridade para todo o domínio (o que bloquearia o encaminhamento).

A solução mais simples e robusta é criar uma zona primária apenas para o subdomínio exato (host1.abc.com) e manter o conditional forwarder de abc.com. Em versões do Windows Server 2016 ou superiores, você pode opcionalmente empregar DNS Policies para cenários mais avançados (como respostas diferentes por localização de cliente) — mas, para o caso básico, as políticas não são obrigatórias.

Como o Windows DNS decide para onde enviar a consulta

Entender a ordem de decisão evita erros de design:

  • Correspondência mais específica vence: o DNS seleciona a zona cujo nome tem o sufixo mais longo que corresponde ao FQDN consultado. Ex.: a zona host1.abc.com tem precedência sobre abc.com.
  • Autoridade vs. Encaminhamento: se existir uma zona autoritativa local para abc.com, o servidor não usará o forwarder para esse domínio — responderá localmente (mesmo que o registro solicitado não exista).
  • Conditional forwarder: só é usado quando não há zona autoritativa local que cubra o FQDN.
  • Cache: respostas (inclusive falhas) são armazenadas por TTL. Ajuste o TTL dos registros de exceção para facilitar mudanças futuras.

Solução recomendada e direta (todas as versões)

Crie uma zona primária somente para o FQDN desejado (host1.abc.com), adicione o registro que aponta para o IP interno e mantenha o conditional forwarder de abc.com para o servidor externo. Assim, apenas o nome-alvo é respondido localmente; todo o restante continua sendo encaminhado.

Passo a passo em PowerShell

Execute como administrador no servidor DNS.


Variáveis
$HostFqdn   = "host1.abc.com"
$LocalIPv4  = "192.168.1.100"      # IP interno desejado
$Forwarders = @("203.0.113.10")    # Servidores externos autoritativos para abc.com (exemplo)

1) Criar a zona primária apenas para o FQDN alvo

if (-not (Get-DnsServerZone -Name \$HostFqdn -ErrorAction SilentlyContinue)) {
Add-DnsServerPrimaryZone -Name \$HostFqdn -ZoneFile "\$HostFqdn.dns" -ReplicationScope "Domain"
}

2) Adicionar o registro A no ápice (@) da subzona

if (-not (Get-DnsServerResourceRecord -ZoneName \$HostFqdn -RRType A -Name "@" -ErrorAction SilentlyContinue)) {
Add-DnsServerResourceRecord -ZoneName \$HostFqdn -A -Name "@" -IPv4Address \$LocalIPv4 -TimeToLive 00:05:00
}

3) Garantir o conditional forwarder para abc.com apontando ao(s) DNS externo(s)

if (-not (Get-DnsServerConditionalForwarderZone -Name "abc.com" -ErrorAction SilentlyContinue)) {
Add-DnsServerConditionalForwarderZone -Name "abc.com" -MasterServers \$Forwarders -ReplicationScope "Domain" -UseRecursion \$true
}

4) Limpar caches para testes previsíveis

Clear-DnsServerCache -Force

Importante: não crie uma zona abc.com local (primária, secundária ou stub) se deseja preservar o encaminhamento para esse domínio. A existência dessa zona tornará o servidor autoritativo para abc.com e bloqueará o forwarder.

Testes de validação


Deve retornar o IP interno definido para host1.abc.com
Resolve-DnsName host1.abc.com -Server <IPdoseu_DNS>

Deve ser encaminhado e resolvido pelo servidor externo

Resolve-DnsName [www.abc.com](http://www.abc.com) -Server \

Conferir de onde veio a resposta (campo "Server" e "Section")

Resolve-DnsName host1.abc.com -Server \ -Type A -DnsOnly -NoHostsFile

Boas práticas de produção

  • TTL: use TTL curto (ex.: 5–15 min) para o registro de exceção enquanto estabiliza a mudança; aumente depois, se necessário.
  • Replicação: prefira zonas integradas ao AD com -ReplicationScope adequado (Domain ou Forest) para consistência entre todos os DNS.
  • IPv6: se o ambiente usar IPv6, adicione também um AAAA correspondente.
  • PTR: se serviços internos dependem de reverso, crie o PTR na zona reversa correspondente.
  • Auditoria: documente a exceção (mudança, motivação, responsáveis e janela de rollback).

Uso opcional de DNS Policies no Windows Server 2016+

Quando usar: DNS Policies são úteis se você precisa diversificar a resposta do mesmo nome (por localização, horário, cliente, etc.). No nosso caso, você pode usá-las para variar o IP de host1.abc.com por site/filial. Elas não são necessárias para o objetivo principal (encaminhar todo *.abc.com exceto um host), e não “forçam” encaminhamento quando existe zona autoritativa para o domínio.

Exemplo: respostas diferentes para o mesmo host por subnet de origem

Mantendo a arquitetura recomendada (subzona apenas para host1.abc.com + forwarder de abc.com), crie zone scopes dentro da zona host1.abc.com e associe políticas por sub-rede.


Subnets de clientes
Add-DnsServerClientSubnet -Name "SiteA" -IPv4Subnet "10.10.0.0/16"
Add-DnsServerClientSubnet -Name "SiteB" -IPv4Subnet "10.20.0.0/16"

Zone scopes adicionais na zona do host

Add-DnsServerZoneScope -ZoneName "host1.abc.com" -Name "SiteA-Scope"
Add-DnsServerZoneScope -ZoneName "host1.abc.com" -Name "SiteB-Scope"

Registros A distintos por escopo

Add-DnsServerResourceRecord -ZoneName "host1.abc.com" -ZoneScope "SiteA-Scope" -A -Name "@" -IPv4Address "192.168.10.100"
Add-DnsServerResourceRecord -ZoneName "host1.abc.com" -ZoneScope "SiteB-Scope" -A -Name "@" -IPv4Address "192.168.20.100"

Políticas que mapeiam sub-redes aos zone scopes

Add-DnsServerQueryResolutionPolicy -Name "Host1-SiteA" -Action ALLOW -FQDN "eq,host1.abc.com" -ClientSubnet "eq,SiteA" -ZoneName "host1.abc.com" -ZoneScope "SiteA-Scope,1"
Add-DnsServerQueryResolutionPolicy -Name "Host1-SiteB" -Action ALLOW -FQDN "eq,host1.abc.com" -ClientSubnet "eq,SiteB" -ZoneName "host1.abc.com" -ZoneScope "SiteB-Scope,1"

Para demais clientes, o escopo padrão já contém o registro criado no passo principal (192.168.1.100)

Resultado: host1.abc.com responde com IPs diferentes conforme a origem do cliente, e todas as outras consultas de *.abc.com continuam sendo encaminhadas pelo conditional forwarder.

Limite importante sobre políticas:

DNS Policies operam sobre zonas autoritativas e sobre o conteúdo dos zone scopes. Elas não fazem “forward seletivo dentro de uma mesma zona. Por isso, para preservar o encaminhamento de abc.com, não crie uma zona abc.com local — mantenha apenas a subzona host1.abc.com.

Quadro de decisão

CenárioAbordagem recomendadaNotas
Windows Server 2012 R2 ou anteriorCriar zona primária host1.abc.com e manter o conditional forwarder de abc.com.Funciona sem DNS Policies. Não crie zona abc.com local.
Windows Server 2016+Mesma abordagem simples; use DNS Policies apenas se precisar de respostas diferentes para host1 por cliente/região.Políticas não fazem encaminhamento seletivo dentro de abc.com.
Ambiente híbrido público/privadoConditional forwarders + subzona do host excepcional; considere Split-DNS apenas se sua organização for autoridade de abc.com.Split-DNS exige governança rígida do conteúdo em todas as visões (interna/externa).

Checklist rápido

  • Confirmar versão do Windows Server e privilégios de administração.
  • Listar IP(s) do(s) forwarder(s) autoritativos para abc.com.
  • Escolher escopo de replicação da zona host1.abc.com (Domain/Forest).
  • Definir TTL inicial para o override.
  • Planejar rollback e janela de mudança.

Erros comuns e como evitar

  • Criar a zona abc.com local por engano: isso bloqueia o forwarder. Remova a zona ou reverta à configuração anterior.
  • Usar CNAME para redirecionar a autoridade: CNAME não direciona consulta ao forwarder; apenas aponta para outro nome.
  • Confiar no arquivo hosts: não é escalável, difícil de auditar e inconsistente entre clientes.
  • TTL longo demais: mudanças futuras ficarão “presas” no cache. Prefira TTL curto enquanto estabiliza.
  • Esquecer do IPv6: clientes dual-stack podem preferir AAAA. Publique o AAAA se necessário.

Plano de rollback

  1. Remover o registro A/AAAA do ápice da zona host1.abc.com.
  2. Remover a zona host1.abc.com (se ela só existir para esse override): Remove-DnsServerZone -Name "host1.abc.com".
  3. Limpar caches nos servidores DNS e nos clientes: Clear-DnsServerCache -Force e ipconfig /flushdns.

Exemplo completo e idempotente

O script abaixo cria/ajusta tudo que é necessário e não duplica objetos existentes.


param(
  [Parameter(Mandatory=$true)] [string] $HostName,      # "host1"
  [Parameter(Mandatory=$true)] [string] $DomainName,    # "abc.com"
  [Parameter(Mandatory=$true)] [string] $IPv4,          # "192.168.1.100"
  [Parameter(Mandatory=$true)] [string[]] $Forwarders,  # "203.0.113.10","203.0.113.11"
  [ValidateSet("Domain","Forest","Legacy")] [string] $ReplicationScope = "Domain",
  [TimeSpan] $Ttl = [TimeSpan]::FromMinutes(5)
)

\$Fqdn = "\$HostName.\$DomainName"

Write-Host "==> Criando zona \$Fqdn (se necessário)..."
if (-not (Get-DnsServerZone -Name \$Fqdn -ErrorAction SilentlyContinue)) {
Add-DnsServerPrimaryZone -Name \$Fqdn -ZoneFile "\$Fqdn.dns" -ReplicationScope \$ReplicationScope | Out-Null
}

Write-Host "==> Publicando registro A (@) em \$Fqdn..."
\$rr = Get-DnsServerResourceRecord -ZoneName \$Fqdn -RRType A -Name "@" -ErrorAction SilentlyContinue
if (\$rr) {

Atualiza se o IP mudou

if (\$rr.RecordData.IPv4Address.ToString() -ne \$IPv4 -or \$rr.TimeToLive -ne \$Ttl) {
Remove-DnsServerResourceRecord -ZoneName \$Fqdn -RRType A -Name "@" -Force
Add-DnsServerResourceRecord -ZoneName \$Fqdn -A -Name "@" -IPv4Address \$IPv4 -TimeToLive \$Ttl | Out-Null
}
} else {
Add-DnsServerResourceRecord -ZoneName \$Fqdn -A -Name "@" -IPv4Address \$IPv4 -TimeToLive \$Ttl | Out-Null
}

Write-Host "==> Garantindo conditional forwarder para \$DomainName..."
\$cfz = Get-DnsServerConditionalForwarderZone -Name \$DomainName -ErrorAction SilentlyContinue
if (-not \$cfz) {
Add-DnsServerConditionalForwarderZone -Name \$DomainName -MasterServers \$Forwarders -ReplicationScope \$ReplicationScope -UseRecursion \$true | Out-Null
} else {

Sincroniza lista de forwarders

\$needUpdate = @(\$cfz.MasterServers | ForEach-Object { $\_.IPAddressToString }) -join "," -ne (\$Forwarders -join ",")
if (\$needUpdate) {
Set-DnsServerConditionalForwarderZone -Name \$DomainName -MasterServers \$Forwarders -UseRecursion \$true | Out-Null
}
}

Clear-DnsServerCache -Force
Write-Host "Pronto. Teste com:  Resolve-DnsName \$Fqdn -Server \  e  Resolve-DnsName [www.\$DomainName](http://www.$DomainName) -Server \"

Tabela de comandos úteis

ObjetivoComandoObservações
Criar zona apenas para o FQDNAdd-DnsServerPrimaryZone -Name "host1.abc.com"Cria autoridade exclusivamente para o nome exato.
Adicionar registro AAdd-DnsServerResourceRecord -ZoneName "host1.abc.com" -A -Name "@" -IPv4Address "192.168.1.100"Use TTL curto inicialmente.
Conditional forwarderAdd-DnsServerConditionalForwarderZone -Name "abc.com" -MasterServers "203.0.113.10"Encaminha todas as demais consultas de *.abc.com.
Limpar cacheClear-DnsServerCache -ForceEvita resultados antigos durante testes.
Verificar resoluçãoResolve-DnsName host1.abc.com -Type AConfirma resposta interna.

Perguntas frequentes

Posso criar uma zona abc.com local e ainda assim encaminhar as outras entradas?

Não. Ao criar a zona abc.com, o servidor torna-se autoritativo para esse domínio e não usará o forwarder, respondendo localmente (ou com NXDOMAIN). Para preservar o encaminhamento, mantenha apenas a subzona host1.abc.com.

E se eu precisar administrar abc.com no futuro?

Quando (e se) sua organização tornar-se autoridade de abc.com, você migrará para uma zona autoritativa local (ou split-DNS com zone scopes), abandonando o forwarder. Planeje essa transição como um projeto à parte.

Qual é a ordem de checagem do servidor?

Primeiro o servidor procura a zona com sufixo mais específico (ex.: host1.abc.com), depois aplica cache e, na ausência de autoridade local, usa o conditional forwarder de abc.com.

Isso funciona com múltiplas exceções?

Sim. Crie uma subzona para cada FQDN que precisa de override (host2.abc.com, app-interno.abc.com, etc.). Se precisar de políticas por cliente para cada host, use DNS Policies e zone scopes dentro de cada subzona.

Como confirmar que a consulta foi encaminhada?

Use Resolve-DnsName www.abc.com -Server <IP_DNS> -DnsOnly e observe o servidor de origem da resposta. Você também pode habilitar logs analíticos do serviço DNS para rastrear encaminhamento.

Resumo final

Para criar uma exceção de encaminhamento em Windows DNS sem “quebrar” o fluxo atual, a abordagem segura é:

  1. Criar uma zona primária apenas para o FQDN (host1.abc.com), com o registro que aponta para o IP interno.
  2. Manter o conditional forwarder de abc.com para o servidor externo.
  3. Opcionalmente, aplicar DNS Policies em Windows Server 2016+ para variações do host1 por localização/cliente.

Com isso, você garante que somente host1.abc.com resolve internamente, enquanto todas as demais entradas de abc.com continuam sendo resolvidas pelo forwarder externo — de forma clara, reversível e documentada.

Windows Server
Conditional Forwarder DNS DNS Policies PowerShell Troubleshooting Windows Server
Índice