Setting up Sophos DNS Protection with Sophos Firewall

Sophos DNS Protection checks DNS queries through a cloud service and manages policies and reports in Sophos Central. It can block malicious domains, phishing, command-and-control targets, and unwanted categories before a client establishes the actual connection.

With Sophos Firewall, the cleanest standard setup is usually: clients use the firewall as their DNS resolver, the firewall forwards public queries to DNS Protection, and internal domains go to internal DNS servers through DNS Request Routes.

DNS Protection does not replace Web Protection, Threat Feeds, or NDR and Active Threat Response. It complements these controls at the DNS layer.

Decision and target architecture

DNS is a core service. If the resolver is slow, unstable, or too restrictive, users quickly perceive it as a general network outage. DNS Protection should therefore be used only when the benefits of Central policies, categories, logs, or protection for roaming clients justify the additional operational effort.

From Avanet’s perspective, fast, redundant resolvers combined with well-maintained Threat Feeds are the more pragmatic solution for many traditional firewall installations. DNS Protection is particularly suitable when:

• DNS queries need to be visible in Sophos Central.
• Locations require different DNS policies.
• Categories should be blocked during name resolution.
• Clients must not use arbitrary public resolvers.
• managed Windows endpoints also require protection outside the corporate network.

The recommended firewall path is:

1. Sophos Central knows the site as a Location.
2. Sophos Central provides two DNS Protection IP addresses.
3. Sophos Firewall uses both addresses as DNS forwarders.
4. DNS Request Routes send internal zones to internal DNS servers.
5. DHCP distributes the firewall as the resolver to clients.
6. An optional NAT rule forces classic DNS traffic onto this path.
7. Sophos Central logs and evaluates the public DNS queries.

Two methods must be distinguished:

• Traditional DNS over IPv4: for firewalls, routers, and local resolvers. Sophos assigns queries to the Location using the public source IP or a DDNS FQDN.
• Secure DNS: DNS over HTTPS (DoH) for compatible devices. Sophos Endpoint can manage this path on supported Windows endpoints; Windows and macOS can also be configured manually for Secure DNS.

A custom Location can support both methods. For firewall forwarding, Traditional DNS must be enabled and the public IP or FQDN must be stored.

Before rollout, clarify the license, public egress addresses, internal DNS zones, DHCP servers, and ownership of policies and exceptions. Xstream Protection covers standalone DNS Protection. Endpoint DNS Protection requires Workspace Protection and an appropriate Sophos Endpoint license.

The predefined Default Location can be used for Secure DNS and assigned policies; it simply cannot be edited or deleted. A maximum of 50 Locations and 100 public IPv4/FQDN entries per Location are supported. Locations should therefore be organised by site and internet egress rather than by every VLAN.

Set up DNS Protection

1. Create a Location in Sophos Central

My Products > DNS Protection > Locations

1. Select Add and enter a unique site name.
2. Enable Traditional DNS over IPv4.
3. Enter the public WAN IP or a stable DDNS FQDN.
4. With multi-WAN, include every egress address that is actually used.
5. Save the Location.

Private IP addresses are invalid. Sophos must recognise the public source IP through which the query reaches the service. For dynamic addresses, Sophos checks the DDNS name regularly, but a change can still cause a brief interruption. With Cloudflare, the DDNS record must be set to DNS only and must not use the proxy.

With CGNAT or a shared provider IP, the address is assigned to the customer account that registered it first. An FQDN does not solve this issue if it resolves to the same shared IP; a unique public IP is required.

2. Copy the DNS Protection IP addresses

My Products > DNS Protection > Installers

Two DNS Protection IP addresses are listed under Installers. Always copy these values from the organisation’s own Central tenant and use them as DNS 1 and DNS 2. A third-party resolver used as an additional fallback can bypass protection and visibility.

The IP addresses remain available when Secure DNS is enabled. The important point is that Traditional DNS with the public egress address is also configured in the Location for the firewall path.

3. Configure the firewall as a DNS forwarder

Network > DNS

1. Select Static DNS.
2. Set DNS 1 and DNS 2 to the two Central addresses.
3. Leave DNS 3 empty unless there is a deliberately documented exception.
4. Under IPv6, also select Static DNS and do not enter IPv6 DNS servers.
5. Enable Choose IPv4 DNS server over IPv6.
6. Save the configuration.

The service operates over IPv4 but can also resolve AAAA records and therefore IPv6 destinations. With SD-WAN, failover, or policy routing, the actual egress path must use a public address stored in the Location.

4. Forward internal domains

Network > DNS
DNS request route section > Add

DNS Protection does not resolve internal zones. DNS Request Routes are therefore required for Active Directory, internal applications, and reverse lookups.

Example:

• Host/domain name: firma.local or corp.example.com
• Target servers: internal domain controllers or DNS servers

The complete procedure is described in Configure DNS Request Routes on Sophos Firewall. Internally used, publicly registered domains should also be allowed in a Domain List if a category such as Parked Domains blocks them.

5. Point clients to the firewall through DHCP

Network > DHCP

1. Edit the DHCP server for the affected network.
2. Distribute the internal interface IP of the firewall as the DNS server.
3. Renew the lease on a test client.
4. Check the resolver that the client actually uses.

Sophos shows the firewall IP as Primary DNS and a DNS Protection IP as Secondary DNS in its example. However, clients do not necessarily treat the second entry as an emergency server only. Direct queries to DNS Protection bypass the firewall’s DNS Request Routes. In networks with Active Directory or internal zones, redundancy should therefore be implemented in the resolver path rather than through an arbitrary second client DNS server.

6. Prevent direct DNS bypass

An optional DNAT rule can redirect classic DNS traffic from internal clients to the firewall:

• Original source: affected internal networks
• Original destination: outbound host group or Internet IPv4
• Original service: DNS
• Translated destination: internal firewall IP
• Inbound interfaces: only interfaces matching the internal sources, never WAN
• Position: near the top, before more general NAT rules

Exceptions for internal DNS servers and special devices must be documented. The rule captures DNS on UDP/TCP 53 only. DoH and DoT require separate browser, MDM, endpoint, or Web Policy controls. Test internal name resolution, VPN, guest networks, and logs before activation. The rule mechanics are explained in more detail in Understanding NAT on Sophos Firewall.

Policies, endpoints, and Block Pages

Filtering Policy and Domain Lists

A Filtering Policy is assigned to one or more Locations under DNS Protection > Policies > Filtering policies. Only one Filtering Policy can be active per Location. In addition to categories, Domain Lists and options such as Safe Search can be configured.

Domain Lists should have a purpose, owner, and review date. An Allow List overrides normal category decisions, but it does not override classification by SophosLabs as a Threat or Security Risk. An allowed domain can also remain blocked when its CNAME target belongs to a blocked category.

The following decisions are particularly important for categories:

• Infrastructure: normally allow Content delivery, CRL, and OCSP, because updates and certificate validation may depend on them.
• Threats and liabilities: generally block categories such as Phishing, Malware, Newly Registered Websites, or Anonymizers and resolve false positives specifically.
• Data loss: assess cloud storage and webmail according to DLP and compliance requirements.
• Uncategorized: do not block blindly; new legitimate or internal services can temporarily be uncategorized.
• Productivity, social media, and bandwidth: decide by network and business requirements, not as a blanket security rule.

Endpoint DNS Protection

The Endpoint DNS Protection Policy is intended for managed Windows endpoints that also require protection outside the corporate network. Sophos Endpoint intercepts DNS queries and sends them over HTTPS to the Secure DNS Location. The associated Filtering Policy determines the actual filtering.

The policy currently supports neither Windows Server nor macOS. There is a separate manual Secure DNS profile path for macOS; Linux, mobile devices, and special-purpose devices also require their own network, VPN, or MDM solution. Check the current endpoint package requirements in Sophos Central before rollout because they can change at short notice.

Internal zones are explicitly maintained as Domain Exclusions in the Endpoint Policy. This is more reliable than an NXDOMAIN retry and avoids unnecessary external queries. The DNS Protection Root Certificate can be distributed automatically to supported endpoints.

Root Certificate and Block Page

For HTTPS Block Pages, clients must trust the DNS Protection Root Certificate. It is not the same certificate as the firewall CA for TLS Inspection; its distribution is described in Distribute the Sophos Firewall CA certificate for TLS Inspection.

The certificate and configuration test are available under DNS Protection > Installers. In addition, blockpage.dnsprotection.sophos.com must be reachable.

In Web Proxy Mode, Pharming Protection can interfere with the Block Page. Before disabling protection globally, allow the Block Page domain through a specific HTTP/HTTPS firewall rule without web filtering and set it to Do not decrypt in a TLS rule.

Pilot, rollout, and acceptance

Enable DNS Protection in a small pilot network first. Document internal zones, reverse lookups, and critical services, configure DNS Request Routes, and prepare a clear rollback to the previous resolvers. Server networks require a separate test window because license validation, updates, CRL/OCSP, backups, or cluster communication may depend on DNS.

The following tests must pass before a broad rollout:

• a public domain is resolved through the intended resolver.
• an internal AD domain and reverse lookup work through DNS Request Routes.
• the configuration test under Installers shows the expected confirmation.
• a harmless domain deliberately blocked by a test policy is blocked and assigned to the correct Location.
• logs appear in Sophos Central after the expected reporting delay.
• the guest network uses the planned DNS path but no internal DNS servers.
• the VPN client receives appropriate resolvers and DNS suffixes.
• browser DoH, Private Relay, or local profiles do not unexpectedly bypass the control.
• rollback to the previous resolver has been tested or is clearly documented.

Test commands for clients

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux with systemd-resolved and dig installed:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

Replace <firewall-ip> with the internal interface address of Sophos Firewall. If the explicit query to the firewall works but the normal query does not, the cause is usually DHCP, VPN, browser DoH, or a local DNS configuration. The commands show the client resolver used and its response, but they do not prove by themselves which upstream the firewall uses.

Test an internal zone:

dig @<firewall-ip> interner-host.corp.example.com

This query must reach the internal DNS server through the appropriate DNS Request Route.

Troubleshooting

Location does not appear in Sophos Central

Check the public WAN IP, DDNS FQDN, and the actual multi-WAN egress. A source IP that is not configured can be rejected by the DNS Protection service. For dynamic addresses, check that the FQDN resolves externally to the current IP; Cloudflare records must be set to DNS only.

Invalid FQDNs and IP conflicts appear under My Environment > Alerts. With CGNAT or shared proxy/VPN egress, the first registered Location wins. A different FQDN pointing to the same IP does not change this assignment.

Internal names no longer work

Check DNS Request Routes, internal DNS servers, reverse zones, search domains, and client suffixes. Also ensure that the client uses the firewall or the intended internal resolver and does not query a DNS Protection IP directly.

Internal or legitimate domain is blocked

Check categorisation, the Domain List, and the CNAME target. A narrow exception is better than opening an entire category. SophosLabs Threat and Security Risk classifications cannot be overridden with an Allow Domain List.

Logs remain empty

Dashboard and reports lag behind real time by approximately 15 to 25 minutes. Only after that should DHCP, client DNS, firewall DNS, NAT redirection, alternative resolvers, VPN profiles, and Location assignment be checked.

With EDR, XDR, or MDR, Threat Analysis Center > Live Discover can additionally analyse DNS Protection data such as domain, Policy Action, Location, and source IP. User and device fields are available for endpoint data in the standard reports, not in the documented firewall DNS schema for Live Discover.

Block Page does not appear

Check the DNS Protection Root Certificate, the DNS path, and the reachability of blockpage.dnsprotection.sophos.com. In Web Proxy Mode, also check Pharming Protection, the HTTP/HTTPS rule, and the Do not decrypt TLS exception. VPN, browser DoH, and Apple Private Relay can also route the test around DNS Protection.

DoH or Private DNS bypasses the control

A NAT redirection for port 53 does not capture DoH or DoT. Browser, operating system, and MDM policies must control such resolvers. Secure DNS in DNS Protection uses DoH; a dedicated DNS Protection mode over DoT is not documented.

VPN clients behave differently from LAN clients

Check assigned DNS servers, DNS suffixes, Split DNS, Full or Split Tunnel, and local resolvers. DNS Protection may work in the office but still be bypassed for Remote Access. The basic VPN options are explained in Sophos Connect or SSL VPN: Which Remote Access solution fits?.

Operation

DNS Protection is not a one-time DNS server replacement. Check the following regularly:

• Locations, public egress addresses, and DDNS resolution.
• DHCP settings and internal DNS Request Routes.
• policies, Domain Lists, owners, and review dates.
• top blocked domains and documented false positives.
• new sites, guest networks, VPN paths, and endpoint platforms.
• certificate distribution and reachability of the Block Page domain.
• reports after changes and the defined rollback path.

If these tasks cannot be maintained over time, robust resolvers and targeted security controls are often the better choice. DNS Protection is worthwhile where policies, reporting, and endpoint protection are actually used and monitored.