Skip to content
Avanet

Manage domain lists in Sophos DNS Protection

Sophos DNS Protection

Domain lists let you allow or block specific domains without changing the decision for an entire web category. The complete workflow has two parts: first maintain the list under My Products > DNS Protection > Domains, then include it in a filtering policy and set it to Allow or Block. A saved list that is not assigned to a policy has no effect.

Quick workflow

  1. Under My Products > DNS Protection > Domains, create a list with Add domain list.
  2. Enter only the required domain name for each item and finish every item with Enter or Tab.
  3. Save the list.
  4. Under My Products > DNS Protection > Policies > Filtering policies, open the appropriate policy.
  5. Under Filtering by domain lists, turn on Include domain lists when filtering, add the list with Add list, and choose Allow or Block under Actions.
  6. Save and test name resolution from a client that is actually covered by this policy.

Sophos permits a maximum of 100 domain lists and 1,000 domains per list. You can only delete a list after removing it from every policy.

Requirements and responsibilities

To make this change, you need access to My Products > DNS Protection and a filtering policy in which the list can be used. Before creating the list, determine whether the entry should be set to Allow or Block, which locations or endpoints the policy applies to, and who will review the exception later. Manage filtering policies in Sophos DNS Protection explains how to configure and assign the policy.

The domain list controls only the filtering decision. It does not replace configuration of the DNS path or assignment of a location or Endpoint policy. This keeps the operational boundary clear: in a network or firewall deployment, test traffic must pass through the configured DNS Protection location; with Endpoint DNS, it must pass through the protected endpoint and its policy.

Choose Allow or Block deliberately

An allow list is a targeted exception to the category decision. It is suitable, for example, when a required company domain is placed in a blocked category such as Parked Domains. A block list denies individual domains even though their category is generally allowed. Domain-list decisions take precedence over the web category: a list entry set to Allow is allowed regardless of its category, while an entry set to Block is blocked regardless of its category.

There is an important security boundary: DNS Protection continues to block websites with a poor threat score or dangerous reputation even when the domain is set to Allow in a list. An allow list is therefore not a malware bypass. If this blocks a business-critical domain, do not add ever broader exceptions. Check the domain, its owner, its current DNS destinations, and the reason for the classification.

Avanet recommends keeping exceptions small, purpose-specific, and traceable:

  • Maintain allow and block entries in separate lists so that their effect is clear during policy reviews.
  • Use purpose-based names such as Allow-ZTNA-Production or Block-Unwanted-Services.
  • Record the owner, ticket or business reason, and a review date in Description.
  • Before granting broad access, add only the domain that is genuinely required.
  • Review temporary entries on the agreed date and remove them when the reason no longer applies.

An allow list alone is not enough for zones that only resolve internally. The query must also use the correct internal DNS path. Depending on the design, this is configured through DNS Request Routes on the firewall or domain exclusions in an Endpoint policy.

Create a list and use the correct syntax

  1. Open My Products > DNS Protection > Domains.
  2. Select Add domain list.
  3. Enter a unique name under Name and the purpose under Description.
  4. Under Domains, enter items individually or paste a prepared list.
  5. Confirm every item with Enter or Tab. Pasted items must be separated by line breaks. This also applies when adding only one item.
  6. Optionally use Copy to clipboard to copy the recorded domains into the change record.
  7. Select Save.

The entered name determines the scope:

example.com

example.com matches the domain itself and its subdomains, including www.example.com, images.example.com, and more.images.example.com.

www.example.com

www.example.com matches that name, but not example.com or other names such as images.example.com. Only enter the parent domain when all subordinate domains should receive the same decision. Use the specific hostname for a narrowly scoped exception.

The documented input consists of domain names such as example.com. URLs, paths, and protocol prefixes do not belong in the list. Before a large import, remove blank lines and accidentally copied extra characters, and keep the list to no more than 1,000 entries.

Use the list in a filtering policy

  1. Open My Products > DNS Protection > Policies > Filtering policies.
  2. Select the policy that applies to the intended locations or firewalls.
  3. Open Settings.
  4. Under Filtering by domain lists, turn on Include domain lists when filtering.
  5. Select Add list. If the list does not yet exist, you can create one with Add new.
  6. Under Domain lists, select the required list and choose Save.
  7. Under Actions, set the added list to Allow or Block.
  8. Scroll up and save the policy with Save.

Only one filtering policy can be assigned to each location. Before testing, verify not only the list but also the location or firewall assignment to the edited policy. Multiple lists in one policy should not contain contradictory entries; a clear owner and separate allow/block lists make such conflicts easier to detect.

Edit an existing list

Under My Products > DNS Protection > Domains, open the required list, change Name, Description, or Domains, and save with Save. The overview shows the number of domains, description, and last-modified date for each list. Use these details to confirm the correct list and expected revision after saving.

Because an edited list affects every policy in which it is used, make three checks before saving:

  1. Identify the policy using the list and the scope of that policy.
  2. Compare removed and new domains with the approved change.
  3. Plan at least one allowed and one blocked control case.

For a large change, a new, clearly named list is often safer than replacing many entries in a production list. Assign and test the new list first, then remove the old assignment.

Validate the effect

Test from a client whose DNS queries pass through DNS Protection and which is assigned to the correct location or Endpoint policy.

  1. Record the currently expected resolution before the change.
  2. After saving, clear the local DNS cache or use a new test domain.
  3. Query a name from the list and an unrelated control domain.
  4. For Block, the list entry must be blocked while the control domain follows the normal category decision.
  5. For Allow, the required domain must be reachable despite its blocked category, unless Sophos blocks it as a security risk because of its threat score or reputation.
  6. Allow 15 to 25 minutes for dashboard and report data to appear.
  7. Open My Products > DNS Protection > Logs & Reports, select DNS usage by source, and filter by Location, Domain, Status, or Source IP. Confirm that the source, requested domain, location, and status match the test.

When testing subdomains, test both the entered name and an expected subordinate name. If you entered only www.example.com, do not expect an effect on example.com or sibling hosts.

Troubleshooting

The saved list has no effect

Check that Include domain lists when filtering is on, the list has actually been added, the correct Action is selected, and the policy has been saved. Then verify that the affected location or firewall is assigned to this exact filtering policy. A list under Domains does not filter anything by itself.

An allowed domain remains blocked

First check the entry’s spelling and scope: www.example.com does not automatically allow example.com or images.example.com. Then check the DNS cache, correct DNS path, and policy assignment. If the domain is treated as a security risk because of a poor threat score or dangerous reputation, that protection decision overrides the allow list.

A CNAME can also be the cause: if the category of the CNAME target is blocked, the name originally requested remains unavailable. On Windows, you can check the chain with a targeted nslookup against the DNS Protection resolver that is actually in use:

nslookup <domain-name> <dns-server-ip-address>

On Linux, dig shows the response chain:

dig <domain-name>

Replace <domain-name> with the affected hostname and <dns-server-ip-address> with the DNS server address that the tested client actually uses. Look for CNAME or Aliases in the response. Do not allow the CNAME target without checking it: first verify its owner and classification, and add only the target hostname that is actually required. If the category is clearly incorrect, request reclassification instead of maintaining a permanently broad exception.

A changed block decision does not take effect immediately

If the domain has a long DNS TTL, a previously allowed result may remain cached until that TTL expires. First check that the correct policy was saved and assigned. Then clear the client cache or query again after the TTL expires. Do not repeatedly change the policy merely to override a DNS entry that is still cached.

Too many subdomains are allowed or blocked

The parent domain was probably entered. example.com also applies to its subdomains. Narrow the entry to the hostname actually required, such as portal.example.com, save, and retest.

An internal service remains unreachable

An allow list changes only the filtering decision; it does not provide private DNS resolution. Check whether the internal zone reaches the internal resolver through a DNS Request Route or a domain exclusion. Then test resolution and filtering separately.

The list cannot be deleted

Open the policy named in the error, remove the list from it, and save the policy. Only then try deleting it again under Domains. If the assignment is intentionally still required, the list must not be deleted.

A website is categorized incorrectly

A small domain list can correct the filtering decision temporarily and traceably. For a permanent correction, submit the URL to Sophos Support for reclassification:

  1. Under Submit a Sample, select Web Address (URL).
  2. Enter the affected URL under Web Address (URL).
  3. Under Product/Services, select Sophos XG Firewall. Sophos Firewall and DNS Protection use the same website categories.
  4. Under Comments, explicitly state that the reclassification is being requested for DNS Protection rather than Sophos Firewall, and add the business reason.
  5. Enter the contact details and select Submit URL.

Until Sophos has reviewed the classification, keep the exception narrowly limited to the required domain. After a correction, retest it and remove it from the allow list if the normal category decision once again permits the required access.

Delete a list safely

  1. First open every filtering policy that uses the list.
  2. Remove the list under Filtering by domain lists and save the policy.
  3. Perform a brief functional test so that a required exception does not disappear unnoticed.
  4. Return to My Products > DNS Protection > Domains.
  5. Select the list and choose Delete.

A list that is still used in a policy cannot be deleted. In this case, Sophos names the relevant policy in the error message. Remove the assignment there; a different list with the same name or a broader category allowance is not a safe substitute.