Configurar e testar DNS Host Entries na Sophos Firewall

Uma DNS Host Entry permite que a Sophos Firewall responda diretamente a um hostname específico com um endereço IP configurado. É adequada para alguns sistemas internos fixos, como uma appliance, um serviço de gestão ou um nome de servidor que a própria firewall tem de resolver.

A entrada só produz efeito se o pedido DNS chegar realmente à firewall. Se um cliente utilizar um controlador de domínio, um resolvedor público ou DNS over HTTPS, a firewall não vê esse pedido como resolvedor DNS. Uma DNS Host Entry também não substitui um objeto de regra, o routing, o NAT ou uma regra de firewall.

⚠️ Publish on WAN permanece desativado para entradas internas. Uma publicação pública exige um design DNS autoritativo deliberado, registos NS adequados, Device Access estritamente limitado e um teste negativo de recursão. Uma autorização DNS ACL a partir da WAN, por si só, não justifica a exposição pública do serviço DNS.

DNS Host Entry em oito passos

1. Confirmar que o nome é estático e que não é necessário encaminhar uma zona DNS interna completa.
2. Verificar se os clientes afetados utilizam realmente a Sophos Firewall como servidor DNS.
3. Documentar o FQDN, o endereço de destino, a versão IP, o TTL e um registo PTR opcional.
4. Introduzir o nome e o endereço em Network > DNS > DNS host entry > Add.
5. Manter Publish on WAN desativado para uma entrada interna.
6. Verificar a perspetiva da firewall em Network > DNS > Test name lookup.
7. A partir do cliente, consultar explicitamente o IP da firewall e testar a resolução direta e, se necessário, a resolução inversa.
8. Só depois testar a aplicação real e documentar a entrada juntamente com as suas dependências.

Quando uma DNS Host Entry é adequada

Uma DNS Host Entry é adequada para um único nome estável cuja resposta deve ser mantida diretamente na firewall. Exemplos típicos:

• uma appliance interna sem um registo DNS próprio;
• um FQDN de gestão fixo para LDAP, RADIUS ou outro serviço;
• um único hostname para uma migração controlada;
• um serviço público com inbound DNS load balancing deliberadamente planeado em vários endereços WAN.

Para um domínio completo, Active Directory ou zonas internas mantidas dinamicamente, uma DNS Request Route é mais adequada. Encaminha a zona para o servidor DNS responsável em vez de manter cada nome individualmente na firewall.

Um IP Host ou FQDN Host também tem uma função diferente. Estes objetos são utilizados em regras de firewall e NAT; não respondem ao pedido DNS de um cliente. Utilizar corretamente IP Hosts, Services e Groups explica os tipos de objetos.

Uma configuração de Dynamic DNS, por outro lado, atualiza um nome num fornecedor externo quando um endereço WAN muda. O procedimento completo encontra-se em Configurar Dynamic DNS na Sophos Firewall.

O SFOS suporta os tipos de registo A, AAAA e PTR para DNS Host Entries. Por isso, a função não é um servidor DNS autoritativo completo para CNAME, MX, TXT ou SRV. Cada DNS Host Entry suporta até oito endereços; a firewall suporta, no total, um máximo de 1024 DNS Host Entries.

Exemplo e valores a substituir

O exemplo representa um único servidor de aplicações interno:

• Hostname: app01.corp.example
• Endereço IPv4: 192.0.2.20
• Rede de clientes: 10.20.30.0/24
• IP da firewall como servidor DNS: 10.20.30.1
• Cliente de teste: 10.20.30.50
• TTL: 300 segundos
• Publish on WAN: desativado
• Reverse DNS: opcionalmente ativado

A zona .example e a rede 192.0.2.0/24 estão reservadas para documentação. Num ambiente de produção, o FQDN, o endereço, a rede de clientes e o IP do resolvedor são substituídos pelos valores reais. O nome deve corresponder à estratégia interna de nomes e não pode substituir involuntariamente uma zona autoritativa existente.

O TTL de 300 segundos é um valor de exemplo controlado para testes e migrações, não uma recomendação universal. Um TTL curto acelera alterações planeadas, mas gera mais pedidos DNS. Um TTL longo reduz os pedidos, mas mantém respostas antigas durante mais tempo nas caches depois de uma alteração.

Criar a DNS Host Entry

Em Network > DNS, deslocar-se até DNS host entry e selecionar Add:

1. Introduzir app01.corp.example em Host/Domain name.
2. Utilizar um endereço IP como Entry type.
3. Introduzir 192.0.2.20 em IP address.
4. Introduzir 300 em Time-to-live.
5. Não tratar Weight como uma ferramenta de balanceamento de carga quando só existe um endereço.
6. Manter Publish on WAN desativado.
7. Ativar Add reverse DNS lookup for this host entry apenas se a firewall também tiver de devolver uma resposta PTR para este endereço.
8. Guardar com Save.

Para um endereço IPv4, a firewall devolve uma resposta A; para um endereço IPv6, devolve uma resposta AAAA. A pesquisa inversa opcional volta a associar o endereço ao nome como PTR. No entanto, não cria um registo PTR num controlador de domínio ou num servidor DNS externo.

Se vários hostnames apontarem para o mesmo endereço IP, apenas um deles pode servir como destino inverso. Antes de ativar a opção, deve ficar claro qual é o nome esperado como resposta PTR canónica.

Utilizar uma interface em vez de um endereço fixo

Como Entry Type, é possível selecionar uma interface em vez de um IP fixo. Esta opção é adequada quando a resposta deve seguir deliberadamente o endereço atual dessa interface, por exemplo num design Multi-WAN público planeado.

A seleção de uma interface não substitui a verificação do caminho WAN real. Após uma mudança de endereço, uma troca de link ou um failover HA, é necessário voltar a testar a resposta DNS, o serviço acessível e o caminho de retorno com uma nova ligação.

Testar a resolução na firewall e no cliente

Primeiro, em Network > DNS > Test name lookup, verifica-se se a firewall devolve o endereço esperado para app01.corp.example. Se Reverse DNS estiver ativado, consulta-se também 192.0.2.20.

Este teste confirma apenas a perspetiva do resolvedor da firewall. Em seguida, o cliente afetado tem de consultar explicitamente o IP da firewall 10.20.30.1.

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux ou macOS:

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

A resposta tem de conter o registo esperado, o endereço correto e, na pesquisa inversa, o nome previsto. Em seguida, testa-se a aplicação através do FQDN. Uma resposta DNS correta ainda não prova que o routing, a regra de firewall, o NAT, o certificado TLS e o serviço funcionam.

Se não for claro se o pedido chega à firewall, pode utilizar-se um filtro restrito em Diagnostics > Packet capture, como:

host 10.20.30.50 and port 53

O pedido e a resposta têm de estar visíveis na interface esperada. Packet Capture na Sophos Firewall explica em detalhe a captura e análise seguras.

Utilizar vários endereços e pesos deliberadamente

Uma DNS Host Entry pode conter até oito endereços. Esta função destina-se a inbound DNS load balancing ou failover através de vários links WAN, não a uma coleção aleatória de servidores internos.

Os valores de Weight determinam a proporção em que as respostas são distribuídas pelos links indicados. Este comportamento deve ser verificado com pedidos DNS repetidos e ligações reais à aplicação. A distribuição de respostas DNS, por si só, não confirma a disponibilidade do serviço publicado nem um caminho DNAT e de retorno correto.

Vários endereços não se tornam automaticamente num Health Check geral para aplicações internas. Num design público, a Sophos documenta failover para uma interface inacessível ou avariada. Isto não garante que uma interface WAN acessível também forneça corretamente o serviço de aplicação atrás dela.

Weighted DNS e a configuração DNAT gerada pelo Server Access Assistant não devem ser planeados simultaneamente como um mecanismo conjunto para a mesma DNS Host Entry. A publicação requer um design coerente de resposta DNS, endereço WAN, DNAT, regra de firewall, TLS e caminho de retorno. Publicar um servidor através de DNAT explica separadamente o caminho dos dados.

Utilizar Publish on WAN apenas em designs autoritativos

Publish on WAN por si só não é suficiente para uma resposta pública. Para que a Sophos Firewall responda como Name Server de um serviço publicado, a zona autoritativa tem de ser delegada para nomes de servidores DNS cujos registos A/AAAA ou glue apontem para os endereços WAN previstos.

São também necessários os seguintes elementos:

1. O domínio público e a zona DNS responsável estão inequivocamente documentados.
2. A delegação NS e os registos de endereço ou glue associados conduzem aos endereços WAN previstos.
3. Em Administration > Device access, o DNS só é permitido através da zona WAN necessária ou de uma Local Service ACL Exception restrita.
4. Publish on WAN está ativado apenas nos endereços previstos.
5. O nome publicado é testado com êxito a partir de um resolvedor externo.
6. Os nomes não autoritativos e os pedidos recursivos são testados negativamente a partir do exterior.
7. O DNAT, a regra de firewall, o certificado e o caminho de retorno do serviço real são validados em separado.

Uma exceção DNS ACL adicional não restringe uma autorização ampla de zona WAN já ativa. O DNS permanece desativado para WAN na matriz e é permitido através de uma exceção específica, ou a autorização mais ampla é documentada como uma exposição consciente. Device Access e Local Service ACL explica como gerir esta camada sem provocar um bloqueio administrativo.

Se a delegação, o âmbito das respostas ou a proteção contra utilização recursiva não puderem ser claramente verificados, Publish on WAN não é ativado. Para zonas DNS públicas comuns, um serviço DNS autoritativo dedicado é normalmente a solução mais clara.

Delimitar erros por sintoma

A firewall resolve, mas o cliente não

• Verificar qual o servidor DNS realmente configurado no cliente. O DHCP pode distribuir o IP da firewall; o procedimento encontra-se em Configurar DHCP Server na Sophos Firewall.
• Verificar DNS over HTTPS, definições do cliente VPN e resolvedores estáticos no cliente como caminhos alternativos.
• Em Administration > Device access, verificar se o DNS é permitido a partir da zona do cliente.
• Utilizar Packet Capture para confirmar se o pedido e a resposta passam pela firewall.
• Não alterar o routing ou o NAT enquanto o cliente nem sequer estiver a consultar a firewall.

O cliente continua a receber o endereço antigo

• Verificar a entrada atual quanto a erros de escrita, hostnames duplicados e vários endereços.
• Ter em conta o antigo TTL ainda válido e as caches locais, do browser ou da aplicação.
• Enviar um novo pedido explícito para o IP da firewall em vez de apenas recarregar a aplicação.
• Antes de uma migração planeada, reduzir o TTL com antecedência e deixar o TTL anterior expirar completamente.

Esvaziar uma cache pode corrigir um único cliente de teste, mas não altera as respostas noutros resolvedores ou caches de aplicações. Por isso, não substitui uma espera controlada nem um teste através da cadeia DNS realmente utilizada.

Falta a pesquisa inversa ou aparece o nome errado

• Verificar se Add reverse DNS lookup for this host entry está ativado.
• Garantir que vários nomes não reclamam o mesmo endereço como destino PTR.
• Enviar explicitamente o pedido inverso para o IP da firewall.
• Para uma zona inversa interna num controlador de domínio, utilizar a DNS Request Route adequada em vez de uma entrada PTR local.

O pedido público não recebe resposta

• Verificar a partir do exterior a delegação NS e a acessibilidade dos endereços WAN.
• Verificar Publish on WAN em cada endereço previsto.
• Verificar Device Access, Local Service ACL, filtros upstream e a porta 53 UDP e TCP.
• Registar um Packet Capture durante um único pedido externo específico.
• Não ativar uma autorização DNS ampla como tentativa de resolução.

O DNS está correto, mas a aplicação continua inacessível

O DNS fornece apenas o endereço de destino. Seguem-se o routing, a regra de firewall, o NAT, o TLS e o serviço real. Por isso, o teste deve verificar sucessivamente o endereço IP, a porta e o protocolo da aplicação. Para problemas de regras e caminho, ajuda Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture.

Alterações, HA e rollback

Antes de uma alteração, documentam-se o nome, a resposta atual, o TTL, a pesquisa inversa, os resolvedores utilizados pelos clientes e os serviços dependentes. Com vários endereços, o estado inicial inclui também pesos, associação WAN, delegação NS, DNAT e caminho de retorno.

Num cluster HA, efetua-se um novo pedido DNS após um failover planeado. Numa publicação pública, testam-se também ambos os caminhos WAN e um novo fluxo da aplicação. Este artigo não pressupõe caches DNS sincronizadas nem uma ligação ativa sem interrupções.

Para o rollback:

1. Antes de uma migração planeada, reduzir o TTL e aguardar que o TTL anterior expire.
2. Documentar as aplicações dependentes e o caminho DNS público.
3. Repor o endereço, a interface ou a Host Entry no estado inicial confirmado.
4. Remover uma exceção temporária de Device Access e a publicação WAN que já não seja necessária.
5. Voltar a consultar explicitamente a partir da firewall e do cliente.
6. Voltar a testar a resolução direta, o PTR opcional, a acessibilidade e a aplicação real.

Checklist

• A Sophos Firewall vê o pedido DNS do cliente afetado.
• Um único nome estático é mais adequado do que uma DNS Request Route.
• O FQDN, a versão IP, o endereço e o TTL estão documentados.
• Publish on WAN permanece desativado para entradas internas.
• Uma entrada PTR só está ativada para o nome canónico do endereço.
• A firewall e o cliente devolvem a mesma resposta esperada.
• O acesso DNS está limitado às origens necessárias em Device Access.
• Com vários endereços, foram testados os pesos, o estado do link e o caminho da aplicação.
• Na publicação WAN, estão documentados a delegação NS, os endereços dos servidores DNS e um teste negativo de recursão.
• O rollback e o tempo de espera das caches são conhecidos antes da alteração.

Perguntas frequentes