Setting up Sophos DNS Protection with Sophos Firewall

Sophos DNS Protection secures DNS queries via a cloud-based DNS service with policies and reporting in Sophos Central. The feature can block malicious domains, phishing, command-and-control targets, and unwanted categories before a client even connects to the actual website or infrastructure.

With Sophos Firewall, the cleanest standard setup is usually: clients use the firewall as a DNS resolver, the firewall forwards public DNS queries to DNS Protection, and internal domains are sent to internal DNS servers via DNS Request Routes. This keeps internal name resolution stable while public DNS queries are centrally controlled and logged.

DNS Protection does not replace Web Protection, Threat Feeds, or NDR. It is a separate protection point at the DNS level. Therefore, the function should be planned consciously and not just replace public DNS servers.

Video Guide

Avanet Assessment: Use DNS Protection Consciously

DNS Protection is technically interesting but not automatically the best choice in every environment. In many projects, we deliberately do not use DNS Protection as a standard but prefer fast, highly available DNS resolvers and additionally block known malicious targets via Sophos Firewall Threat Feeds or comparable threat intelligence sources on the firewall.

The reason is simple: DNS is a basic function. If DNS is slow, not redundant, or generates too many false positives, users quickly feel that the entire network is defective. DNS protection must therefore not only be secure but also stable, fast, understandable, and well manageable.

The decision depends on the goal:

DNS Protection is particularly suitable when DNS logs in Sophos Central, location-based DNS policies, category filtering, or endpoint DNS protection for roaming clients are explicitly desired. If the primary goal is fast and highly available name resolution with additional blocking of known bad targets, good DNS resolvers plus threat feeds are often the more pragmatic solution.

When DNS Protection Makes Sense

DNS Protection is particularly strong when many clients access the internet through a central firewall or a local DNS resolver.

Typical use cases:

• Clients should not use arbitrary public DNS resolvers.
• Malware, phishing, and C2 domains should be blocked early.
• DNS queries should be visible in Sophos Central.
• Different locations should have their own DNS policies.
• Internal DNS names should continue to work via local DNS servers.
• Web Protection should be complemented by a pre-stage DNS control.

However, DNS Protection is not a substitute for content inspection. If an allowed domain later delivers harmful content or HTTPS traffic needs to be inspected more closely, Web Protection, TLS Inspection, IPS, endpoint protection, and logging remain relevant.

DNS Protection is not ideal if only a fast external DNS forwarder is sought or if a very stable DNS operation with separate threat feeds, Web Protection, endpoint protection, and clean monitoring already exists. In such cases, it should first be checked what additional value DNS Protection specifically brings and who manages the policy, exceptions, and false positives.

Architecture with Sophos Firewall

For Sophos Firewall, this setup is usually the clearest:

1. Sophos Central recognizes the location as a Location.
2. Sophos Central provides two DNS Protection IP addresses.
3. Sophos Firewall uses these IP addresses as DNS forwarders.
4. Internal domains are sent to internal DNS servers via DNS Request Routes.
5. DHCP distributes the firewall as a DNS resolver to clients.
6. Optionally, a NAT rule enforces that outgoing DNS traffic is redirected to the firewall.
7. DNS Protection logs and reports are evaluated in Sophos Central.

This setup ensures that clients do not need to be configured directly to the Sophos DNS service. The firewall remains the central resolver in the LAN and can better handle internal special cases.

Prerequisites

Before the rollout, these points should be clarified:

• Sophos Central access with permission for DNS Protection.
• Appropriate license: Xstream Protection for standalone DNS protection or Workspace Protection for endpoint DNS protection.
• Public WAN IP or a stable FQDN/DDNS name for the location.
• Sophos Firewall is used as a DNS resolver for the affected networks or is intended to be.
• Internal domains, Active Directory zones, and reverse lookups are known.
• DHCP servers for client networks are identified.
• Exceptions for internal domains and critical services are planned.
• Responsible parties for DNS policy, false positives, and logging are defined.

If the public IP address changes frequently, it should be clarified before the rollout whether a DDNS configuration is stable enough. Sophos DNS Protection can also identify locations via an FQDN, but an IP change can still lead to temporary interruptions.

1. Create Location in Sophos Central

In Sophos Central, the location is created first:

My Products > DNS Protection > Locations

Practical steps:

1. Select Add.
2. Enter location name and description.
3. Enter the public WAN IP of the Sophos Firewall.
4. For multiple WAN interfaces, enter all relevant public IP addresses or a suitable range.
5. Use a DDNS FQDN if the design is based on dynamic IP.
6. Save the location.

The location is important because DNS Protection must assign incoming DNS queries to the correct customer account and policy. If the location is missing or the public IP does not match, Sophos Central does not see the location correctly.

2. Copy DNS Protection IP Addresses

The DNS Protection IP addresses can be found in Sophos Central under:

My Products > DNS Protection > Installers

Two IP addresses are provided there. These are used on the Sophos Firewall as the primary and secondary DNS servers. Do not enter other public DNS servers as fallback if the traffic is to run entirely through DNS Protection. Otherwise, DNS servers may be used bypassing DNS Protection depending on the resolver’s behavior, and protection and visibility are lost.

3. Configure Sophos Firewall DNS Forwarder

On the Sophos Firewall:

Network > DNS

Recommended steps:

1. Select Static DNS.
2. Set DNS 1 to the first DNS Protection IP address.
3. Set DNS 2 to the second DNS Protection IP address.
4. Leave DNS 3 blank unless there is a specific exception.
5. Do not set separate IPv6 DNS servers under IPv6 if the location is to run via the IPv4-based DNS Protection servers.
6. Save and apply the settings.

DNS Protection operates as an IPv4-based DNS service but can also resolve IPv6 addresses. Therefore, a separate IPv6 DNS server is not automatically needed.

4. Protect Internal Domains with DNS Request Routes

DNS Protection does not resolve internal domains. If Active Directory, internal applications, local zones, or reverse lookups are used in the network, these queries must go to internal DNS servers.

For this, use on the Sophos Firewall:

Network > DNS > DNS request route

Example:

Without these routes, internal names would be sent to DNS Protection and not resolved correctly there. The exact procedure is described in Configure DNS Request Routes on Sophos Firewall.

For productive environments, internal domains should also be considered in DNS Protection as a domain list if the domain could be blocked by a category. Typical examples are internal sites or services that might otherwise fall under problematic categories like parked domains.

5. Use DHCP to Point Clients to the Firewall

Clients should use the Sophos Firewall as a DNS resolver, not directly arbitrary external resolvers.

If the Sophos Firewall provides DHCP:

Network > DHCP

Practical steps:

1. Edit the DHCP server of the affected interface.
2. Distribute the IP address of the firewall interface as the primary DNS server.
3. Do not distribute external DNS servers as alternative client DNS if DNS Protection is to be consistently applied.
4. Renew DHCP lease or reconnect test client.
5. Check with a test client which DNS server is actually used.

If a Windows DNS server or another internal resolver is in use, this resolver can forward to DNS Protection instead of the clients. However, it must be clear where internal domains are resolved and which server forwards public queries.

6. Prevent Direct DNS Bypass

Many clients use the DNS server distributed via DHCP. However, some devices, browsers, IoT systems, or deliberately configured clients can use their own DNS servers.

A possible countermeasure is a NAT rule that redirects outgoing DNS traffic from internal networks to the firewall. Practically, this means: DNS traffic from the internal source networks is redirected via DNAT to the internal firewall address so that the query can be evaluated via DNS Protection.

Important:

• Only capture internal source networks.
• Do not use WAN interfaces as inbound interface.
• Set the rule position consciously very high.
• Document exceptions for internal DNS servers and special cases.
• Then test whether internal DNS resolution, DNS Protection, and logs are still correct.

The NAT basics are explained in Understanding NAT on Sophos Firewall. DNS enforcement should not be activated blindly, as it can affect internal resolvers, VPN clients, DoH/DoT behavior, or special devices.

Plan Rollout in Phases

DNS Protection should not be enforced for all networks at once. DNS is a basic function: if internal names, certificate checks, software updates, or SaaS services are no longer resolved cleanly, it quickly feels like a general internet outage.

A controlled rollout looks like this in practice:

1. Select a pilot network or small test group.
2. Document internal domains, reverse zones, and search domains.
3. Set up DNS Request Routes for internal zones.
4. Distribute the firewall as a DNS resolver via DHCP.
5. Set DNS Protection IP addresses on the firewall.
6. Install block page certificate on test clients.
7. Check logs in Sophos Central.
8. Only then include further networks, guest network, server networks, or VPN networks.

For server networks, one should be particularly cautious. Some systems use DNS for license checks, updates, CRL/OCSP, backup, monitoring, or cluster communication. There, a test window with rollback is more important than in normal client networks.

Acceptance Test Before Broad Rollout

Before the productive rollout, it should be clear how to recognize a functioning DNS Protection implementation. The Sophos test link alone is not enough.

If any of these tests fail, the policy should not be opened immediately. First, it must be clear whether the problem lies with DHCP, DNS Request Routes, location assignment, client profile, browser DoH, VPN split tunnel, or domain categorization.

7. Plan Policies and Domain Lists

DNS Protection can block security-relevant domains even without its own policy if SophosLabs classifies them as a threat or security risk. Own policies complement this baseline with company guidelines.

Typical policy questions:

• Which locations get which policy?
• Which categories should be blocked?
• Which categories are only problematic for certain locations?
• Which domains must be explicitly allowed?
• Who decides on false positives?
• How long do exceptions remain valid?

Domain lists should be managed tightly. A broad allow list can reduce protection effectiveness. A broad block list can disrupt business processes. Each list needs a purpose, owner, and review date.

Filtering Policy or Endpoint DNS Protection Policy?

In Sophos Central, there are two policy levels that should not be confused.

A Filtering policy is created under DNS Protection > Policies > Filtering policies and assigned to one or more locations or firewalls. Only one filtering policy can be active per location. In this policy, categories, domain lists, and additional options like Safe Search are defined.

An Endpoint DNS Protection policy uses Sophos Endpoint. The endpoint intercepts DNS traffic on the device and securely forwards it via HTTPS to DNS Protection. This means the client does not need to be manually configured to the DNS Protection IP addresses. The devices are assigned to a DNS Protection location in the endpoint policy and are then controlled by the filtering policy appropriate to that location.

Practically, this means:

• For an office with Sophos Firewall, the location plus filtering policy is the normal network path.
• For roaming clients, the endpoint DNS protection policy is sensible because protection can also apply outside the corporate network.
• For mixed environments, both approaches are combined: firewall locations via locations, managed endpoints additionally via endpoint DNS protection.
• For internal domains, domain exclusions should be maintained in endpoint policies. Sophos recommends explicitly excluding internal zones rather than relying solely on an NXDOMAIN retry.
• Block pages on endpoints require the DNS Protection Root Certificate. With Sophos Endpoint, the certificate can be distributed automatically.

Which Categories Can Be Blocked?

DNS Protection offers categories organized into groups in Sophos Central. Some categories are more productivity-related, while others are clearly security-relevant. The names remain deliberately in English, as they are also displayed in Sophos Central.

Domain lists take precedence over categories. An allowed domain in a domain list remains allowed even if the category would be blocked. A blocked domain remains blocked even if the category would be allowed. Therefore, domain lists should be documented and regularly reviewed.

8. Block Pages and Certificates

For blocked domains, DNS Protection can display an HTTPS block page. For users to see this block page correctly, the DNS Protection Root Certificate must be installed as trusted on the affected devices.

If TLS Inspection or web filtering is also active on the firewall, the certificate and exception planning must match. For the firewall CA, see Distribute Sophos Firewall CA Certificate for TLS Inspection.

If block pages are not displayed, do not immediately adjust the policy. Often certificates are missing, the client uses a different DNS path, or blockpage.dnsprotection.sophos.com is disrupted by another control.

Test DNS Protection

Sophos Central provides a test link under DNS Protection > Installers. If the configuration is correct, the browser displays a confirmation.

Additionally, practical testing should include:

• Client uses the firewall as a DNS server.
• Public domain is resolved via DNS Protection.
• Internal domain is correctly resolved via DNS Request Route.
• Blocked test domain is blocked.
• Logs appear in Sophos Central.
• DNS queries appear at the correct location.
• Alternative DNS servers are not used.
• VPN or guest network behaves as planned.

For real error analysis, do not only test the browser. nslookup, dig, firewall logs, DHCP leases, and Sophos Central logs together provide a better picture.

Test Commands for Clients

On a test client, first check which DNS server is actually used. A successful browser test is not enough if the client is simultaneously using another resolver, DoH, or a VPN profile.

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:

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

Replace <firewall-ip> with the internal interface address of the Sophos Firewall that should serve as the DNS resolver in the respective network. If the query against the firewall works, but the normal query uses another resolver, the problem usually lies with DHCP, operating system profile, VPN client, browser DoH, or a local DNS configuration.

For internal domains, an additional test with an internal zone should be conducted:

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

This test must land at the internal DNS server via the appropriate DNS Request Route. If public domains work but internal names do not, DNS Protection is rarely the actual cause. Then DNS Request Routes, internal DNS servers, search domains, and client DNS suffixes should be checked.

Troubleshooting

Location Does Not Appear in Sophos Central

Check whether the public WAN IP or the DDNS FQDN in the location is correct. For multiple WAN lines, all relevant outgoing addresses must be considered. With dynamic IP addresses, there may be short delays until DNS Protection recognizes the change.

Internal Names No Longer Work

Then DNS Request Routes are usually missing, or the clients are not querying the expected resolver. Internal AD domains, reverse zones, and application domains should be explicitly forwarded to internal DNS servers.

DNS Protection Blocks an Internal or Legitimate Domain

First, clarify whether the domain is internal, public, miscategorized, or actually risky. Then check the domain list and policy. Do not set a broad allow rule before the cause and affected users are known.

Logs Remain Empty

If no logs appear in Sophos Central, the client may not be using DNS Protection. Check: DHCP, client DNS, firewall DNS, NAT redirection, alternative resolvers, VPN profile, and whether the location is correctly recognized in Sophos Central.

Block Page Does Not Appear

Then often the DNS Protection Root Certificate is not installed, the client uses a different DNS path, or another security control affects the connection. Also, check TLS Inspection and Web Protection.

DoH or Private DNS Bypasses Control

Browsers and operating systems can use DNS over HTTPS or private DNS functions. Depending on the environment, these functions must be controlled via browser, MDM, or operating system policy. DNS Protection on the network path only helps if the queries actually run through the intended resolver.

VPN Clients Behave Differently Than LAN Clients

For VPN clients, behavior strongly depends on the profile. Full tunnel, split tunnel, DNS suffixes, search domains, and local resolvers of the client can influence name resolution. If DNS Protection works in the LAN but not over VPN, first check VPN profile, assigned DNS servers, DNS suffixes, and firewall rules. For remote access environments, additionally see Sophos Connect or SSL VPN: Which Remote Access Solution Fits?.

Operational Recommendation

DNS Protection should be operated like a security control, not like a one-time DNS server swap.

From Avanet’s perspective, one should honestly decide beforehand whether DNS Protection is actually the right tool for the environment. For many classic firewall installations, fast, redundant DNS resolvers plus well-maintained threat feeds on the firewall are the more robust operational variant. DNS Protection is especially worthwhile if the operation also actively uses the Central policies, logs, categories, domain lists, and endpoint component.

Regularly check:

• Locations and WAN IP addresses are correct.
• DHCP continues to distribute the correct DNS servers.
• Internal DNS Request Routes are up to date.
• Policies and domain lists have owners and review dates.
• Logs are evaluated.
• Blocked top domains are checked for false positives.
• New locations, VPN networks, and guest networks are considered in the design.

For detection topics, Operate Sophos Firewall NDR and Active Threat Response can complement. For known malicious IPs, domains, and URLs at the firewall level, Sophos Firewall Threat Feeds remain relevant.

Checklist

• Checked Sophos Central DNS Protection license.
• Location created as a location.
• Public WAN IP or DDNS FQDN correctly entered.
• Copied DNS Protection IP addresses from Central.
• Sophos Firewall uses DNS Protection as a DNS forwarder.
• Internal domains covered with DNS Request Routes.
• DHCP distributes the firewall as a DNS resolver.
• Checked and redirected direct DNS bypass via NAT if necessary.
• Planned DNS Protection Root Certificate for block pages.
• Successfully checked test link from Sophos Central.
• Controlled logs and reports in Sophos Central.
• Defined false-positive process and domain list review.

FAQ