Configure Sophos DNS Protection for endpoints

The Endpoint DNS Protection policy connects Sophos DNS Protection directly to Sophos Endpoint. The agent intercepts DNS requests and redirects them securely over HTTPS to the Sophos service. This also works outside the corporate network without manually changing local DNS servers.

It is not the same as Web Control. DNS Protection decides at domain level, while Web Control adds its own categories and Endpoint web inspection.

Requirements

The current Endpoint integration requires:

• a suitable Workspace Protection licence
• Sophos Endpoint Agent on target devices
• a supported Windows endpoint operating system
• no Windows Server or macOS targets
• a compatible Endpoint software package
• HTTPS connectivity to Sophos DNS Protection

Sophos currently explicitly requires the package FTS 2025.2.3.31.2 Required for DNS Protection Update. Select this package in the Endpoint Update Management Base Policy for Windows. Sophos describes this requirement as temporary, so verify before every new rollout whether it still applies.

How the integration works

1. The Endpoint agent intercepts DNS requests.
2. Requests not excluded are sent securely to DNS Protection.
3. Responses return directly to the application.
4. Excluded internal domains use the system or application DNS service.
5. Optionally, a public NXDOMAIN response can be retried through local DNS.

Sophos recommends explicit domain exclusions for internal zones. This is faster and more predictable than a general retry after NXDOMAIN.

Install the agent component

Select suitable Windows endpoints under My Environment > Computers & Servers. Depending on the licence, Manage Software shows DNS or DNS & ZTNA.

After Install and Save, verify:

• agent mode remains as planned
• the DNS component reaches Installed
• the device has current Endpoint software
• no installation or restart alerts remain

A software assignment can begin outside the normal update window.

Choose a Secure DNS location

DNS Protection uses Locations to assign filtering rules. Endpoint devices use a Location with Secure DNS. The immutable Default location or a new Location can be selected.

Separate Locations are useful when mobile devices, countries or organisational units need different filtering. A Location does not replace a clean policy target.

Assign a Filtering Policy to the Location

The Endpoint policy determines which devices use DNS Protection and under which Secure DNS Location they appear. The actual category and domain filtering is defined in a separate Filtering policy for that Location.

Only one Filtering Policy can apply to each Location. Sophos permits up to 50 such policies per tenant. A built-in filter profile cannot be edited directly; use Let me specify for custom category decisions.

Domain Lists override the normal category decision: an Allow list can permit a domain in a blocked category, while a Block list can block one despite its permitted category. Sophos nevertheless continues to block domains with a poor Threat Score or dangerous reputation. An Allow list is therefore not a general malware bypass.

Internal corporate domains can additionally be placed on an allowed Domain List so that, for example, ZTNA or internal services are not blocked because of a category such as Parked Domains. This does not replace the Endpoint domain exclusion for names that only an internal DNS server can resolve.

Create the Endpoint policy

The current entry point is My Products > DNS Protection > Policies > Endpoint policies.

1. Select Add policy.
2. Add computers or computer groups.
3. Enable the policy.
4. Turn on Use Sophos DNS Protection under Settings.
5. Select the appropriate Secure DNS Location.
6. Add internal domain exclusions.
7. Configure block pages and certificate deployment.
8. Save and test with a pilot group.

As with other Central policies, order determines which Endpoint DNS policy a device receives.

Internal DNS zones

Internal names such as corp.example, Active Directory zones or split-DNS domains must not be resolved only through public DNS.

An explicit domain exclusion is the safest approach. All subdomains are included and use normal system DNS.

Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN is a fallback, but a maintained list of internal zones is more efficient.

Block pages and certificate

For HTTPS domains, browsers need to trust the DNS Protection certificate to show a useful block page instead of a certificate warning.

Automatically deploy the DNS Protection signing certificate to devices distributes the root certificate. Test existing certificate policies, browsers and restrictive trust stores first.

In addition, blockpage.dnsprotection.sophos.com must be reachable without web filtering or TLS decryption that changes the block-page destination. If a Sophos Firewall uses web proxy mode with Pharming Protection, either configure it to use DNS Protection as its resolver or add a dedicated allow rule for this FQDN and a Do not decrypt TLS rule.

A domain can still be blocked without a visible block page. Use DNS Protection logs to check the policy and action.

Pilot and validation

The pilot group tests at least:

• allowed and blocked public domains
• internal short names and FQDNs
• VPN, home and office connectivity
• browsers with and without their own Secure DNS settings
• the block page and certificate trust
• applications with built-in DNS over HTTPS
• behaviour during failure or proxy blocking

Also verify the source Location, policy and action in DNS Protection logs.

Evaluate logs and Reports

DNS Protection Reports lag current traffic by about 15 to 25 minutes. Changes to Location or policy names can take 30 minutes to four hours to appear in Reports. Allow for this delay during testing.

For Endpoint traffic, the columns include user and Device ID in addition to Location. This helps verify whether a request really came from the expected agent rather than merely from the same public IP address. Important views include DNS usage, DNS usage by source and High risk devices.

Saved Templates preserve filters and presentation, but not data or the time range. Scheduled exports have different row and column limits depending on format, and exported files are deleted after 90 days. Define separate retention for incident data.

Common problems

Internal names do not resolve

Add the internal zone as a domain exclusion, then check local DNS, search suffix and effective Endpoint DNS policy.

The device is unavailable for the policy

Check platform, licence, agent component and agent mode. The Endpoint integration currently supports only Windows endpoints, not servers or macOS.

The block page shows a certificate error

Check deployment and trust of the DNS Protection signing certificate. Browsers with separate trust stores may require additional management.

A browser bypasses the policy

Browsers and applications can use their own DNS over HTTPS. Inspect the actual resolver and Endpoint events before concluding that the policy is ineffective.

An allowed domain remains blocked

First check the Threat reputation and any CNAME. If the destination name is allowed but its CNAME belongs to a blocked category, the connection can still fail. Submit an obviously incorrect category for recategorisation instead of working around it with increasingly broad Allow lists.

A new block does not take effect immediately

Cached DNS responses remain usable until their TTL expires. Document the policy, Report and test time together; repeatedly saving the same rule does not accelerate TTL expiry.

Frequently asked questions