Configure DNS Request Routes on Sophos Firewall

A DNS Request Route forwards queries for a particular domain or reverse zone to selected DNS servers. A common example is ad.example.com: the firewall resolves public names through its usual resolvers but sends queries for this internal zone to the domain controllers.

The route applies only when Sophos Firewall processes the query as a DNS server. If a client queries an internal DNS server directly, that server’s forwarding configuration applies; the firewall’s request route does not.

The target zone does not have to be internal: a Request Route can also forward selected public domains to a resolver on your own network. This makes sense when that resolver is deliberately responsible for those domains. Local processing can reduce external DNS queries, but any particular speed improvement or additional confidentiality depends on the target resolver processing the queries accordingly rather than simply forwarding them unchanged to the internet.

Determine the DNS path before making changes

Three configurations that may look similar serve different purposes:

• The client queries the firewall: DHCP or the VPN profile supplies the firewall interface IP as the DNS server. To reach the local DNS service, the client zone must be allowed to use DNS under Administration > Device access > Local service ACL. Standard firewall rules do not control access to a service hosted by the firewall itself.
• The client queries an internal DNS server directly: The internal resolver answers its local zones and forwards other queries. A standard firewall rule may be required when traffic crosses zones. This client path does not use a request route configured on the firewall.
• The firewall queries an internal target server: A request route selects the target server according to the queried domain. The route to that server and the server’s reachability must both be correct.

A DNS Host Entry, by contrast, lets the firewall answer directly for one name. For a small number of static records, see Set up DNS Host Entries on Sophos Firewall. A request route is more appropriate for an entire zone maintained on a DNS server. DHCP options determine which DNS server and search domain a client receives; see Configure DHCP Options on Sophos Firewall.

⚠️ A request route is selected by domain name, not by the client’s source network. If different sites require different answers, the resolvers involved or separate DNS paths must provide those views. A single route cannot create source-dependent DNS responses.

Example and prerequisites

This example forwards an internal AD zone to two resolvers:

• internal zone: ad.example.com
• primary target server: 10.10.10.10
• secondary target server: 10.10.10.11
• client network: 10.20.30.0/24
• firewall IP used as the client resolver: 10.20.30.1
• positive test: dc01.ad.example.com
• negative test: example.net

example.com and example.net are reserved documentation domains. Replace the zone, server addresses, and interface address with your own production values. Both target servers should be authoritative for the same zone and hold the same zone data. A long list of unrelated resolvers is not a sound redundancy strategy.

Confirm the following before creating the route:

1. The firewall is configured as a resolver under Network > DNS > DNS configuration.
2. The target servers are reachable over the intended local or VPN route.
3. The clients that should use the route actually have the firewall IP configured as their DNS server.
4. Under Administration > Device access, DNS is enabled only for the required client zones. If the entire zone should not have access, use a more restrictive Local Service ACL Exception.
5. The internal zone exists on the target servers and contains a known record for testing.
6. The current DNS path and existing request routes are documented so the change can be rolled back.

Create the DNS Request Route

1. In WebAdmin, open Network > DNS.
2. Go to the DNS request route section.
3. Select Add.
4. In Host/Domain name, enter ad.example.com.
5. Under Target servers, select 10.10.10.10 and 10.10.10.11. If the server objects do not yet exist, use Create to add them as IP hosts.
6. Check the order. SFOS queries the selected hosts in the order shown.
7. Select Save.

Sophos supports up to eight target IP addresses per request route. Additional servers improve availability only when they answer the same zone correctly and are reachable over independent paths that have been tested.

When a request route matches and no suitable answer is cached, SFOS sends the query to that route’s Target Servers. It does not fall back to global forwarders or root servers for the domain. If every target server is unreachable or incorrectly configured for the zone, resolution fails rather than silently using a public resolver.

The new entry should then appear under DNS request route with the expected domain and target servers.

Assess multiple target servers correctly

The documented server order provides an availability mechanism; it does not reconcile conflicting DNS data. For global static resolvers, SFOS treats NXDOMAIN as a valid answer and does not then query the next server. The SFOS 22 help does not explicitly confirm the same behavior for request-route Target Servers. Do not rely on a second server holding different zone data, and do not promise a particular failover outcome after NXDOMAIN.

As part of acceptance testing, query each target server separately from an authorized test system. Both servers must return the same positive answer. A deliberately nonexistent name should also produce the same result from each server. These checks expose replication or zone-authority problems before the firewall needs to switch servers.

nslookup dc01.ad.example.com 10.10.10.10
nslookup dc01.ad.example.com 10.10.10.11
nslookup does-not-exist.ad.example.com 10.10.10.10
nslookup does-not-exist.ad.example.com 10.10.10.11

These direct queries test the zone data and each server’s response, not the request route. Run them only from a network that is permitted by the DNS design to reach both resolvers. Then query through 10.20.30.1 to confirm that the firewall forwards the zone to the intended servers.

Forward reverse lookups

For PTR queries, enter the reverse zone—not a network—in Host/Domain name. For 172.16.16.0/24, the conventional IPv4 reverse zone is:

16.16.172.in-addr.arpa

For 172.16.0.0/16, it is:

16.172.in-addr.arpa

Do not enter CIDR notation such as 172.16.16.0/24 in the domain field. What matters is the zone actually configured on the internal DNS server. A request route does not create PTR records. If the zone or records are absent from the target server, reverse lookups still fail. Non-octet-aligned IPv4 networks and IPv6 reverse zones require a purpose-built DNS delegation design; do not improvise one by simply reversing the prefix.

Reverse DNS helps logs and services associate an address with a name. It cannot fix a failed forward lookup for an FQDN, so test it separately.

Understand the global resolver path

Under Network > DNS > DNS configuration, specify how the firewall resolves queries that match neither a Host Entry nor a Request Route. Depending on the interface, SFOS can learn resolvers through Obtain DNS from DHCP or Obtain DNS from PPPoE. With Static DNS, set DNS 1, DNS 2, and optionally DNS 3 explicitly.

⚠️ If Obtain DNS from DHCP is active and the last applicable DHCP interface is turned off or changed to another assignment mode, SFOS switches to Static DNS. Re-enabling the interface does not restore the previous selection automatically. Check the DNS selection after changing WAN or interface settings.

With Static DNS, the firewall queries servers in their configured order. It moves to the next server after a timeout, but not after a valid NXDOMAIN response. Answers remain cached according to their TTL. A second resolver is therefore a reachability fallback, not an alternative source of DNS truth.

SFOS 22 documents four selection options for global DNS servers. Both IPv4 and IPv6 DNS servers must be configured for the two fixed-priority options:

• Choose a server based on incoming requests record type selects the DNS server based on the requested record type, A or AAAA.
• Choose IPv6 DNS server over IPv4 gives the IPv6 DNS server priority over the IPv4 DNS server.
• Choose IPv4 DNS server over IPv6 gives the IPv4 DNS server priority over the IPv6 DNS server.
• Choose IPv6 if request originator address is IPv6, else IPv4 uses the IPv6 DNS server for a query from an IPv6 source address and the IPv4 DNS server for a query from an IPv4 source address.

Record type and source address family are distinct criteria: an AAAA query is not automatically a query from an IPv6 source address. Selection is therefore based on the intended resolver path, not solely on the desired address in the DNS response. The selected resolvers must be reachable over the respective address family. These global options do not change the domain-based selection of a Request Route’s Target servers.

After selecting Apply, use Test name lookup to resolve a hostname or IP address from the firewall’s perspective. An internal test name may match a request route. This test does not, however, confirm which resolver a client uses or the path its queries actually take.

If WebAdmin is unavailable during a planned recovery, the interactive CLI at 1. Network Configuration > DNS Configuration shows the global IPv4 and IPv6 DNS servers. This menu does not modify request routes. Record every displayed value before entering anything; pressing Enter without a new value skips that change. Keep an independent management path available when making changes remotely.

Combine DNS Protection with internal zones

Choose the version first: From SFOS 23.0, use the integrated DoH path with DNS Protection under Network > DNS and the Filtering Policy assignment to the firewall object. The DNS Protection article linked below describes setup, the fallback decision, the pilot, and rollback. The following Location/DDNS and Static DNS sequence applies exclusively to Traditional DNS on SFOS 22 and earlier; do not additionally perform it for the integrated SFOS 23 path. Internal Request Routes and the client-path/NAT checks remain relevant.

With Sophos DNS Protection and Sophos Firewall, public queries go to DNS Protection while request routes send internal zones to local resolvers. First register the firewall as a location in Sophos Fusion (formerly Sophos Central). If several public WAN addresses are used, register every relevant address or the appropriate range. For a dynamic WAN address, use the registered DDNS hostname.

Sophos’s official configuration sets the two DNS Protection addresses as DNS 1 and DNS 2 under Network > DNS > DNS configuration, leaves DNS 3 empty, removes IPv6 DNS servers, and selects Choose IPv4 DNS server over IPv6. A third resolver or an unintended IPv6 resolver can allow queries to bypass DNS Protection.

Sophos specifies a particular DHCP configuration: under Network > DHCP > Server > Edit, leave Use device’s DNS settings turned off. Set Primary DNS to the firewall IP on the DHCP interface and Secondary DNS to a public DNS Protection address. Clients do not all handle multiple resolvers in the same way, so verify that internal queries actually pass through the firewall. Queries sent directly by a client to DNS Protection do not use the firewall’s local request routes.

Sophos also describes a DNAT rule that redirects conventional outbound DNS queries from internal networks to the firewall’s internal IP. This redirection is a separate security decision: it does not automatically capture DNS over HTTPS or DNS over TLS, and it can affect specialized devices. Introduce it only for clearly defined source networks, never with WAN as the Inbound Interface, and with documented exceptions and a rollback plan.

Test the firewall and client separately

Firewall resolver view

Under Network > DNS > Test name lookup, test dc01.ad.example.com and then example.net. The internal name must return the expected internal address, while the public name must continue to resolve through the intended default path.

The officially documented command provides the same view from 4. Device Console:

dnslookup host dc01.ad.example.com
dnslookup host example.net

These checks show the firewall’s resolver view. They do not prove that a client is querying the firewall.

Compare individual resolvers under Diagnostics

Under Diagnostics > Tools, SFOS 22 provides Name lookup with IP address or hostname and DNS server IP. An FQDN tests forward resolution; an IPv4 or IPv6 address tests reverse resolution. Select a specific configured server, or use Lookup using all configured servers to compare answers and response times from all configured resolvers. A short response time alone does not justify changing the server order; first confirm that the answers are correct for the intended zone.

In SFOS 23, the section is called DNS lookup, and the fields are Hostname or IP address and DNS server IP address. Alongside an available server and All configured servers, the options include Custom DNS server and Custom DoH server; for either custom option, enter the IP address of the server you want to query. DNS Protection is selectable only when DNS Protection is enabled under Network > DNS. This is a diagnostic option, not a recommendation to rework the existing DNS configuration for a test.

Use only approved internal resolvers for internal test names so that the names are not sent to a public DNS or DoH service. A query to a specific resolver confirms its answer, not the actual Request Route or client path. Acceptance testing through the firewall IP and with Packet Capture therefore remains necessary.

Verify the client path

On a test client, first check the configured DNS server, and then query the firewall IP 10.20.30.1 explicitly.

Windows:

ipconfig /all
nslookup dc01.ad.example.com 10.20.30.1
nslookup example.net 10.20.30.1

macOS or Linux:

dig @10.20.30.1 dc01.ad.example.com A
dig @10.20.30.1 example.net A

Next, repeat the same queries without specifying a server. If the results differ, the client is using another resolver path, such as a static setting, a VPN profile, DNS over HTTPS, or a local security agent. A search domain matters only for short, unqualified names; the FQDNs above do not require one.

Capture packets on the actual path

Under Diagnostics > Packet capture, narrow the traffic with a filter for the test client, target servers, and port 53. Packet Capture on Sophos Firewall explains the procedure in detail.

(host 10.20.30.50 or host 10.10.10.10 or host 10.10.10.11) and port 53

Look for the incoming client query, the query generated by the firewall to the correct Target Server, and the corresponding responses. The capture distinguishes a client-access problem from a routing or target-server problem. Because the capture buffer is limited, keep the filter narrow and record only during the test.

When DNS Protection is in use, the official Check your configuration link under My Products > DNS Protection > Installers provides an additional check. The welcome page confirms the DNS Protection path, but the internal zone, client path, and request route still need separate tests.

Troubleshoot by symptom

The firewall resolves the internal name, but the client does not

• Confirm that the client is actually using the firewall IP as its DNS server.
• Under Administration > Device access, confirm that DNS is allowed for the client zone or through an appropriate Local Service ACL Exception.
• Send the query explicitly to the firewall IP and verify it with Packet Capture.
• Check DHCP, VPN, and local resolver settings, as well as DoH and DoT, for alternative paths.

The firewall cannot reach the target server

• Check Route Lookup and the local or VPN path to the target address.
• Check both UDP and TCP port 53 all the way to the target server, including the server’s own ACL.
• Query the resolver directly and confirm that it accepts requests from the firewall IP.
• In Packet Capture, look for the generated query, a response, or a drop reason.

If clients query the internal DNS server directly, troubleshoot the standard transit path, including zones and the relevant firewall rule. Test firewall rules with Log Viewer, Policy Test, and Packet Capture helps distinguish this case.

Answers are incorrect or inconsistent

• Domain is too broad or incorrect: Restrict the request route to the zone for which the server is actually authoritative.
• Target servers return different data: Check DNS replication and zone authority directly on each server.
• Answer is stale: Account for the TTL and caches on the firewall, resolver, and client.
• Only short names fail: Check the client’s search domain and test the FQDN separately.
• Reverse lookup fails: Check the PTR zone and PTR record on the target server.
• Only VPN clients are affected: Check the assigned DNS servers, VPN routing, and access to the local DNS service. The relevant client settings are described in Configure Sophos Connect and Set up SSL VPN Remote Access.

XML API: identify the route by its object name

From SFOS 23, the XML API documentation requires both Name and DomainName when adding and editing a DNS Request Route. Name identifies the configured object, while DomainName is the DNS zone to forward; for example, Name = ad-intern and DomainName = ad.example.com. These are field values, not executable XML. Name is a single STRING with a maximum of 64 characters, permits UTF-8, and prohibits commas. DomainName remains FQDN with a maximum of 255 characters; the target servers must still be specified as well.

For deletion, the documented key changes from DomainName in SFOS 22 to Name in SFOS 23. Do not replay old requests unchanged or automatically use the domain name as the object name. First check the installed version and read the specific object, compare Name, DomainName, Target Servers, and dependencies with the intended target, and document the rollback path. If there is any ambiguity, stop. Afterwards, check the API response and status, and read back the exact target: only the intended route may have been removed; other routes must remain unchanged. Then test internal and public resolution as described above. No deletion envelope or REST schema is invented here, and no product test is claimed.

The global DNS protocol configuration is separate. The DNS Protection article explains the unresolved SFOS 23 XML schema conflicts and the safe WebAdmin path; the four resolver options above, explicitly described for SFOS 22, do not establish a numeric SFOS 23 API mapping.

XML API: SFOS 22 — Add/Edit; SFOS 23 — Add/Edit; SFOS 22 — Delete; SFOS 23 — Delete.

Rollback and ongoing operation

Before making the change, record the existing request routes, global DNS selection, Device Access permissions, and the results of one positive and one negative test. For a routine rollback, remove the newly created route or restore the exact values documented beforehand. Return any temporary ACL exceptions or DNS redirections to their original state as well.

Then verify these three points again:

1. The firewall resolves one internal and one public name through their intended paths.
2. The affected client uses the intended resolver and receives the expected answers.
3. A domain outside the route is not sent to the internal Target Server.

A full configuration backup is not a convenient single-object rollback. Restoring it replaces the entire configuration and may overwrite later changes. For one request route, reversing the documented object-level change is the safer approach.

Frequently asked questions