Plan and set up the Sophos DNS Protection network

Sophos DNS Protection can protect either a central DNS resolver at a site or connect compatible devices directly through Secure DNS. The key decision is therefore not the firewall vendor, but where DNS is resolved, how internal zones remain available, and how Sophos identifies the site.

Quick path: In a managed site network, clients should normally keep using the existing local resolver as their DNS server. It forwards only public queries to the two DNS Protection IP addresses shown in Sophos Fusion (formerly Sophos Central). Internal zones continue to use their authoritative internal DNS servers. Secure DNS suits managed individual devices and mobile users. Test both approaches with a small pilot group first, and never add an unprotected public resolver as a third fallback.

Target architecture and boundaries of responsibility

The network path consists of four separate roles:

The client sends the query to the resolver assigned through DHCP, VPN, MDM, or local configuration.
A local resolver chooses between internal zones and public names.
The firewall, router, and NAT determine the public source IP and actual egress.
DNS Protection maps the query to a Location, applies its policy, and returns the answer.

With Secure DNS, the device instead sends the query to DNS Protection using DNS over HTTPS (DoH). This path bypasses the local DNS forwarder. Port 53 redirection, local caching, and conditional forwarding do not apply to it.

This article covers vendor-neutral architecture and the requirements for third-party firewalls. Device-specific configuration is in Set up Sophos DNS Protection with Sophos Firewall.

Prerequisites, licensing, and roles

Before changing the network, the intended Location and authorized Sophos Fusion access must be available. Check the license entitlement in advance: standalone DNS Protection is included with Xstream Protection, whereas Endpoint DNS Protection requires Workspace Protection and Secure DNS. These two deployment models use different data paths and must not be treated as interchangeable.

The Location must be created before device deployment. The person responsible for each platform then distributes the tenant values by following the appropriate device instructions and configures Windows, macOS, or Windows Server as required. Managed Windows devices are handed over to the person responsible for the Endpoint DNS Protection Policy instead of maintaining manual profiles. Installing, renewing, and removing trust belong in the separate process for the DNS Protection Root Certificate, not in this setup procedure.

Choose Traditional DNS or Secure DNS

Local resolver or Firewall forwarder

Choose this approach when a site already uses a router, firewall, Windows DNS, or another Local resolver. The local resolver or Firewall forwarder sends public queries to Sophos using Traditional DNS over IPv4. DNS Protection identifies the Location by the public IPv4 source address or by the FQDN stored in the Location.

The advantages are central caches, a consistent path for many device types, and conditional forwarding for internal zones. The limitation is that behind the same public source IP, DNS Protection sees the site but does not automatically identify every user or device. A changing, shared, or incorrect egress address can prevent the assignment.

Manual device DNS or Secure DNS

Manual device DNS configures the two DNS Protection IP addresses directly on the device. Secure DNS, by contrast, uses DoH over HTTPS and suits managed devices, roaming clients, and networks where the local resolver cannot be changed. It also protects the device path outside the office. Internal names, VPN split DNS, and applications with their own resolver must be handled explicitly. Manual device configuration is not the same as managed Workspace deployment through an Endpoint Policy.

For this path, open or create the intended Location, enable Secure DNS, and select Save. Sophos Fusion then generates the location-specific DNS over HTTPS URL. Give the complete URL or generated profile to the person responsible for Windows, macOS, or MDM. For Sophos Endpoint, give the person responsible for the Endpoint Policy the Location and pilot group so they can select that Location in the policy. Do not construct a URL yourself or copy one from another Location.

Recommended choices

Site with Active Directory or internal zones: local resolver with conditional forwarding; send only public queries to DNS Protection.
Simple network without internal zones: DHCP can distribute the two DNS Protection addresses directly, provided that the Location knows the public egress IP.
Managed mobile devices: Secure DNS, supplemented by defined internal exceptions and VPN tests.
Mixed environment: operate the site path and Secure DNS in parallel, but document which path is authoritative for each device class. Double interception makes troubleshooting harder.

Inventory and network access

Record the following before making changes:

the two DNS Protection IP addresses under My Products > DNS Protection > Installers in your own tenant;
all public IPv4 egress addresses actually used by normal operation, WAN failover, SD-WAN, VPN, or central proxies;
internal forward and reverse zones, their authoritative resolvers, and search suffixes;
DNS values supplied by DHCP and VPN or configured statically in each network;
devices or applications using their own DoH, DoT, VPN, or hard-coded resolver;
the previous resolver, the TTL of the DHCP options, responsible personnel, the maintenance window, and the rollback path.

On Installers, select Copy next to IP addresses and always use both addresses shown. The Certificate download belongs to the separate certificate process; for visible HTTPS Block Pages, devices must trust this DNS Protection Root Certificate. Do not confuse it with a CA used for HTTPS inspection by the firewall.

For Traditional DNS, both tenant addresses must be reachable over UDP 53 and TCP 53: from the approved local resolvers in forwarder mode, or only from the approved client or pilot subnets in direct-client mode. UDP is the normal path; TCP is required for larger or truncated answers, among other cases. DNS Protection is an IPv4-based resolver but can resolve AAAA records and therefore IPv6 destinations. Do not let a separate unprotected IPv6 resolver bypass the intended path.

For Secure DNS, devices require outbound TCP 443 to the DoH destinations supplied by Sophos. HTTPS Block Pages also require TCP 443 and access to blockpage.dnsprotection.sophos.com. TLS inspection must not silently break the connection; constrain the specific exception narrowly to the documented Sophos destination path.

Restrict the port 53 rule to the addresses shown in the tenant as destinations and separate its sources according to the design: the intended local resolvers in forwarder mode, or the approved client or pilot subnets in direct-client mode. No inbound WAN rule is required. An upstream DNS proxy, ISP DNS redirection, or transparent captive portal can alter replies and must be detected during the pilot.

Plan Location identity, egress, and resilience

Traditional DNS works only when the query’s visible public source IP matches a Location in Sophos Fusion. Private RFC 1918 addresses do not belong in this mapping. For dynamic egress, a stable DDNS FQDN can be used, but it must resolve publicly to the current address. With CGNAT or an IP shared with other customers, unique assignment is not guaranteed; a dedicated public IP is the clean solution.

For multi-WAN, inventory every possible egress address and add it to the appropriate Location. Then switch paths deliberately and test both. Policy routing must not send DNS through an unknown egress. If public IPs overlap between tenants, Sophos states that the assignment created first takes precedence.

Sophos supplies two resolver addresses. Configure both as an equivalent primary/secondary pair. A third public resolver is not resilience but a bypass: resolvers do not always use alternative servers only after a complete failure and may use the fastest one in parallel. True resilience also includes two local resolvers, redundant DHCP/VPN distribution, and a tested WAN failover path.

Vendor-neutral setup procedure

In Sophos Fusion, under My Products > DNS Protection > Network setup, choose the appropriate branch for Local resolver, Firewall forwarder, Windows DNS, Manual device DNS, or Secure DNS. Then confirm the intended Location and connection method. For Traditional DNS, all production public egress addresses must be known.
For Traditional DNS, copy both resolver addresses from your own tenant under My Products > DNS Protection > Installers. Do not use example values or addresses from another tenant.
For Secure DNS, create or edit the Location, enable Secure DNS, select Save, and copy the generated location-specific DNS over HTTPS URL. Give that exact URL or generated profile to the person responsible for Windows, macOS, or MDM. Give the person responsible for the Sophos Endpoint Policy the Location and pilot group so they can select that Location in the Endpoint Policy.
In forwarder mode, configure both Sophos addresses as the only forwarders for public queries on the local resolver or third-party firewall: one as Primary DNS server, the other as Secondary DNS server. Retain conditional forwarders or stub zones for internal forward and reverse zones. If the product offers a third DNS server, do not add an external public resolver there because switching to it bypasses protection.
Separate the egress firewall rule according to the design: in forwarder mode, allow UDP/TCP 53 only from authorized local resolvers to both Sophos addresses; in direct-client mode, allow it only from approved pilot or client subnets to both addresses. Block port 53 for all other sources according to the documented bypass design.
For Secure DNS, allow TCP 443 only from approved devices to the generated DoH destination and required Block Page destination. Constrain exceptions from TLS inspection narrowly.
In forwarder mode, point the pilot DHCP and VPN scopes to the local resolver. In direct-client mode, distribute both Sophos addresses to the approved pilot subnet. Inventory static devices separately.
Have the person responsible for Windows, macOS, or MDM deploy the generated Secure DNS URL or profile only to the pilot group. For Sophos Endpoint, the person responsible for the policy selects the supplied Location in the Endpoint Policy and assigns that policy to the supplied pilot group. Document the Location, policy, group, and removal method.
Refresh caches and existing leases only in the pilot and in a controlled manner. A global cache flush creates unnecessary load and makes comparison harder.
Restrict alternative DNS paths only after successful validation.

Boundaries of bypass prevention

Classic DNS can be constrained by allowing outbound UDP/TCP 53 only for authorized local resolvers in forwarder mode, or only for approved client or pilot subnets in direct-client mode. Redirecting unknown port 53 destinations to the local resolver can help with difficult-to-manage devices, but it must exclude internal DNS servers, VPNs, guest networks, and devices that require a specific resolver. Blocking is more transparent than redirection where clients are manageable.

This control catches no DoH on TCP 443, no DoT on TCP 853, and no name resolution inside a third-party VPN tunnel. Do not block TCP 443 indiscriminately. Browser, operating-system, MDM, and endpoint policies must control unapproved Secure DNS; known DoT use can be handled specifically. Apple Private Relay and similar privacy services are also a separate design decision.

If only iPhones cannot access the internet even though resolution works on other devices, temporarily turn off Limit IP Address Tracking for the affected network and test again. Make this change deliberately on pilot devices because it affects a device privacy feature.

Bypass prevention ends at the administrative boundary. In a BYOD or guest network, a documented, less restrictive policy is often more robust than trying to enforce every encrypted resolver without device management.

Pilot, validation, and acceptance

Start with a representative VLAN or a few devices. Test at least public names, internal FQDNs, reverse lookups, VPN, guest access, WAN failover, and a harmless test block.

Before the change, define an observation window and explicit rollback triggers. Roll back the pilot if internal or VPN resolution fails, the wrong Location or policy appears, DoH/TLS remains unstable, or a required business destination is disrupted; do not expand while any trigger remains unresolved.

nslookup example.com <resolver-ip>
nslookup internal-host.corp.example <resolver-ip>

With dig installed:

dig @<resolver-ip> example.com A
dig @<resolver-ip> example.com AAAA
dig @<resolver-ip> internal-host.corp.example
dig +tcp @<resolver-ip> example.com

Replace <resolver-ip> with the local resolver or, for direct use, a tenant address. corp.example is a documentation zone and must be replaced by your internal zone. The TCP test confirms that UDP is not the only protocol that works.

Next, open the test URL copied from Installers > Check your configuration in a browser. The Welcome message confirms the DNS Protection path, but not the correct policy by itself. Also block a harmless test domain deliberately and verify in Sophos Fusion that the query, Location, and policy appear as expected. Reporting is not necessarily real-time, so do not infer a failure immediately after a single query.

Acceptance means:

both Sophos resolvers work separately over UDP and TCP;
internal forward and reverse zones stay internal;
the expected egress maps to the correct Location;
blocking and approved business destinations work;
WAN failover, VPN, and IPv6-capable clients do not create an alternative path;
unauthorized port 53 DNS is blocked or redirected as designed;
manual Windows, macOS, and MDM Secure DNS pilots use the exact generated URL or profile, while Sophos Endpoint pilots are assigned a policy with the intended Location; both appear under the intended Location and policy and pass tests in the office, while roaming, over VPN, for internal domains, and on removal;
monitoring and a tested rollback path are documented.

Operations and regular checks

After the pilot, roll out in waves by site or VLAN. For each wave, monitor DNS errors, helpdesk reports, blocked business domains, and egress assignment. Move static servers and OT/IoT devices last and in a separate maintenance window.

After changes to WAN, NAT, DHCP, VPN, IPv6, or local resolvers, verify the DNS path again. The same applies after changing providers or adding a new public egress address. Check regularly that both tenant resolvers remain configured, internal zones are still resolved locally, and no additional DNS server bypasses protection. Add product notifications under My Environment > Alerts and status under My Products > DNS Protection to the operating process.

Safe rollback or decommissioning

For rollback, first disable new rules that block or redirect DNS. Then follow the branch that matches the deployment:

Forwarder mode: Actively restore the documented previous forwarders on the local resolver. Then verify internal and public resolution.
Direct-client mode: Restore the documented previous DNS values in DHCP, VPN, and static clients. Renew leases on test devices, then verify internal and public resolution.
Secure DNS: The person responsible for Windows, macOS, or MDM removes the pilot profile; the person responsible for the Sophos Endpoint Policy instead removes the pilot-group assignment. Then restore the previous DNS state and verify that the DoH path is no longer used.

Initially leave conditional forwarders and the Sophos Fusion Location in place unless the Location itself caused the incident.

Troubleshooting by symptom

Public names do not resolve at all

First test both Sophos addresses explicitly over UDP and TCP. Then check the egress rule, NAT, route, and visible public source IP. If the source IP is not assigned to a Location or conflicts with another tenant, DNS Protection can reject queries. With DDNS, also verify public resolution of the FQDN.

Internal names or Active Directory fail

Check which resolver the client actually uses. Then inspect conditional forwarders, authoritative target servers, reverse zones, search suffixes, and VPN split DNS. A directly assigned DNS Protection resolver does not know private zones.

Only large replies or individual domains fail

Test TCP 53. If UDP works but dig +tcp does not, the TCP rule is usually missing or an intermediary is dropping the connection. If an allowed domain is still blocked, also inspect its CNAME target and security classification.

Sophos Fusion shows no Location or the wrong one

Determine the actual egress rather than relying only on the configured WAN address. SD-WAN, central NAT gateways, proxies, and failover can change the source IP. Then allow sufficient time for reports and confirm that the test used the intended resolver rather than browser DoH or a VPN.

For a Location defined by FQDN, also check its public resolution. A Cloudflare DNS record must have Proxy status: DNS only; a proxied record does not return the actual public egress address. A private or IPv6 address is not a valid Location address. If the same public value is already assigned to another customer or the FQDN is invalid, correct the assignment before continuing the rollout.

The Block Page is absent although DNS blocking works

This does not prove that the domain was allowed. Check access to blockpage.dnsprotection.sophos.com, trust in the DNS Protection Root Certificate, Pharming Protection, the web proxy or web filter, and TLS inspection. If the firewall decrypts the Block Page path, use the narrowly scoped Do not decrypt action for the documented Sophos destination path. Always manage certificate installation and removal through the responsible platform process.

An allowed domain remains blocked

First check the CNAME target and its category: an allowed original domain can still point to a name blocked because of its category or Threat Score. After changing a policy, also wait for the DNS TTL and local caches or refresh them in a controlled manner. Do not accelerate the rollout by adding broad blanket exceptions.

The bypass control does not work

Search logs for outbound UDP/TCP 53, TCP 853, and known Secure DNS connections. Then inspect the browser, operating system, VPN, and local security software. A port 53 filter cannot detect or prevent encrypted DNS on 443.

DNS resolves, but policy and reports are missing

First use ipconfig, nslookup, or dig on Linux and macOS to check which resolvers the device actually uses. Then run a standard or extended test at https://www.dnsleaktest.com/. When DNS Protection is in use, all values in the Hostname column contain the pattern gw-<number>.<region>.dnsprotection.sophos.com; Amazon or a corresponding designation appears as the ISP. Other resolvers indicate a DNS leak or redirection by the ISP.

If https://dns.access.sophos.com shows a browser error instead of the Welcome page while the dashboard shows No queries received from locations, or if a Sophos Firewall reports DNS Protection: Connectivity Error, correct the divergent resolver path first. Check router DNS, DHCP and DHCPv6, static DNS entries, ISP redirection, and parallel IPv6 resolvers. Only then investigate policy or reporting; this diagnostic path applies to the network path and must not be applied to Endpoint DoH without verification.

Set up Sophos DNS Protection with Sophos Firewall shows the specific integration on SFOS.
Endpoint DNS Protection Policy describes the separate managed Workspace path for endpoints.