Manage Sophos DNS Protection Locations safely

A Location tells Sophos DNS Protection which site, network, or set of devices a DNS query belongs to. This mapping enables location-specific Filtering policies and meaningful reports. For reliable operation, a Location should represent the internet egress rather than every internal VLAN.

The complete workflow starts under My Products > DNS Protection > Locations: choose the connection method, create the Location, verify the assignment on the Policies page, test the actual DNS path, and only then remove old IP addresses or Locations. The Default location is an immutable Secure DNS starting point; custom Locations represent sites, regions, or separate policy groups.

Decide between Default and a custom Location

The predefined Default location uses Secure DNS and works without a recorded public site address. You can assign it to both an Endpoint policy and a Filtering policy. You can view its details under My Products > DNS Protection > Locations > Default, but you cannot edit or delete it.

Create a custom Location if at least one of the following applies:

• A firewall, router, or local DNS resolver sends traditional DNS queries.
• Sites or device groups need different Filtering policies.
• Reports must separate DNS queries by region or internet egress.
• Endpoint devices need a dedicated Secure DNS assignment rather than Default.

DNS Protection supports up to 50 Locations. A custom Location can use Secure DNS, Traditional DNS over IPv4, or both methods. Each Location can contain up to 100 public IPv4 addresses or FQDNs.

Choose the appropriate connection method

Secure DNS

Secure DNS carries DNS over HTTPS. This method is suitable for compatible devices and is mandatory for Sophos Endpoint with DNS Protection. Central generates an individual DNS over HTTPS URL when you save. Sophos Endpoint configures managed devices automatically; a manually configured device needs the URL.

For this deployment, you must use and copy exactly the two DNS Protection IPv4 addresses shown by Central.

Traditional DNS over IPv4

Traditional DNS over IPv4 sends unencrypted DNS to the DNS Protection resolvers. This method is suitable for firewalls, routers, and local DNS servers. DNS Protection identifies the Location by its public source IP. Therefore, enter the public WAN address, a public range, or an FQDN that resolves to that address—never an internal RFC 1918 address.

The complete firewall configuration, including forwarders, internal zones, and DHCP, belongs in the separate guide to Sophos DNS Protection with Sophos Firewall. The Location alone does not change any DNS path in the network.

Both methods

Both switches can be active in the same custom Location. This is useful when the same policy context includes both managed endpoints over DoH and a site resolver over traditional DNS. First, decide explicitly whether these two paths should genuinely receive the same filtering and reporting.

Prerequisites and address plan

Before creating the Location, record:

• a unique name, a concise description, and the person technically responsible,
• the required connection method,
• every public egress address used by multi-WAN, SD-WAN, and failover,
• a maintained DDNS FQDN for a dynamic public address,
• the intended Filtering policy and, where applicable, the Endpoint policy,
• a directly connected test device for each DNS path.

Default is a reserved name. ZH-HQ-Egress is a suitable example; the description can include the provider, WAN links, and the person responsible. Keep the site name stable even when the provider changes.

Changes to DNS Protection require an appropriate administrative role in Sophos Fusion. Read-only access is suitable for verification, but not for creating, editing, or deleting. Manually entering a public IP address or FQDN does not prove entitlement to use the service.

Standalone or network-based DNS requires at least one valid firewall linked to Central with Xstream Protection. Managed Endpoint DNS, however, is a Workspace feature; Xstream alone is not sufficient for it. Add known IPs detects only public addresses of licensed Sophos Firewalls with Xstream Protection. Secure DNS requires a device capable of handling DNS over HTTPS; Sophos Endpoint specifically requires this connection method for DNS Protection.

Create a custom Location

1. Open My Products > DNS Protection > Locations > Add location. In the Locations list, the Add button opens this dialog.
2. Enter a unique name under Location name and the purpose under Description.
3. Under Connection method, enable Secure DNS, Traditional DNS over IPv4, or both.
4. For Secure DNS, record the displayed IPv4 addresses. The DNS over HTTPS URL is generated only when you select Save.
5. For Traditional DNS over IPv4, add the public values under IPv4 addresses or FQDNs. Confirm each individual entry with Enter or Tab. When pasting several values, place a line break between them.
6. Select Save.
7. For Secure DNS, copy and store the generated DNS over HTTPS URL securely before selecting Close.

Use detected addresses

Add known IPs shows suggestions in Central:

• Your Current Location is the address from which the current Central session originates. During a VPN session, this is the VPN server’s public address and might not be the intended site address.
• Your Firewalls shows the address through which a licensed Sophos Firewall reaches Central. Only firewalls with Xstream Protection are detected automatically.

A detected value is only a suggestion. DNS Protection does not automatically update it after a later address change. For multi-WAN, manually add any egress addresses that were not detected.

IP, FQDN, multi-WAN, and DDNS

For a static connection, the public IPv4 address is usually the clearest choice. For multi-WAN, enter all addresses through which DNS queries can actually leave; alternatively, use an appropriate public range. If the failover address is missing, DNS Protection will not work for this Location after the link changes.

For a dynamic address, enter an FQDN from a third-party DDNS service. The DDNS client must update the record reliably. If you use Sophos Firewall for this, Configure and verify Dynamic DNS on Sophos Firewall explains the configuration under Network > Dynamic DNS > Add. DNS Protection checks for address changes every minute and then needs eight seconds to update its cache. Name resolution can be interrupted briefly while the provider, DDNS record, and cache are being updated.

Supported services are DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS, and Cloudflare. With Cloudflare, set Proxy status to DNS only; a proxied record returns Cloudflare addresses instead of the public egress IP.

CGNAT and address conflicts

Traditional DNS requires a unique public source IP. With CGNAT and shared provider, proxy, or VPN egress addresses, the same IP can occur in several customer accounts. DNS Protection gives precedence to the user who created the Location first. A different FQDN does not help if it resolves to the same shared IP.

The reliable solution is a unique public address from the provider or Secure DNS for compatible devices. Private addresses such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 do not identify the internet egress and must not be added to the Location.

Complete the policy assignment

A Location allows incoming DNS queries to be assigned, but does not by itself define the required filtering.

• Under My Products > DNS Protection > Policies > Filtering policies, move the Location from Available to Assigned to this policy. A Location can be assigned to only one Filtering policy.
• In an Endpoint policy, assign a Location to the selected Windows devices. It must use Secure DNS; Default location is also valid.

The endpoint path, internal Domain exclusions, and the agent component belong in the separate endpoint guide. An Endpoint assignment does not replace a Filtering policy: the first determines which devices use the Location, while the second determines how their domains and categories are handled.

Edit a Location

Before making any change, document the name, methods, IP/FQDN list, DoH use, and both policy assignments. Then open the custom Location under My Products > DNS Protection > Locations, adjust the values, and select Save.

Use this safe sequence for an egress migration:

1. Add the new public address alongside the old address.
2. Wait until the new internet path is active.
3. Verify DNS resolution and policy matches through the new path.
4. Only then remove the old address.

When moving from Traditional DNS to Secure DNS, configure and validate the DoH path with a pilot group first. Keep Traditional DNS active until the test succeeds. This avoids an untested cutover and enables a quick return to the previous path.

Validate after creation or a change

1. Under My Products > DNS Protection > Locations, verify that Location, Description, and the displayed number under IP addresses/FQDNs are correct.
2. Open the Location and check in its details that the intended Connection method and expected IP/FQDN values are recorded.
3. Under Policies, confirm that the Location is assigned to the intended Filtering policy and, if applicable, Endpoint policy.
4. From the exact DNS path affected, resolve a demonstrably allowed domain and a test domain deliberately blocked by the assigned policy. Account for caches and DNS TTL.
5. Check the dashboard or reports to confirm that the query appears under the expected Location.

Successful name resolution alone proves neither the correct policy nor the correct Location. Only the combination of a positive test, a blocked test, and a matching report entry confirms the complete path. If the query is missing, first compare the actual public source IP with IP addresses/FQDNs; for an invalid FQDN or IP conflict, check My Environment > Alerts next.

Troubleshoot by symptom

The Location does not accept the address

Static entries and hostnames support IPv4 only. A private or IPv6 address is not a valid site egress. Enter the public WAN address or an FQDN that resolves to it, and finish every value with Enter or Tab.

Resolution stops or the Location is absent from reports

Compare the actual egress with the stored IP/FQDN list. Multi-WAN might be using an unrecorded failover address. For an FQDN, first confirm that it resolves to a valid public IPv4 address. Central reports invalid FQDNs and IP conflicts under My Environment > Alerts.

IP conflict or CGNAT

If the same public IP already belongs to another customer, the Location created first retains precedence. An alias for the same IP changes nothing. Ask the provider for a unique public IPv4 address or use Secure DNS for suitable devices.

DDNS outage after an address change

Confirm that the DDNS record already returns the new public address. Then wait for at least one DNS Protection update cycle and for the cache to update. With Cloudflare, verify DNS only. Do not remove the old IP until the new value matches the actual egress.

The policy does not take effect

Check which Location the query was actually assigned to and which Filtering policy that Location belongs to. Only one Filtering policy can apply per Location. After a policy change, an already cached DNS record can continue to work until its TTL expires; therefore, retest with a fresh test name or after cache expiry.

Other resolvers bypass DNS Protection

If clients receive additional traditional or IPv6 DNS servers, queries can bypass DNS Protection. Distribute only the planned DNS Protection path for public resolution. DNS Protection is IPv4-based but can also resolve AAAA records; a separate IPv6 resolver is not required for this.

Operations and lifecycle

Review the Locations after a provider, WAN, DDNS, or policy change, as well as regularly during operations. In the list, compare Location, Description, and the number under IP addresses/FQDNs with the documented target state. Check the Connection method in the Location details and the assignment on the Policies page. Automatically suggested addresses are not permanently synchronized: if a previously detected IP address changes, you must update the Location or the maintained DDNS name and validate it again.

For operational steps, the current help pages are authoritative. Release notes provide a timeline for changes such as automatically suggested IP addresses, the copy function for IP addresses and FQDNs, or the display of assigned Locations in policies; they do not replace current configuration instructions. As of September 24, 2026, the current help pages and release notes do not provide a specific date for the retirement of DNS Protection.

Delete a custom Location safely

You cannot delete the Default location. For a custom Location, use the following sequence:

1. Back up its name, description, enabled connection methods, IP/FQDN values, policy assignments, and existing DoH URL. Also document every firewall, resolver, and manually configured device that uses the Location.
2. If the DNS path is still required, create and configure a replacement Location. This may happen in parallel with the old Location only if the replacement Location uses its own uniquely routable identity or a newly provisioned Secure DNS path.
3. If you use a replacement Location, assign it to the intended Filtering and Endpoint policies. Then move a controllable pilot path to the replacement Location first, such as pilot devices, a resolver, or—where operationally feasible—a firewall.
4. For a replacement Location, resolve an allowed domain and a domain blocked by the assigned policy through the pilot path. Check the reports to confirm that both queries are assigned to the replacement Location. Only after successful verification should you move the remaining firewalls, resolvers, and manually configured devices. If the DNS path is being removed without replacement, end its use on all documented systems instead. Then remove the old Location from its previous policies and confirm that it is no longer in use.
5. Only now, under My Products > DNS Protection > Locations, select the old Location and select Delete.
6. For a replacement Location, retest allowed and blocked resolution over the new path and verify the assignment in reports. For removal without replacement, verify that the remaining DNS paths work as intended.

If a replacement Traditional DNS Location is intended to use the same public identity and therefore cannot exist uniquely alongside the old Location, stop before selecting Delete. Document the planned cutover and conflict risk; deletion may be performed only for the deliberately approved cutover. In this case, the replacement Location is explicitly not considered validated in parallel.

Recreation using the backed-up name, description, methods, IP/FQDN values, and policy assignments is only a best-effort recovery attempt, not a guaranteed return to the previous state. In particular, for a contested public Traditional DNS identity, it does not reliably restore the precedence of the Location created first. For Secure DNS, recreation generates a new DNS over HTTPS URL; you must redeploy it to every manually configured device. Reconnect firewalls and resolvers to the traditional path where applicable. Then retest allowed and blocked resolution and the reports.