Configurar DNS Request Routes no Sophos Firewall

Uma DNS Request Route encaminha consultas relativas a um domínio ou uma zona inversa específicos para servidores DNS selecionados. Um caso típico é ad.example.com: a firewall resolve nomes públicos através dos seus resolvedores habituais, mas envia as consultas desta zona interna para os controladores de domínio.

A rota só funciona se o Sophos Firewall processar a consulta como servidor DNS. Se um cliente consultar diretamente o servidor DNS interno, o encaminhamento desse servidor será responsável, e não a Request Route da firewall.

A zona de destino não tem de ser interna: uma Request Route também pode encaminhar domínios públicos selecionados para um resolvedor na própria rede. Isto faz sentido quando esse resolvedor é deliberadamente responsável por esses domínios. O processamento local pode reduzir as consultas DNS externas; no entanto, uma determinada melhoria de velocidade ou confidencialidade adicional só se verifica se o resolvedor de destino processar as consultas de forma adequada e não se limitar a encaminhá-las sem alterações para a Internet.

Determinar o caminho DNS antes da alteração

Três configurações com efeitos semelhantes resolvem tarefas diferentes:

• O cliente consulta a firewall: o DHCP ou o perfil VPN distribui o IP da interface da firewall como servidor DNS. Para aceder ao serviço DNS local, a zona do cliente deve ter DNS autorizado em Administration > Device access > Local service ACL. As regras normais de firewall não controlam este acesso à própria firewall.
• O cliente consulta diretamente um servidor DNS interno: o resolvedor interno responde pelas zonas locais e encaminha as restantes consultas. Entre zonas diferentes, pode ser necessária uma regra normal de firewall; este caminho do cliente não utiliza uma Request Route da firewall.
• A firewall consulta um servidor de destino interno: uma Request Route seleciona o servidor de destino com base no domínio consultado. O routing e a acessibilidade do servidor de destino têm de estar corretos.

Uma DNS Host Entry, por outro lado, responde diretamente a um único nome na firewall. Para algumas entradas estáticas, Configurar DNS Host Entries no Sophos Firewall apresenta o procedimento completo. Uma Request Route é mais adequada para uma zona completa mantida num servidor DNS. As opções DHCP, por sua vez, determinam o servidor DNS e o domínio de pesquisa que um cliente recebe; consulte Configurar opções DHCP no Sophos Firewall.

⚠️ Uma Request Route é selecionada pelo nome de domínio, não pela rede de origem do cliente. Respostas diferentes para locais diferentes têm de ser fornecidas pelos resolvedores envolvidos ou por caminhos DNS separados. Uma única rota não cria uma vista DNS dependente da origem.

Exemplo e pré-requisitos

Este exemplo encaminha uma zona AD interna para dois resolvedores:

• zona interna: ad.example.com
• servidor de destino primário: 10.10.10.10
• segundo servidor de destino: 10.10.10.11
• rede do cliente: 10.20.30.0/24
• IP da firewall como resolvedor do cliente: 10.20.30.1
• teste positivo: dc01.ad.example.com
• teste negativo: example.net

example.com e example.net são domínios de documentação. Na configuração de produção, a zona e os endereços dos servidores e interfaces são substituídos pelos valores próprios. Ambos os servidores de destino devem ser responsáveis pela mesma zona e fornecer o mesmo estado da zona. Uma longa lista de resolvedores diferentes não constitui uma redundância adequada.

Antes de criar a rota, é necessário esclarecer os seguintes pontos:

1. A firewall está configurada como resolvedor em Network > DNS > DNS configuration.
2. Os servidores de destino estão acessíveis através do caminho de routing local ou VPN previsto.
3. Os clientes para os quais a rota deve funcionar utilizam efetivamente o IP da firewall como servidor DNS.
4. Em Administration > Device access, DNS está autorizado apenas para as zonas de clientes necessárias. Uma Local Service ACL Exception mais restritiva é aconselhável se não for suposto toda a zona ter acesso.
5. A zona interna existe nos servidores de destino e contém uma entrada de teste conhecida.
6. O caminho DNS anterior e as Request Routes existentes estão documentados para permitir a reversão.

Criar uma DNS Request Route

1. No WebAdmin, abra Network > DNS.
2. Aceda à secção DNS request route.
3. Selecione Add.
4. Em Host/Domain name, introduza ad.example.com.
5. Em Target servers, selecione 10.10.10.10 e 10.10.10.11. Se os objetos de servidor não existirem, crie-os como IP Hosts através de Create.
6. Verifique a ordem: o SFOS consulta os hosts selecionados pela ordem indicada.
7. Guarde com Save.

A Sophos permite no máximo oito endereços IP de destino por Request Route. Mais servidores só melhoram a disponibilidade se responderem corretamente pela mesma zona e estiverem acessíveis através de caminhos independentes e realmente funcionais.

Quando uma Request Route corresponde e a firewall não encontra uma resposta adequada na cache, o SFOS envia a consulta para os respetivos Target Servers. Para esse domínio, não recorre aos forwarders globais nem aos root servers. Se todos os servidores de destino estiverem inacessíveis ou configurados incorretamente para a zona, a resolução falha em vez de utilizar inadvertidamente um resolvedor público.

Em DNS request route, a nova entrada deve então aparecer com o domínio e os servidores de destino esperados.

Avaliar corretamente vários servidores de destino

A ordem documentada é um mecanismo de disponibilidade, não uma forma de reconciliar dados DNS contraditórios. Nos resolvedores estáticos globais, o SFOS trata NXDOMAIN como resposta válida e não consulta depois o servidor seguinte. A ajuda do SFOS 22 não confirma expressamente este comportamento para os servidores de destino de uma Request Route. Por isso, não se deve confiar num segundo servidor com um estado de zona diferente nem prometer um failover específico após NXDOMAIN.

Durante a aceitação, ambos os servidores de destino são consultados individualmente a partir de um sistema de teste autorizado. Devem responder da mesma forma ao teste positivo; um nome deliberadamente inexistente também deve produzir o mesmo resultado em ambos. Assim, detetam-se erros de replicação ou de autoridade da zona antes de a firewall ter de alternar entre os servidores.

nslookup dc01.ad.example.com 10.10.10.10
nslookup dc01.ad.example.com 10.10.10.11
nslookup does-not-exist.ad.example.com 10.10.10.10
nslookup does-not-exist.ad.example.com 10.10.10.11

As consultas diretas testam o estado da zona e a resposta do servidor, não a Request Route. Só devem ser executadas a partir de uma rede que, segundo o desenho DNS, possa aceder a ambos os resolvedores. Em seguida, a consulta através de 10.20.30.1 confirma que a firewall também encaminha a zona para os servidores previstos.

Encaminhar pesquisas inversas

Para consultas PTR, introduza a zona inversa, e não uma rede, em Host/Domain name. Para 172.16.16.0/24, a zona inversa IPv4 clássica é:

16.16.172.in-addr.arpa

Para 172.16.0.0/16, é:

16.172.in-addr.arpa

Uma indicação CIDR como 172.16.16.0/24 não deve ser colocada no campo de domínio. O que importa é a zona efetivamente configurada no servidor DNS interno. A Request Route não cria registos PTR; se a zona ou os registos não existirem no servidor de destino, a consulta inversa continuará a falhar. Redes IPv4 que não estejam alinhadas por octetos e zonas inversas IPv6 exigem um desenho próprio de delegação DNS e não devem ser improvisadas pela simples inversão do prefixo.

O DNS inverso ajuda logs e serviços a associar um endereço a um nome. No entanto, não corrige uma resolução direta falhada de um FQDN e constitui, por isso, um caso de teste separado.

Compreender o caminho do resolvedor global

Em Network > DNS > DNS configuration, define-se como a firewall resolve consultas às quais não se aplica nenhuma Host Entry nem Request Route. Consoante a interface, o SFOS pode obter resolvedores através de Obtain DNS from DHCP ou Obtain DNS from PPPoE. Com Static DNS, definem-se explicitamente DNS 1, DNS 2 e, opcionalmente, DNS 3.

⚠️ Se Obtain DNS from DHCP estiver ativo e a última interface DHCP aplicável for desativada ou alterada para outro modo de atribuição, o SFOS muda para Static DNS. Se a interface for reativada, a definição não regressa automaticamente. Por isso, a seleção DNS deve ser verificada após alterações de WAN e interfaces.

Com Static DNS, a firewall consulta os servidores pela ordem configurada. Passa ao servidor seguinte após um timeout, mas não depois de uma resposta NXDOMAIN válida. As respostas permanecem na cache de acordo com o respetivo TTL. Assim, um segundo resolvedor é uma reserva de disponibilidade, não uma verdade DNS alternativa.

Para os servidores DNS globais, o SFOS 22 documenta quatro opções de seleção. As duas opções de prioridade fixa exigem que estejam configurados servidores DNS IPv4 e IPv6:

• Choose a server based on incoming requests record type seleciona o servidor DNS com base no tipo de registo consultado, A ou AAAA.
• Choose IPv6 DNS server over IPv4 dá prioridade ao servidor DNS IPv6 sobre o servidor DNS IPv4.
• Choose IPv4 DNS server over IPv6 dá prioridade ao servidor DNS IPv4 sobre o servidor DNS IPv6.
• Choose IPv6 if request originator address is IPv6, else IPv4 utiliza o servidor DNS IPv6 para uma consulta proveniente de um endereço de origem IPv6 e o servidor DNS IPv4 para uma consulta proveniente de um endereço de origem IPv4.

O tipo de registo e a família do endereço de origem são critérios distintos: uma consulta AAAA não é automaticamente uma consulta proveniente de um endereço de origem IPv6. Por isso, a seleção é feita de acordo com o caminho de resolução previsto, e não apenas com o endereço pretendido na resposta DNS. Os resolvedores selecionados têm de estar acessíveis através da respetiva família de endereços. Estas opções globais não alteram a seleção dos Target servers de uma Request Route com base no domínio.

Após Apply, Test name lookup testa um hostname ou endereço IP do ponto de vista da firewall. Um nome de teste interno pode utilizar uma Request Route adequada. No entanto, o teste não confirma o resolvedor configurado no cliente nem o seu caminho DNS real.

Se o WebAdmin não estiver disponível durante uma recuperação planeada, a CLI interativa em 1. Network Configuration > DNS Configuration apresenta os servidores DNS IPv4 e IPv6 globais. Esta opção de menu não altera Request Routes. Antes de introduzir valores, guarde todos os valores apresentados; Enter sem um novo valor ignora a alteração. Para uma alteração remota, mantenha disponível um caminho de gestão independente.

Combinar DNS Protection com zonas internas

Escolher primeiro a versão: a partir do SFOS 23.0, utilizar o percurso DoH integrado com DNS Protection em Network > DNS e a atribuição da Filtering Policy ao objeto da firewall. O artigo sobre DNS Protection ligado abaixo descreve a configuração, a decisão de fallback, o piloto e o procedimento de reversão. A sequência seguinte de Location/DDNS e Static DNS aplica-se exclusivamente a Traditional DNS no SFOS 22 e anteriores; não é executada adicionalmente no percurso integrado do SFOS 23. As Request Routes internas e as verificações do caminho do cliente e do NAT continuam relevantes.

Com Sophos DNS Protection e Sophos Firewall, as consultas públicas são enviadas para o DNS Protection, enquanto as Request Routes enviam as zonas internas para resolvedores locais. Para isso, a firewall é primeiro registada como Location no Sophos Fusion (anteriormente Sophos Central). Se existirem vários endereços WAN públicos, todos os endereços utilizados ou o intervalo adequado têm de ser registados; com um endereço WAN dinâmico, utiliza-se o hostname DDNS registado.

A configuração oficial da Sophos define os dois endereços do DNS Protection como DNS 1 e DNS 2 em Network > DNS > DNS configuration, deixa DNS 3 vazio, remove os servidores DNS IPv6 e seleciona Choose IPv4 DNS server over IPv6. Um terceiro resolvedor ou um resolvedor IPv6 não intencional pode fazer com que as consultas contornem o DNS Protection.

Para DHCP, a Sophos indica um caminho específico: em Network > DHCP > Server > Edit, Use device’s DNS settings permanece desativado. O IP da firewall da interface DHCP é introduzido como Primary DNS, e um endereço público do DNS Protection como Secondary DNS. Como os clientes podem tratar a utilização de vários resolvedores de formas diferentes, é necessário verificar se as consultas internas passam realmente pela firewall. As consultas diretas dos clientes ao DNS Protection não utilizam as Request Routes locais da firewall.

A Sophos descreve também uma regra DNAT que redireciona consultas DNS de saída clássicas das redes internas para o IP interno da firewall. Este redirecionamento é uma decisão de segurança separada: não abrange automaticamente DNS over HTTPS nem DNS over TLS e pode afetar dispositivos especiais. Só deve ser introduzido com redes de origem claramente identificadas, sem WAN como Inbound Interface e com um plano documentado de exceções e reversão.

Testar separadamente a firewall e o cliente

Perspetiva do resolvedor da firewall

Em Network > DNS > Test name lookup, teste sucessivamente dc01.ad.example.com e example.net. O nome interno deve devolver o endereço interno esperado e o nome público deve continuar a ser resolvido através do caminho predefinido previsto.

Em 4. Device Console, a mesma perspetiva está disponível com o comando oficialmente documentado:

dnslookup host dc01.ad.example.com
dnslookup host example.net

Estes testes mostram a perspetiva do resolvedor da firewall. Ainda não provam que um cliente consulta a firewall.

Comparar resolvedores individuais em Diagnostics

Em Diagnostics > Tools, o SFOS 22 disponibiliza Name lookup com os campos IP address or hostname e DNS server IP. Um FQDN testa a resolução direta, enquanto um endereço IPv4 ou IPv6 testa a resolução inversa. Selecione um servidor configurado específico ou utilize Lookup using all configured servers para comparar as respostas e os tempos de resposta de todos os resolvedores configurados. Um tempo de resposta curto, por si só, não justifica alterar a ordem dos servidores; primeiro, as respostas têm de ser adequadas à zona prevista.

No SFOS 23, a secção chama-se DNS lookup e os campos são Hostname or IP address e DNS server IP address. Além de um servidor disponível e de All configured servers, estão disponíveis Custom DNS server e Custom DoH server; em cada caso, introduz-se o endereço IP do servidor pretendido. DNS Protection só pode ser selecionado se o DNS Protection estiver ativado em Network > DNS. Trata-se de uma opção de diagnóstico, não de uma indicação para reformular a configuração DNS existente apenas para realizar um teste.

Para nomes de teste internos, utilize apenas resolvedores internos autorizados, para que os nomes não sejam enviados para um serviço DNS ou DoH público. Uma consulta dirigida a um resolvedor confirma a resposta desse resolvedor, não o caminho real da Request Route ou do cliente. Por isso, continua a ser necessário efetuar a validação através do IP da firewall e com Packet Capture.

Comprovar o caminho do cliente

Num cliente de teste, verifique primeiro o servidor DNS configurado e, depois, consulte explicitamente o IP da firewall 10.20.30.1.

Windows:

ipconfig /all
nslookup dc01.ad.example.com 10.20.30.1
nslookup example.net 10.20.30.1

macOS ou Linux:

dig @10.20.30.1 dc01.ad.example.com A
dig @10.20.30.1 example.net A

Em seguida, execute as mesmas consultas sem indicar explicitamente um servidor. Se os resultados forem diferentes, o cliente utiliza outro caminho de resolução, como uma definição estática, um perfil VPN, DNS over HTTPS ou um agente de segurança local. Um domínio de pesquisa só é relevante para nomes curtos e não qualificados; os FQDN utilizados acima não precisam dele.

Packet Capture para o caminho real

Em Diagnostics > Packet capture, um filtro aplicado ao cliente de teste, aos servidores de destino e à porta 53 restringe o tráfego. Packet Capture no Sophos Firewall explica o procedimento exato.

(host 10.20.30.50 or host 10.10.10.10 or host 10.10.10.11) and port 53

É necessário verificar a consulta recebida do cliente, a consulta gerada pela firewall para o Target Server correto e a respetiva resposta. O capture distingue assim a falta de acesso do cliente de um problema de routing ou do servidor de destino. Como o buffer de capture é limitado, o filtro deve ser restrito e a gravação ativada apenas durante o teste.

No caso do DNS Protection, a ligação oficial Check your configuration em My Products > DNS Protection > Installers complementa a verificação. A página de boas-vindas confirma o caminho do DNS Protection; a zona interna, o caminho do cliente e a Request Route continuam a ser testados separadamente.

Isolar erros por sintoma

A firewall resolve internamente, mas o cliente não

• Verifique se o cliente utiliza realmente o IP da firewall como servidor DNS.
• Em Administration > Device access, verifique se DNS está autorizado para a zona do cliente ou através de uma Local Service ACL Exception adequada.
• Envie a consulta explicitamente para o IP da firewall e confirme-a com Packet Capture.
• Verifique as definições de DHCP, VPN e resolvedor local, bem como DoH/DoT, como caminhos alternativos.

A firewall não alcança o Target Server

• Verifique o Route Lookup e o caminho local ou VPN até ao endereço de destino.
• Verifique a porta 53 UDP e TCP até ao servidor de destino, bem como a ACL do próprio servidor.
• Consulte diretamente o resolvedor e verifique se aceita consultas provenientes do IP da firewall.
• No Packet Capture, procure uma consulta gerada, uma resposta ou um motivo de drop.

Se os clientes consultarem diretamente o servidor DNS interno, aplica-se, em vez disso, o caminho de trânsito normal com zonas e regra de firewall. Para esta distinção, consulte Verificar regras de firewall com Log Viewer, Policy Test e Packet Capture.

Respostas incorretas ou variáveis

• Domínio demasiado abrangente ou incorreto: limite a Request Route à zona efetivamente responsável.
• Os servidores de destino fornecem dados diferentes: verifique diretamente a replicação DNS e a autoridade da zona em cada servidor.
• Resposta antiga: tenha em conta o TTL e as caches da firewall, do resolvedor e do cliente.
• Só os nomes curtos falham: verifique o domínio de pesquisa do cliente; teste o FQDN separadamente.
• A pesquisa inversa falha: verifique a zona PTR e o registo PTR no servidor de destino.
• Só os clientes VPN são afetados: verifique os servidores DNS atribuídos, o routing VPN e o acesso ao serviço DNS local. Os campos de cliente adequados estão em Configurar o Sophos Connect ou Configurar o acesso remoto SSL VPN.

API XML: identificar a rota pelo nome do objeto

A partir do SFOS 23, a documentação da API XML exige tanto Name como DomainName ao criar e editar uma DNS Request Route. Name identifica o objeto configurado e DomainName a zona DNS a encaminhar; por exemplo, Name = ad-intern e DomainName = ad.example.com. São valores de campos, não XML executável. Name é um único STRING com um máximo de 64 caracteres, permite UTF-8 e proíbe vírgulas. DomainName continua a ser FQDN com um máximo de 255 caracteres; os servidores de destino também têm de continuar a ser indicados.

Para a eliminação, a chave documentada muda de DomainName no SFOS 22 para Name no SFOS 23. Não repetir pedidos antigos sem alterações nem utilizar automaticamente o nome de domínio como nome do objeto. Antes, verificar a versão instalada e ler o objeto específico, comparar Name, DomainName, Target Servers e dependências com o destino pretendido e documentar o procedimento de reversão. Em caso de ambiguidade, interromper. Depois, verificar a resposta e o estado da API e voltar a ler o destino exato: apenas a rota pretendida pode ter sido removida; as restantes rotas têm de permanecer inalteradas. Em seguida, testar a resolução interna e pública conforme descrito acima. Não se inventa aqui um envelope de eliminação nem um esquema REST, e não se afirma ter sido realizado um teste no produto.

A configuração global do protocolo DNS é independente. O artigo sobre DNS Protection explica os conflitos por esclarecer no esquema XML do SFOS 23 e o percurso seguro através do WebAdmin; as quatro opções de seleção de resolvedores acima, descritas expressamente para o SFOS 22, não comprovam qualquer correspondência numérica na API do SFOS 23.

XML API: SFOS 22 — Add/Edit; SFOS 23 — Add/Edit; SFOS 22 — Delete; SFOS 23 — Delete.

Reversão e operação

Antes da alteração, registe as Request Routes existentes, a seleção DNS global, as permissões de Device Access e um teste positivo e outro negativo. Para uma reversão normal, remova a rota recém-criada ou restaure exatamente os valores anteriores documentados. Reponha também quaisquer exceções ACL ou redirecionamentos DNS temporários no estado inicial.

Em seguida, verifique novamente três aspetos:

1. A firewall resolve um nome interno e um nome público através do caminho previsto.
2. O cliente afetado utiliza o resolvedor previsto e recebe as respostas esperadas.
3. Um domínio não afetado não é enviado para o Target Server interno.

Um backup completo da configuração não é uma reversão prática de um único objeto: um restauro substitui toda a configuração e pode sobrescrever alterações posteriores. Para uma única Request Route, a alteração documentada do objeto é, portanto, o caminho de retorno mais seguro.

Perguntas frequentes