Configurar DNS Request Routes no Sophos Firewall

Com DNS Request Routes, pode definir em Sophos Firewall que servidor DNS deve ser usado para determinados domínios ou zonas inversas. Isto é especialmente útil quando a firewall usa servidores DNS públicos, mas os nomes internos têm de ser resolvidos através de um servidor DNS interno.

Exemplos típicos incluem domínios do Active Directory, aplicações internas, pesquisas reversas ou ambientes VPN.

Quando Sophos DNS Protection com Sophos Firewall é utilizado, as DNS Request Routes tornam-se ainda mais importantes. Domínios públicos seguem então para o serviço DNS Protection, enquanto domínios internos continuam a seguir para o servidor DNS local ou controlador de domínio. Sem esta separação, aplicações internas, autenticações AD ou pesquisas inversas podem parecer subitamente problemas de rede.

Orientação e desenho

As DNS Request Routes só funcionam de forma fiável quando está claro que resolvedor vê que consulta. Por isso, deve separar primeiro o desenho DNS, o DNS do cliente, as zonas internas e o caminho de routing.

Rota de Pedido DNS, Servidor DNS ou Opção DHCP?

As DNS Request Routes são frequentemente confundidas com servidores DNS globais ou opções DHCP. As funções resolvem problemas diferentes.

• Servidores DNS globais: resolução padrão da firewall para DNS de internet, resolução FQDN geral, atualizações e serviços cloud.
• DNS Request Route: encaminha domínios específicos ou zonas inversas para servidores DNS definidos. Exemplos típicos são Active Directory, domínios internos, DNS de site e Split DNS.
• Opção DHCP: distribui servidores DNS ou domínios de pesquisa aos clientes. Isto é relevante quando os clientes devem usar diretamente um servidor DNS específico.

Uma DNS Request Route não altera automaticamente a configuração DNS de todos os clientes. A rota controla para onde o próprio Sophos Firewall ou clientes que usam a firewall como encaminhador DNS encaminham pedidos DNS específicos. Se os clientes devem usar diretamente um servidor DNS interno, uma Opção DHCP no Sophos Firewall é mais adequada.

Também é importante a diferença para uma DNS Host Entry: uma DNS Host Entry responde diretamente a um hostname específico com um endereço IP na firewall. Uma DNS Request Route, pelo contrário, encaminha um domínio ou zona para outro servidor DNS. Para Active Directory e zonas internas dinâmicas, uma Request Route é quase sempre mais limpa do que muitas Host Entries individuais.

Qual Design DNS é Adequado?

Antes de criar uma DNS Request Route, deve estar claro que resolvedor é usado na respetiva rede. A rota só ajuda se Sophos Firewall também vir o pedido.

• Clientes consultam Sophos Firewall: a firewall encaminha domínios públicos globalmente e domínios internos por DNS Request Route. Isto encaixa bem em sites pequenos e médios, DNS Protection e redes de convidados ou clientes.
• Clientes consultam diretamente servidores DNS internos: Domain Controller ou servidores DNS resolvem internamente e encaminham externamente. Isto encaixa em redes Active Directory clássicas com Windows DNS como resolvedor central.
• Clientes VPN consultam a firewall: a firewall usa Request Routes para domínios internos. Isto encaixa em Remote Access com um caminho DNS simples através da firewall.
• Clientes VPN consultam diretamente servidores DNS internos: DNS passa por VPN para o Domain Controller ou servidor DNS. Isto encaixa em ambientes AD maiores, quando os clientes devem usar a mesma lógica DNS que na LAN.

Em ambientes mistos, um pequeno esboço DNS é muito útil: rede do cliente, servidor DNS atribuído, domínio de pesquisa, zonas DNS internas, DNS Request Routes e caminho de routing até ao servidor de destino. Sem esta visão geral, muitas vezes trabalha-se na Request Route, embora o cliente nem sequer use a firewall como resolvedor DNS.

Para que DNS Request Routes tenham efeito nos clientes, Sophos Firewall tem de estar no caminho da consulta DNS. Isto pode ser direto, se os clientes receberem o IP de interface da firewall como servidor DNS, ou indireto, se um resolvedor interno encaminhar conscientemente para a firewall. Se os clientes consultarem diretamente um Domain Controller, a firewall não vê esta consulta DNS como resolvedor e não a pode redirecionar por Request Route.

Quando Precisamos de Rotas de Pedido DNS?

As Rotas de Pedido DNS são úteis quando:

• nomes de host internos como server01.firma.local têm de ser resolvidos
• pesquisas reversas para redes IP internas devem funcionar
• utilizadores VPN devem usar nomes internos
• vários locais têm suas próprias zonas DNS
• a própria firewall tem de aceder a sistemas internos por FQDN
• servidores DNS públicos não conhecem nomes internos

Sem uma Rota de Pedido DNS, o firewall pergunta ao servidor DNS configurado globalmente. Se o domínio interno não for conhecido lá, a resolução falha.

Esta diferença é especialmente importante no acesso remoto. Se os clientes VPN usam a firewall como servidor DNS, uma DNS Request Route pode garantir que os domínios internos chegam ao controlador de domínio ou servidor DNS correto. Se os clientes VPN recebem diretamente servidores DNS internos, deve verificar adicionalmente se routing, regras de firewall e sufixos DNS no cliente estão corretos.

Pré-requisitos

• Acesso ao WebAdmin do Sophos Firewall
• Sophos Firewall está corretamente configurado como resolvedor DNS ou encaminhador DNS em Network > DNS > DNS configuration
• Servidor DNS interno está acessível
• Domínio ou rede é conhecido
• Regras de firewall permitem tráfego DNS para o servidor de destino
• Em interligação de sites: routing para o servidor DNS funciona
• O cliente afetado usa o firewall como servidor DNS ou recebe conscientemente outro servidor DNS

⚠️ Problemas de DNS muitas vezes parecem problemas de routing, VPN ou aplicações. Antes de alterações maiores, deve verificar se o servidor de destino é acessível por IP e se apenas a resolução de nomes falha.

Em Network > DNS > DNS configuration, deve verificar também como a firewall resolve as suas consultas DNS normais. Se for usada DNS Protection, encontram-se aí os endereços IP de DNS Protection. Se forem usados forwarders clássicos ou resolvedores internos, esses servidores têm de estar acessíveis. Com Test name lookup, pode verificar diretamente na configuração DNS se a firewall consegue resolver em princípio um nome ou um IP.

Configurar uma DNS Request Route

A configuração é tecnicamente simples, mas torna-se rapidamente confusa quando domínios, zonas inversas, clientes VPN e vários sites se juntam.

Criar Rota de Pedido DNS para um Domínio

Uma rota de domínio garante que pedidos para um domínio específico sejam enviados para um servidor DNS definido.

Exemplo:

• Nome do host/domínio: firma.local
• Servidor DNS: 10.10.10.10

Procedimento:

1. Inicie sessão em Sophos Firewall.
2. Abra Network > DNS.
3. Vá para a secção DNS request route.
4. Selecione Add.
5. Em Host/domain name, introduza o domínio interno, por exemplo firma.local.
6. Em Target servers, selecione o servidor DNS interno ou crie-o como host através de Create.
7. Guarde.

O valor em Host/domain name deve ser escrito como um FQDN ou nome de zona, não como URL, regra wildcard ou descrição livre. A API Sophos trata este valor como um campo FQDN com no máximo 255 caracteres. Para rotas de domínio normais, por exemplo, firma.local é suficiente; para pesquisas reversas, usa-se a zona in-addr.arpa correspondente.

Se faltar um acerto de cache DNS na firewall, o pedido correspondente para este domínio não é enviado para os forwarders normais nem para root servers, mas para os Target Servers da Request Route. Isto é intencional: zonas internas não devem ser consultadas externamente por engano. Mas também significa que um Target Server mal escolhido pode responder corretamente ao pedido e, mesmo assim, estar funcionalmente errado.

Usar Vários Servidores de Destino

Em Target servers, pode adicionar mais do que um servidor DNS. Isto é útil quando há vários servidores DNS internos ou quando o DNS deve estar acessível de forma redundante através de uma ligação entre sites.

Possíveis servidores de destino:

• servidores DNS internos na rede local
• servidores DNS do outro lado de uma conexão VPN
• servidores DNS em outro local
• servidores DNS públicos, se um domínio específico deve ser resolvido externamente de forma consciente

A ordem é relevante. A firewall consulta os hosts selecionados pela ordem em que aparecem na lista. Por DNS Request Route, podem ser registados até oito endereços IP. Mais servidores de destino não significam automaticamente melhor redundância se os servidores tiverem estados de zona diferentes, encaminhamentos diferentes ou acessibilidade diferente através de VPN.

Com vários Target Servers, não deve apenas registar redundância, mas também verificar a responsabilidade. Se o primeiro servidor DNS conhece a zona, mas fornece entradas desatualizadas, a Request Route funcionará tecnicamente, mas ainda assim devolverá respostas incorretas.

Um NXDOMAIN é uma resposta DNS válida. Se o primeiro servidor DNS acessível disser que um nome não existe, a firewall não pergunta automaticamente ao servidor seguinte na esperança de uma resposta diferente. Por isso, os Target Servers para a mesma DNS Request Route devem ter o mesmo estado de zona e os mesmos encaminhamentos.

DNS Dividido para VPN e Locais

Split DNS significa que o mesmo nome é resolvido de forma diferente consoante o site ou a rede. Um portal interno pode, por exemplo, apontar internamente para um IP privado, enquanto o mesmo nome aponta externamente para um endereço público ou nem sequer é resolvido.

No Sophos Firewall, três pontos são decisivos para isso:

1. A Rota de Pedido DNS adequada para o domínio interno.
2. Uma regra de firewall que permite DNS do firewall ou do cliente para o servidor DNS interno.
3. Um caminho de routing para o servidor DNS, especialmente em VPN site-to-site, SSL VPN ou Sophos Connect.

Para ambientes de Remote Access, deve verificar adicionalmente que servidores DNS e domínios de pesquisa o cliente recebe. Com Sophos Connect, isto encaixa em Configurar Sophos Connect no Sophos Firewall. Em configurações clássicas de SSL VPN, isto encaixa em Configurar Acesso Remoto SSL VPN no Sophos Firewall.

Com DNS Protection surge uma questão adicional de desenho: a Sophos recomenda configurar dispositivos de rede para que usem a firewall como resolvedor DNS. Para isso, normalmente é distribuído nos servidores DHCP da firewall o IP de interface da firewall como servidor DNS. Se, apesar disso, os dispositivos usarem resolvedores externos, pode ser planeada uma regra NAT direcionada para tráfego DNS de saída para a firewall. Isto deve ser consciente e não genérico, porque redirecionamentos DNS rígidos podem influenciar troubleshooting, dispositivos BYOD, DoH/DoT e dispositivos especiais.

Se a própria firewall usar DNS Protection como forwarder, os endereços IP de DNS Protection copiados do Sophos Central devem ser introduzidos em Network > DNS > DNS configuration como servidores DNS primário e secundário. Um terceiro servidor DNS diferente ou um caminho DNS IPv6 não intencional pode fazer com que as consultas contornem o DNS Protection. Por isso, DNS Request Routes, opções DNS DHCP, definições DNS IPv6 e regras NAT DNS opcionais devem ser verificadas como um desenho comum.

DNS Reverso para Redes Internas

Uma DNS Request Route reversa encaminha consultas PTR para uma rede IP interna ao servidor DNS que conhece a zona de pesquisa inversa adequada. Isto ajuda quando logs, relatórios ou serviços têm de converter um endereço IP novamente num nome de host.

Exemplo:

• Rede: 172.16.16.0/24
• Servidor DNS: 172.16.16.10
• Zona Reversa: 16.16.172.in-addr.arpa

Para pesquisas reversas, também se cria uma Rota de Pedido DNS em Network > DNS > DNS request route. Em Host/domain name, não se insere o domínio normal, mas sim a zona reversa.

Exemplo para 172.16.16.0/24:

16.16.172.in-addr.arpa

A ordem dos octetos é invertida. Da rede 172.16.16.0/24, torna-se 16.16.172.in-addr.arpa. Importante: em Host/domain name não se introduz uma notação CIDR como 172.16.16.0/24, mas sim uma zona DNS. O valor deve, portanto, parecer um nome de domínio ou de zona inversa, não uma descrição livre.

Para redes maiores, a zona reversa pode ser mais ampla. Exemplo: Para 172.16.0.0/16, seria 16.172.in-addr.arpa. O importante é como a zona de pesquisa reversa foi configurada no servidor DNS interno.

Se no servidor DNS interno não existir uma zona PTR ou registos PTR, a Request Route não ajuda. A firewall só consegue enviar o pedido ao servidor DNS correto, mas não cria entradas DNS reversas no servidor DNS.

Em ambientes IPv6 com prefixo de fornecedor, deve considerar também o DNS desde cedo. Como os clientes recebem o seu endereço IPv6 e que papel desempenham Router Advertisement e DHCPv6 está em Configurar Delegação de Prefixo IPv6 no Sophos Firewall.

Testes e operação

Após a configuração, deve testar separadamente acessibilidade IP, resolução DNS e DNS do cliente. Assim percebe mais rapidamente se o problema está realmente na Request Route.

Testes e Validação

Após a configuração, deve-se testar a resolução de nomes:

• O firewall consegue resolver o nome interno?
• Network > DNS > Test name lookup funciona para um nome interno e um nome público?
• A resolução funciona a partir de zonas VPN ou de utilizador?
• O servidor DNS é acessível por Ping ou TCP/UDP 53?
• Existem entradas no log de DNS ou firewall?

Se a resolução não funcionar, deve-se primeiro verificar:

• O domínio está escrito corretamente?
• O cliente realmente usa o Sophos Firewall ou o servidor DNS correto?
• Uma regra de firewall bloqueia o DNS?
• Falta uma rota para o servidor DNS?
• O servidor DNS responde a pedidos do firewall?

Um teste sensato separa a acessibilidade IP e a resolução DNS:

1. Teste o sistema de destino por IP, por exemplo, Ping, porta TCP ou aplicação.
2. Alcance o próprio servidor DNS por IP.
3. Resolva o nome através da fonte DNS esperada.
4. Só então teste a aplicação pelo nome.

Se o acesso por IP funcionar, mas por nome não, o foco está em DNS Request Route, sufixo DNS, DNS do cliente ou pesquisa inversa. Se o acesso por IP já falhar, deve verificar primeiro routing, regra de firewall, NAT ou VPN. Para esta delimitação, ajudam Testar regra de firewall com Log Viewer, Policy Test e Packet Capture e Regra do Sophos Firewall não corresponde: verificar causas.

Comandos de Teste para Firewall e Clientes

No Sophos Firewall, a Device Console pode ajudar a testar o DNS do ponto de vista do firewall:

dnslookup server01.firma.local
dnslookup example.com

Nos clientes, deve-se verificar adicionalmente qual resolvedor é realmente usado.

Windows:

ipconfig /all
nslookup server01.firma.local
nslookup server01.firma.local <firewall-ip>
Resolve-DnsName server01.firma.local

macOS:

scutil --dns
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

Linux:

resolvectl status
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

<firewall-ip> representa o endereço da interface interna de Sophos Firewall na respetiva rede. Se a consulta à firewall funcionar, mas a consulta normal do cliente não, o problema está geralmente no DHCP, perfil VPN, sufixo DNS, resolvedor local ou comportamento DNS do browser/sistema. Se a consulta à firewall também falhar, os próximos pontos de verificação são Request Route, Target Server, routing ou regra de firewall.

Em clientes com browsers modernos ou agentes Endpoint, deve verificar adicionalmente se DNS-over-HTTPS ou um agente de segurança local contorna a consulta DNS normal. Nesse caso, a firewall pode não ver nenhum pedido DNS clássico em UDP/TCP 53, embora a configuração de rede pareça correta.

Definir testes positivos e negativos

Uma DNS Request Route só fica corretamente testada quando o nome interno pretendido funciona e também foi verificado um contraexemplo. Caso contrário, não fica claro se a route atinge exatamente a zona interna ou se o DNS está a ser redirecionado de forma demasiado ampla.

Um plano de teste curto costuma ser suficiente:

• Teste positivo: um nome interno da zona de destino resolve para o IP privado esperado, por exemplo server01.ad.firma.local.
• Teste negativo: um domínio público não afetado continua a usar o caminho predefinido previsto, por exemplo DNS global, DNS Protection ou um forwarder interno.
• Teste no cliente: executar o teste a partir da VLAN, perfil VPN ou localização afetada, não apenas diretamente na firewall.
• Verificação de logs: firewall log, DNS log ou Packet Capture mostram que a consulta chega ao resolvedor esperado.
• Regressão: repetir o mesmo teste após alterações em VPN, DHCP, DNS Protection ou routing da localização.

Este pequeno teste negativo evita efeitos secundários típicos: domínios públicos respondidos internamente, DNS Protection contornado, Split-DNS a funcionar apenas em algumas redes ou cliente VPN ainda a usar um resolvedor antigo.

Verificação operacional

As Rotas de Pedido DNS devem ser o mais específicas possível. Uma rota para o domínio interno exato é melhor do que uma configuração muito ampla. Para ambientes maiores, vale a pena uma pequena tabela com domínio, servidor DNS, local e propósito, para que alterações futuras sejam rastreáveis.

Documentação prática:

• Domínio ou Zona Reversa: ad.firma.local
• Servidores de Destino: 10.10.10.10, 10.10.10.11
• Propósito: DNS do Active Directory para local principal.
• Redes Afetadas: LAN, VPN de Admin, Local de Zurique.
• Dependências: VPN site-to-site, Controlador de Domínio, Regra de Firewall DNS.
• Teste: server01.ad.firma.local resolve para o IP interno esperado.
• Teste negativo: por exemplo, example.com continua a usar o caminho predefinido previsto.

Troubleshooting

Se o DNS não funcionar, não altere diretamente a Request Route. Frequentemente, o cliente usa outro resolvedor, uma regra de firewall bloqueia DNS ou a zona inversa não existe no servidor de destino.

Erros Típicos

• Nome interno não resolve: domínio incorreto, por exemplo, firma.local em vez de ad.firma.local Verificar domínio na Rota de Pedido e domínio de pesquisa do cliente.
• Cliente VPN não resolve nomes internos: Cliente não usa o firewall ou o servidor DNS errado Verificar configurações DNS do VPN, DNS do cliente e regra de firewall.
• Firewall não consegue alcançar o servidor DNS: Falta de rota, VPN ou regra de firewall Verificar Ping, Packet Capture e Route Lookup.
• Firewall resolve externamente, mas não internamente: verificar DNS Request Route, Target Server e Test name lookup. Depois usar Packet Capture em direção ao servidor DNS interno.
• Pesquisa inversa não funciona: faltam zona PTR ou registos PTR. Verificar a zona de pesquisa inversa no servidor DNS interno.
• Locais individuais fornecem respostas incorretas: Servidor de Destino incorreto ou dados de zona desatualizados Verificar ordem dos Servidores de Destino e replicação DNS.
• Nomes públicos são subitamente respondidos internamente: a Request Route é demasiado ampla. Usar um domínio mais específico e evitar lógica de wildcard.
• Primeiro servidor DNS responde NXDOMAIN: A firewall trata esta resposta como válida e não consulta automaticamente todos os outros Target Servers. Verificar estado da zona e ordem dos servidores.
• DNS Protection não atua para todos os clientes: verificar se os clientes usam realmente a firewall como resolvedor DNS ou se resolvedores externos, DoH/DoT, agentes locais ou definições DNS manuais estão no caminho.

Em ambientes VPN, deve-se verificar adicionalmente se os clientes VPN recebem os servidores DNS e domínios de pesquisa corretos.

FAQ