Set up Sophos DNS Protection manually on Windows
A Windows device can use Sophos DNS Protection manually in two ways: Traditional DNS sends unencrypted DNS requests to the DNS Protection IP addresses, while Secure DNS encrypts them using DNS over HTTPS (DoH). Manual configuration is suitable for individual clients that aren’t centrally managed. For managed Windows endpoints with Workspace Protection, Sophos recommends using the Endpoint DNS Protection Policy instead. The software package requirement applies only to this managed alternative: before rollout, select and verify Windows > Recommended in Update Management, then follow the linked endpoint guide.
The safest approach is to record the existing adapter settings, copy the values for your own tenant from Sophos Fusion (formerly Sophos Central), change only one active adapter on a pilot device, test public and internal names, and only then configure additional adapters. Never use IP addresses or a DoH template from another tenant.
Choose Traditional DNS or Secure DNS
Traditional DNS is suitable if the device currently connects directly to a public cloud resolver such as Google Public DNS or Cloudflare DNS and DoH isn’t required. Queries use UDP or TCP port 53 and aren’t encrypted in transit. The location must be able to identify the device’s public egress IP using Traditional DNS over IPv4.
Secure DNS is usually the better manual option for mobile devices or untrusted networks. Windows sends requests over HTTPS using the tenant- and location-specific DNS over HTTPS URL. The location must be configured with Secure DNS. Secure DNS isn’t the same as an arbitrary browser DoH service: browsers and applications with their own resolvers can still use a different DNS path.
Manual adapter settings apply only to the adapter you configure. Wi-Fi, Ethernet, VPN, and virtual adapters can have different DNS values. For domain-joined devices, internal zones, or split DNS, first determine how internal names will remain accessible. Switching directly to Sophos manually can bypass the internal DNS server. In such environments, a central resolver path through Sophos DNS Protection with Sophos Firewall or the managed endpoint policy is usually more appropriate.
Prepare the values and a rollback plan
- On the pilot device, document the DNS servers currently in use and whether each affected adapter is set to Automatic (DHCP) or Manual.
- In Sophos Fusion, open My Products > DNS Protection > Installers and click Copy next to IP addresses. This copies the two DNS Protection IP addresses for your tenant.
- For Secure DNS, use a location configured with Secure DNS under My Products > DNS Protection > Locations, and copy the DNS over HTTPS URL generated when the location was created.
- Check which filtering policy is assigned to the location and choose a harmless test domain that you can deliberately block.
- Schedule a maintenance window and define how to restore the recorded DHCP or static values.
The values are shown as <DNS-IP-1>, <DNS-IP-2>, and <DOH-TEMPLATE>. Always replace these placeholders with values from your own Sophos Fusion tenant. Don’t derive the DoH template from an example configuration.
Before making changes, you can display the known DoH state in an elevated PowerShell session:
Get-DnsClientDohServerAddress
The command doesn’t change anything. However, it doesn’t show the complete adapter configuration, so document that separately in Windows.
Configure Traditional DNS manually
Sophos documents the following procedure using the classic adapter dialog:
- Open Run, enter the following command, and select OK:
control.exe /name Microsoft.NetworkAndSharingCenter
- In Network and Sharing Center, select Change adapter settings on the left.
- Right-click the active adapter, such as Wi-Fi, and select Properties.
- On the Networking tab, select Internet Protocol Version 4 (TCP/IPv4), then select Properties.
- On the General tab, select Use the following DNS server addresses.
- Enter
<DNS-IP-1>under Preferred DNS server and<DNS-IP-2>under Alternate DNS server. Both copied Sophos addresses are part of the manual Traditional DNS setup; entering only one leaves the intended second resolver address unused. - Select OK.
- Test only this adapter first. Configure other active adapters in the same way only after the first one passes validation.
Don’t add an unrelated public resolver IP address as a third fallback. Windows doesn’t guarantee that an alternate DNS server is used only in an emergency; an unrelated resolver can bypass filtering and reporting.
Configure Secure DNS manually using DoH
The current Sophos procedure uses Windows Settings and a manual template:
- Open Settings > Network & internet > Wi-Fi and select the properties of the connected Wi-Fi network. For Ethernet, open the corresponding active adapter under Network & internet.
- Under DNS server assignment, select Edit.
- Select Manual and turn on IPv4.
- Enter
<DNS-IP-1>under Preferred DNS. - Under DNS over HTTPS, select On (manual template).
- Under DNS over HTTPS template, paste the complete tenant-specific
<DOH-TEMPLATE>. - Select Save.
Sophos shows one preferred DNS value in this manual Secure DNS procedure. Don’t arbitrarily combine the same template with additional IP addresses unless that mapping is provided or verified in the tenant. If you use a second resolver, its IP-to-template mapping must also be explicitly correct.
If Windows doesn’t accept the template through the user interface, an elevated PowerShell session can register the mapping documented by Microsoft:
Add-DnsClientDohServerAddress -ServerAddress '<DNS-IP-1>' -DohTemplate '<DOH-TEMPLATE>' -AllowFallbackToUdp $False -AutoUpgrade $True
-AllowFallbackToUdp $False prevents a silent fallback to unencrypted DNS. Name resolution therefore fails if DoH is unavailable. Run this command only after a documented pre-check and first on a pilot device. You must still configure the IP address as a DNS server on the adapter. Use Get-DnsClientDohServerAddress to verify that the IP address and template match exactly.
Don’t mix it with the managed endpoint policy
Manual configuration and Endpoint DNS Protection are two different operating models. In the managed model, Sophos Endpoint intercepts DNS requests and sends them over HTTPS to the selected Secure DNS location. Excluded domains and, optionally, an NXDOMAIN retry instead go to the DNS service configured by the system or application.
Don’t distribute manual Sophos DNS values as a supposed fallback while also enabling Use Sophos DNS Protection. This complicates troubleshooting and can send internal exclusions back to Sophos. Before switching to the endpoint policy, reset the manual adapter values in a controlled manner to the intended corporate resolver or DHCP. Then pilot the agent component, policy assignment, domain exclusions, and certificate deployment as described in the endpoint guide.
Validate the configuration and monitor it in operation
First, check the Windows view:
ipconfig /all
Resolve-DnsName example.com
Get-DnsClientDohServerAddress
ipconfig /all must show the expected DNS IP addresses on the adapter that is actually in use. Resolve-DnsName example.com only confirms that name resolution works; this command alone proves neither that the filtering policy was applied nor that traffic is encrypted.
Then complete the following acceptance checks:
- a known allowed public domain resolves;
- a harmless domain deliberately blocked in the pilot policy is blocked;
- internal FQDNs, short names, VPN names, and business-critical applications work as planned;
- under DNS Protection > Logs & Reports, the request appears for the expected location after the usual reporting delay;
- for Secure DNS, the Windows configuration shows On (manual template) and no UDP fallback is allowed;
- browsers or applications with their own Secure DNS were tested separately.
A Sophos block page requires the DNS Protection Root Certificate in the trusted certificate store. If it is missing, a certificate warning may appear even though the domain was blocked correctly. Therefore, also verify the block status and reports.
Roll back or remove the configuration safely
Have the documented original values ready before restoring the configuration. Then proceed one adapter at a time:
- Open DNS server assignment > Edit or the IPv4 properties.
- If the adapter previously used DHCP, select Automatic (DHCP) or Obtain DNS server address automatically again.
- If static resolvers were configured, restore those exact values.
- Save the changes, reconnect the adapter or renew the DHCP lease, and test public and internal names.
- Only then repeat the procedure for additional adapters.
This stops active use of the service. Don’t blindly delete a DoH mapping while another adapter or a managed policy might still use it. First run Get-DnsClientDohServerAddress and check the device-management records. If both confirm that the mapping was created by the manual PowerShell command in this guide and nothing else owns it, remove the exact server address in an elevated PowerShell session:
Remove-DnsClientDohServerAddress -ServerAddress '<DNS-IP-1>'
Get-DnsClientDohServerAddress
The second command must no longer show the manually created mapping. If the entry is shared or policy-managed, don’t run the removal command; remove it through the management method that owns it instead. Delete the Sophos Fusion location only when no other devices, networks, or policies depend on it.
Troubleshooting
Public names don’t resolve
Check the IP address, gateway, and DNS values on the active adapter. With Traditional DNS, Preferred DNS server and Alternate DNS server must contain the two copied Sophos addresses. If one address is missing, first complete the configuration on the adapter that is actually active. UDP/TCP port 53 must be able to reach these addresses, and the public egress IP must match the location. With Secure DNS, HTTPS must be accessible, and the IP address and DNS over HTTPS template must come from exactly the same tenant configuration. Then check for any VPN, proxy, or firewall requirements.
Manual DNS values disappear
First, check that you edited the active Wi-Fi, Ethernet, or VPN adapter. If the values revert to DHCP or other resolvers after you save them, don’t repeatedly force the change. First determine whether DHCP, device management, or a corporate policy controls the adapter configuration. Either configure the intended DNS path there or roll back to the documented original values.
Internal names stop resolving
A direct manual configuration often bypasses the internal resolver. Roll back the adapter to its previous values. For internal zones that must remain available, use a central DNS forwarder with conditional forwarding or the endpoint policy with maintained Domain exclusions. A publicly unresolvable internal name isn’t a reason to allow it in DNS Protection.
Windows doesn’t show DoH or falls back to plaintext
Check whether Manual, IPv4, Preferred DNS, DNS over HTTPS, and DNS over HTTPS template are available under DNS server assignment > Edit, and whether On (manual template) was saved. If these controls are missing, first check the Windows build and update status required for the documented interface; don’t derive a template from an example or another tenant. If the fields are available, use Get-DnsClientDohServerAddress to verify the correct IP-to-template mapping. A mode that allows unencrypted fallback can switch to plaintext without a visible warning. For a strictly encrypted configuration, this fallback must not be allowed; a DoH outage then intentionally causes name resolution to fail.
Reports remain empty or show the wrong location
First, make sure the adapter you tested is actually active and that no browser, VPN client, or endpoint agent is using its own DNS path. Then check the location, public source IP or Secure DNS template, and filtering policy assignment. Reports in Sophos Fusion aren’t real-time; don’t assume there is a problem immediately after a single query.
The block page shows a certificate error
Check whether the DNS Protection Root Certificate is trusted on the device. For centrally managed endpoints, the policy can distribute it automatically. Manually configured devices require a deliberately managed certificate process. The Root Certificate isn’t the same as a Sophos Firewall CA for TLS Inspection.