Gerir Locations do Sophos DNS Protection em segurança

Uma Location indica ao Sophos DNS Protection a que local, rede ou conjunto de dispositivos pertence uma consulta DNS. Só esta associação permite aplicar Filtering policies específicas por local e obter relatórios relevantes. Para um funcionamento estável, uma Location deve representar a saída para a Internet, e não cada VLAN interna.

O processo completo começa em My Products > DNS Protection > Locations: escolher o método de ligação, criar a Location, verificar a associação na página Policies, testar o percurso DNS real e só depois remover endereços IP ou Locations antigos. A Default location é um ponto de partida Secure DNS imutável; as Locations personalizadas representam locais, regiões ou grupos de policies distintos.

Escolher entre Default e uma Location personalizada

A Default location predefinida utiliza Secure DNS e funciona sem um endereço público registado para o local. Pode ser associada tanto a uma Endpoint policy como a uma Filtering policy. É possível consultar os respetivos detalhes em My Products > DNS Protection > Locations > Default, mas não é possível editá-la nem eliminá-la.

Uma Location personalizada é adequada se se verificar pelo menos uma destas situações:

Uma firewall, um router ou um resolvedor DNS local envia consultas DNS tradicionais.
Os locais ou grupos de dispositivos necessitam de Filtering policies diferentes.
Os relatórios devem separar as consultas DNS por região ou saída para a Internet.
Os dispositivos Endpoint necessitam de uma associação Secure DNS própria em vez de Default.

O DNS Protection permite, no máximo, 50 Locations. Uma Location personalizada pode utilizar Secure DNS, Traditional DNS over IPv4 ou ambos os métodos. Cada Location pode conter, no máximo, 100 endereços IPv4 públicos ou FQDN.

Escolher o método de ligação adequado

Secure DNS

O Secure DNS transporta DNS através de HTTPS. Este método é adequado para dispositivos compatíveis e obrigatório para o Sophos Endpoint com DNS Protection. Ao guardar, o Central gera um DNS over HTTPS URL individual. O Sophos Endpoint configura automaticamente os dispositivos geridos; o URL é necessário para configurar manualmente um dispositivo.

Para esta implementação, têm de ser utilizados e copiados exatamente os dois endereços IPv4 do DNS Protection apresentados pelo Central.

Traditional DNS over IPv4

O Traditional DNS over IPv4 envia DNS sem encriptação para os resolvedores do DNS Protection. Este método é adequado para firewalls, routers e servidores DNS locais. O DNS Protection identifica a Location através do IP de origem público. Por isso, deve registar-se o endereço WAN público, um intervalo público ou um FQDN que aponte para esse endereço — nunca um endereço RFC 1918 interno.

A configuração completa da firewall, incluindo forwarders, zonas internas e DHCP, faz parte do guia separado sobre o Sophos DNS Protection com o Sophos Firewall. A Location, por si só, ainda não altera qualquer percurso DNS na rede.

Ambos os métodos

Ambas as opções podem estar ativas na mesma Location personalizada. Isto é útil quando o mesmo contexto de policy inclui tanto endpoints geridos através de DoH como um resolvedor local através de DNS tradicional. Antes disso, deve decidir-se conscientemente se estes dois percursos devem realmente receber a mesma filtragem e constar dos mesmos relatórios.

Pré-requisitos e plano de endereçamento

Antes de criar a Location, registe:

um nome único, uma descrição breve e o responsável técnico,
o método de ligação pretendido,
todos os endereços públicos de saída utilizados por multi-WAN, SD-WAN e failover,
um FQDN DDNS devidamente mantido para um endereço público dinâmico,
a Filtering policy prevista e, quando aplicável, a Endpoint policy,
um dispositivo de teste ligado diretamente a cada percurso DNS.

Default é um nome reservado. ZH-HQ-Egress é adequado para exemplos; a descrição pode incluir o fornecedor, as ligações WAN e o responsável. O nome de um local deve permanecer estável, mesmo que o fornecedor mude.

Para efetuar alterações no DNS Protection, é necessária uma função de administração adequada no Sophos Fusion. Um acesso só de leitura é apropriado para verificação, mas não para criar, editar ou eliminar. O registo manual de um endereço IP público ou FQDN não comprova a autorização para utilizar o serviço.

O DNS autónomo ou baseado na rede requer, pelo menos, uma firewall válida associada ao Central com Xstream Protection. Em contrapartida, o Endpoint DNS gerido é uma funcionalidade do Workspace; o Xstream, por si só, não é suficiente. Add known IPs deteta apenas endereços públicos de Sophos Firewalls licenciadas com Xstream Protection. O Secure DNS requer um dispositivo capaz de processar DNS através de HTTPS; para o DNS Protection, o Sophos Endpoint exige expressamente este método de ligação.

Criar uma Location personalizada

Abra My Products > DNS Protection > Locations > Add location. Na lista de Locations, o botão Add abre este diálogo.
Introduza um nome único em Location name e a finalidade em Description.
Em Connection method, ative Secure DNS, Traditional DNS over IPv4 ou ambos.
Para Secure DNS, registe os endereços IPv4 apresentados. O DNS over HTTPS URL só é gerado ao selecionar Save.
Para Traditional DNS over IPv4, adicione os valores públicos em IPv4 addresses or FQDNs. Confirme cada entrada individual com Enter ou Tab. Ao colar vários valores, tem de existir uma quebra de linha entre eles.
Selecione Save.
Para Secure DNS, copie e guarde em segurança o DNS over HTTPS URL gerado antes de selecionar Close.

Utilizar os endereços detetados

Add known IPs apresenta sugestões:

Your Current Location é o endereço de origem da sessão atual do Central. Durante uma sessão VPN, corresponde ao endereço público do servidor VPN e pode não ser o endereço do local pretendido.
Your Firewalls apresenta o endereço através do qual uma Sophos Firewall licenciada acede ao Central. Só são detetadas automaticamente firewalls com Xstream Protection.

Um valor detetado é apenas uma sugestão. O DNS Protection não o atualiza automaticamente após alterações posteriores do endereço. Em multi-WAN, os endereços de saída não detetados têm de ser adicionados manualmente.

IP, FQDN, multi-WAN e DDNS

Numa ligação estática, o endereço IPv4 público é geralmente a opção mais clara. Em multi-WAN, devem registar-se todos os endereços pelos quais as consultas DNS podem efetivamente sair; em alternativa, pode utilizar-se um intervalo público adequado. Se o endereço de failover não estiver incluído, o DNS Protection não funcionará para esta Location após a mudança de ligação.

Para um endereço dinâmico, introduza um FQDN de um serviço DDNS de terceiros. O cliente DDNS tem de atualizar o registo de forma fiável. Se utilizar o Sophos Firewall para esse efeito, Configurar e verificar o Dynamic DNS no Sophos Firewall explica a configuração em Network > Dynamic DNS > Add. O DNS Protection verifica alterações de endereço a cada minuto e demora depois oito segundos a atualizar a respetiva cache. A resolução de nomes pode ser interrompida por breves instantes durante a atualização do fornecedor, do DDNS e da cache.

Os serviços suportados são DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS e Cloudflare. No Cloudflare, Proxy status tem de estar definido como DNS only; um registo com proxy devolve endereços da Cloudflare em vez do IP público de saída.

CGNAT e conflitos de endereços

O Traditional DNS requer um IP de origem público único. Com CGNAT e endereços de saída partilhados de fornecedores, proxies ou VPN, o mesmo IP pode surgir em várias contas de clientes. O DNS Protection dá prioridade ao utilizador que criou primeiro a Location. Um FQDN diferente não resolve o problema se apontar para o mesmo IP partilhado.

A solução fiável é obter um endereço público único junto do fornecedor ou utilizar Secure DNS nos dispositivos compatíveis. Os endereços privados, como 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, não identificam a saída para a Internet e não devem ser adicionados à Location.

Concluir a associação de policies

Uma Location permite associar as consultas DNS recebidas, mas ainda não define a filtragem pretendida.

Em My Products > DNS Protection > Policies > Filtering policies, mova a Location de Available para Assigned to this policy. Uma Location só pode estar associada a uma Filtering policy.
Numa Endpoint policy, atribua uma Location aos dispositivos Windows selecionados. Esta tem de utilizar Secure DNS; a Default location também é válida.

O percurso de Endpoint, as Domain Exclusions internas e o componente Agent fazem parte do guia separado sobre endpoints. Uma associação a uma Endpoint policy não substitui uma Filtering policy: a primeira determina quais os dispositivos que utilizam a Location e a segunda determina o tratamento dos respetivos domínios e categorias.

Editar uma Location

Antes de qualquer alteração, documente primeiro o nome, os métodos, a lista de IP/FQDN, a utilização de DoH e ambas as associações de policies. Em seguida, abra a Location personalizada em My Products > DNS Protection > Locations, ajuste os valores e guarde com Save.

Para uma migração segura da saída, siga esta sequência:

Adicione o novo endereço público sem remover o antigo.
Aguarde até que o novo percurso de Internet esteja ativo.
Verifique a resolução DNS e a aplicação da policy através do novo percurso.
Só depois remova o endereço antigo.

Ao passar de Traditional DNS para Secure DNS, configure e valide primeiro o percurso DoH num grupo piloto. Mantenha o Traditional DNS ativo até o teste ser concluído com êxito. Isto evita uma transição não testada e permite regressar rapidamente ao percurso anterior.

Validação após a criação ou alteração

Em My Products > DNS Protection > Locations, verifique se Location, Description e o número apresentado em IP addresses/FQDNs estão corretos.
Abra a Location e, nos respetivos detalhes, verifique se estão configurados a Connection method pretendida e os valores IP/FQDN esperados.
Em Policies, confirme que a Location está associada à Filtering policy pretendida e, quando aplicável, à Endpoint policy.
Resolva um domínio comprovadamente permitido e um domínio de teste bloqueado intencionalmente pela policy atribuída, exatamente através do percurso DNS afetado. Tenha em conta a cache e o TTL do DNS.
Verifique no dashboard ou nos relatórios se a consulta aparece na Location esperada.

Uma resolução de nomes bem-sucedida, por si só, não comprova a policy nem a Location corretas. Apenas a combinação de um teste positivo, um teste bloqueado e uma entrada correspondente no relatório confirma todo o percurso. Se a consulta não aparecer, compare primeiro o IP de origem público real com IP addresses/FQDNs; no caso de um FQDN inválido ou de um conflito de IP, verifique em seguida My Environment > Alerts.

Resolver problemas por sintoma

A Location não aceita o endereço

As entradas estáticas e os nomes de host só são suportados para IPv4. Um endereço privado ou IPv6 não constitui uma saída válida do local. Introduza o endereço WAN público ou um FQDN que seja resolvido para o mesmo e conclua cada valor com Enter ou Tab.

A resolução para ou a Location não aparece nos relatórios

Compare a saída real com a lista de IP/FQDN guardada. Em multi-WAN, pode estar ativo um endereço de failover não registado. Para um FQDN, confirme primeiro que este é resolvido para um endereço IPv4 público válido. O Central comunica FQDN incorretos e conflitos de IP em My Environment > Alerts.

Conflito de IP ou CGNAT

Se o mesmo IP público já pertencer a outro cliente, a Location criada primeiro mantém a prioridade. Um alias para o mesmo IP não altera esta situação. Solicite ao fornecedor um endereço IPv4 público único ou utilize Secure DNS nos dispositivos adequados.

Falha de DDNS após uma alteração de endereço

Confirme se o registo DDNS já devolve o novo endereço público. Depois, aguarde pelo menos o ciclo de atualização do DNS Protection e a atualização da cache. No Cloudflare, verifique DNS only. Não remova o IP antigo até que o novo valor e a saída real coincidam.

A policy não é aplicada

Verifique a que Location a consulta foi efetivamente associada e a que Filtering policy pertence essa Location. Só pode ser aplicada uma Filtering policy por Location. Após uma alteração de policy, um registo DNS já existente em cache pode continuar a funcionar até que o respetivo TTL expire; por isso, repita o teste com um nome novo ou após a expiração da cache.

Outros resolvedores contornam o DNS Protection

Se os clientes receberem servidores DNS tradicionais ou IPv6 adicionais, as consultas podem contornar o DNS Protection. Distribua exclusivamente o percurso DNS Protection previsto para a resolução pública. O DNS Protection baseia-se em IPv4, mas também consegue resolver registos AAAA; não é necessário um resolvedor IPv6 separado para esse efeito.

Operação e ciclo de vida

As Locations devem ser verificadas após uma mudança de fornecedor, WAN, DDNS ou policy e também regularmente durante a operação. Na lista, compare Location, Description e o número em IP addresses/FQDNs com o estado pretendido documentado. Verifique a Connection method nos detalhes da Location e a associação na página Policies. Os endereços sugeridos automaticamente não constituem uma sincronização permanente: se um endereço IP detetado anteriormente mudar, é necessário ajustar a Location ou o nome DDNS mantido e voltar a validar.

Para os procedimentos operacionais, as páginas de ajuda atuais são a referência. As notas de versão situam no tempo alterações como as sugestões automáticas de endereços IP, a função para copiar endereços IP e FQDN ou a apresentação de Locations associadas nas policies; não substituem um guia de configuração atual. À data de 24 de setembro de 2026, as páginas de ajuda e as notas de versão atuais não incluem uma data concreta para a desativação do DNS Protection.

Eliminar uma Location personalizada em segurança

A Default location não pode ser eliminada. Para uma Location personalizada, siga esta sequência:

Guarde o nome, a descrição, os métodos de ligação ativados, os valores IP/FQDN, as associações de policies e o URL DoH existente. Documente também todas as firewalls, todos os resolvedores e todos os dispositivos configurados manualmente que utilizam a Location.
Se o percurso DNS continuar a ser necessário, crie e configure uma Location de substituição. Esta só pode funcionar em paralelo com a Location antiga se utilizar uma identidade própria e inequivocamente encaminhável ou um novo percurso Secure DNS disponibilizado.
Se utilizar uma Location de substituição, associe-a às Filtering e Endpoint policies pretendidas. Em seguida, transfira primeiro um percurso piloto controlável para a Location de substituição, por exemplo, dispositivos piloto, um resolvedor ou — se operacionalmente possível — uma firewall.
Para uma Location de substituição, resolva através do percurso piloto um domínio permitido e um domínio bloqueado pela policy atribuída. Verifique nos relatórios se ambas as consultas estão associadas à Location de substituição. Só após uma verificação bem-sucedida deve transferir as restantes firewalls, os restantes resolvedores e os dispositivos configurados manualmente. Se o percurso DNS for desativado sem substituição, termine a respetiva utilização em todos os sistemas documentados. Em seguida, remova a Location antiga das policies anteriores e confirme que deixou de ser utilizada.
Só agora, em My Products > DNS Protection > Locations, selecione a Location antiga e depois Delete.
Para uma Location de substituição, volte a verificar através do novo percurso a resolução permitida e bloqueada, bem como a associação nos relatórios. Em caso de desativação sem substituição, confirme que os restantes percursos DNS funcionam conforme previsto.

Se uma Location de substituição com Traditional DNS tiver de utilizar a mesma identidade pública e, por esse motivo, não puder coexistir de forma inequívoca com a Location antiga, tem de parar antes de selecionar Delete. A migração planeada e o risco de conflito têm de ser documentados; a eliminação só pode ser executada para a mudança conscientemente aprovada. Neste caso, a Location de substituição não deve ser considerada validada em paralelo.

A recriação com o nome, a descrição, os métodos, os valores IP/FQDN e as associações de policies guardados constitui apenas a melhor tentativa possível de recuperação, não um regresso garantido ao estado anterior. No caso de uma identidade Traditional DNS pública disputada, não repõe de forma fiável a prioridade da Location criada primeiro. No Secure DNS, a recriação gera um novo DNS over HTTPS URL, que tem de ser novamente distribuído por todos os dispositivos configurados manualmente. Quando aplicável, volte a ligar as firewalls e os resolvedores ao percurso tradicional. Em seguida, volte a testar a resolução permitida e bloqueada, bem como os relatórios.