Configure DNS Request Routes on Sophos Firewall

With DNS Request Routes, you can specify on the Sophos Firewall which DNS server should be used for certain domains or reverse zones. This is particularly useful when the firewall uses public DNS servers, but internal names need to be resolved via an internal DNS server.

Typical examples include Active Directory domains, internal applications, reverse lookups, or VPN environments.

When Sophos DNS Protection with Sophos Firewall is used, DNS Request Routes become even more important. Public domains then go to the DNS Protection service, but internal domains continue to go to the local DNS server or domain controller. Without this separation, internal applications, AD logins, or reverse lookups can suddenly appear as network issues.

Orientation and Design

DNS Request Routes only work reliably when it is clear which resolver sees which query. Therefore, first separate DNS design, client DNS, internal zones, and routing path.

DNS Request Route, DNS Server, or DHCP Option?

DNS Request Routes are often confused with global DNS servers or DHCP options. The functions solve different problems.

• Global DNS Servers: Default resolution of the firewall Internet DNS, general FQDN resolution, updates, and cloud services.
• DNS Request Route: Send specific domain or reverse zone to defined DNS server Active Directory, internal domains, site DNS, split DNS.
• DHCP Option: Distribute DNS server or search domain to clients Clients should directly use a specific DNS server.

A DNS Request Route does not automatically change the DNS configuration of all clients. The route controls where the Sophos Firewall itself or clients using the firewall as a DNS forwarder forward specific DNS queries. If clients should directly use an internal DNS server, a DHCP Option on Sophos Firewall is more appropriate.

The difference to a DNS Host Entry is also important: a DNS Host Entry answers a specific hostname directly with an IP address on the firewall. A DNS Request Route, by contrast, forwards a domain or zone to another DNS server. For Active Directory and dynamic internal zones, a request route is almost always cleaner than many individual host entries.

Which DNS Design Fits?

Before creating a DNS Request Route, it should be clear which resolver is used in the respective network. The route only helps if the Sophos Firewall sees the request.

• Clients query the Sophos Firewall: The firewall forwards public domains globally and internal domains via DNS Request Route. This fits small and medium sites, DNS Protection, and guest or client networks.
• Clients query internal DNS servers directly: Domain controllers or DNS servers resolve internally and forward externally. This fits classic Active Directory networks with Windows DNS as the central resolver.
• VPN clients query the firewall: The firewall uses Request Routes for internal domains. This fits Remote Access with a simple DNS path through the firewall.
• VPN clients query internal DNS servers directly: DNS runs over VPN to the domain controller or DNS server. This fits larger AD environments when clients should use the same DNS logic as in the LAN.

In mixed environments, a short DNS sketch is very helpful: client network, assigned DNS server, search domain, internal DNS zones, DNS Request Routes, and routing path to the target server. Without this overview, work is often done on the request route later, even though the client does not use the firewall as a DNS resolver.

For DNS Request Routes to affect clients, the Sophos Firewall must be in the DNS query path. This can be direct, if clients receive the firewall interface IP as DNS server, or indirect, if an internal resolver deliberately forwards to the firewall. If clients directly query a domain controller, the firewall does not see this DNS query as resolver and cannot redirect it via request route.

When Do You Need DNS Request Routes?

DNS Request Routes are useful when:

• Internal hostnames like server01.company.local need to be resolved
• Reverse lookups for internal IP networks should work
• VPN users should use internal names
• Multiple sites have their own DNS zones
• The firewall itself needs to reach internal systems via FQDN
• Public DNS servers do not know internal names

Without a DNS Request Route, the firewall queries the globally configured DNS server. If the internal domain is not known there, the resolution fails.

This difference is particularly important for remote access. If VPN clients use the firewall as a DNS server, a DNS Request Route can ensure that internal domains still end up at the correct domain controller or DNS server. If VPN clients instead receive internal DNS servers directly, it must also be checked whether routing, firewall rules, and DNS suffixes on the client are correct.

Prerequisites

• Access to the WebAdmin of the Sophos Firewall
• Sophos Firewall is cleanly configured as a DNS resolver or DNS forwarder under Network > DNS > DNS configuration
• Internal DNS server is reachable
• Domain or network is known
• Firewall rules allow DNS traffic to the target server
• For site networking: routing to the DNS server works
• The affected client either uses the firewall as a DNS server or deliberately receives another DNS server

⚠️ DNS issues often appear as routing, VPN, or application problems. Before making major changes, check whether the target server is reachable by IP and whether only the name resolution fails.

Under Network > DNS > DNS configuration, also check how the firewall resolves its normal DNS queries. If DNS Protection is used, the DNS Protection IP addresses are listed there. If classic forwarders or internal resolvers are used, those servers must be reachable. With Test name lookup, you can check directly in the DNS configuration whether the firewall can generally resolve a name or an IP.

Configure DNS Request Route

The configuration is technically simple, but quickly becomes confusing when domains, reverse zones, VPN clients, and multiple sites come together.

Create a DNS Request Route for a Domain

A domain route ensures that queries for a specific domain are sent to a defined DNS server.

Example:

• Host/domain name: company.local
• DNS server: 10.10.10.10

Procedure:

1. Log in to the Sophos Firewall.
2. Open Network > DNS.
3. Switch to the DNS request route section.
4. Select Add.
5. Enter the internal domain under Host/domain name, for example, company.local.
6. Select the internal DNS server under Target servers or create it as a host via Create.
7. Save.

The value in Host/domain name should be written like an FQDN or zone name, not like a URL, wildcard rule, or free-form description. The Sophos API treats this value as an FQDN field with a maximum length of 255 characters. For normal domain routes, company.local is enough; for reverse lookups, use the matching in-addr.arpa zone.

If a DNS cache hit is missing on the firewall, the matching query for this domain is not sent to the normal forwarders or root servers, but to the target servers of the request route. This is intentional: internal zones should not accidentally be queried externally. However, it also means that an incorrectly chosen target server can answer the query cleanly while still being functionally wrong.

Use Multiple Target Servers

Under Target servers, you can add more than one DNS server. This is useful if there are multiple internal DNS servers or if DNS should be redundantly accessible over a site connection.

Possible target servers:

• Internal DNS servers in the local network
• DNS servers on the other side of a VPN connection
• DNS servers at another site
• Public DNS servers if a specific domain should be deliberately resolved externally

The order is relevant. The firewall queries the selected hosts in the order they appear in the list. Up to eight IP addresses can be stored per DNS Request Route. However, more target servers do not automatically mean better redundancy if the servers have different zone states, different forwardings, or different accessibility over VPN.

With multiple target servers, you should not only enter redundancy but also check responsibility. If the first DNS server knows the zone but provides outdated entries, the request route will technically work but still give incorrect answers.

An NXDOMAIN is a valid DNS response. If the first reachable DNS server says that a name does not exist, the firewall does not automatically ask the next server hoping for a different answer. Therefore, target servers for the same DNS Request Route should have the same zone state and the same forwarders.

Split DNS for VPN and Sites

Split DNS means that the same name is resolved differently depending on the site or network. An internal portal can, for example, point to a private IP internally, while the same name externally points to a public address or is not resolved at all.

On the Sophos Firewall, three points are crucial for this:

1. The appropriate DNS Request Route for the internal domain.
2. A firewall rule that allows DNS from the firewall or client to the internal DNS server.
3. A routing path to the DNS server, especially for site-to-site VPN, SSL VPN, or Sophos Connect.

For remote access environments, you should also check which DNS servers and search domains the client receives. For Sophos Connect, see Configure Sophos Connect on Sophos Firewall. For classic SSL VPN setups, see Set up Sophos Firewall SSL VPN Remote Access.

With DNS Protection, an additional design question is added: Sophos recommends configuring network devices so they use the firewall as DNS resolver. For this, the firewall interface IP is normally distributed as DNS server in the firewall’s DHCP servers. If devices nevertheless use external resolvers, a targeted NAT rule for outbound DNS traffic to the firewall can be planned. This should be deliberate and not blanket, because hard DNS redirection can affect troubleshooting, BYOD devices, DoH/DoT, and special devices.

If the firewall itself uses DNS Protection as the forwarder, the DNS Protection IP addresses copied from Sophos Central should be entered under Network > DNS > DNS configuration as the primary and secondary DNS servers. A different third DNS server or an unintended IPv6 DNS path can cause requests to bypass DNS Protection. Therefore, DNS Request Routes, DHCP DNS options, IPv6 DNS settings, and optional DNS NAT rules should be checked as one shared design.

Reverse DNS for Internal Networks

A reverse DNS request route forwards PTR queries for an internal IP network to the DNS server that knows the appropriate reverse lookup zone. This helps when logs, reports, or services need to convert an IP address back to a hostname.

Example:

• Network: 172.16.16.0/24
• DNS server: 172.16.16.10
• Reverse zone: 16.16.172.in-addr.arpa

For reverse lookups, you also create a DNS Request Route under Network > DNS > DNS request route. However, under Host/domain name, you enter the reverse zone instead of the normal domain.

Example for 172.16.16.0/24:

16.16.172.in-addr.arpa

The order of the octets is reversed. So from the network 172.16.16.0/24, it becomes 16.16.172.in-addr.arpa. Important: Don’t enter CIDR notation such as 172.16.16.0/24 in Host/domain name. Enter a DNS zone instead. The value should therefore look like a domain or reverse zone name, not like a free-form description.

For larger networks, the reverse zone can be broader. Example: For 172.16.0.0/16, it would be 16.172.in-addr.arpa. What matters is how the reverse lookup zone is set up on the internal DNS server.

If there is no PTR zone or PTR records on the internal DNS server, the request route will not help. The firewall can only send the query to the correct DNS server, but it does not create reverse DNS entries on the DNS server.

In IPv6 environments with provider prefix, DNS should also be considered early. How clients receive their IPv6 address and the role of router advertisement and DHCPv6 are covered in Configure IPv6 Prefix Delegation on Sophos Firewall.

Tests and Operation

After configuration, test IP reachability, DNS resolution, and client DNS separately. This makes it easier to identify whether the problem is really with the request route.

Tests and Validation

After configuration, you should test name resolution:

• Can the firewall resolve the internal name?
• Does Network > DNS > Test name lookup work for an internal and a public name?
• Does resolution work from VPN or user zones?
• Is the DNS server reachable via ping or TCP/UDP 53?
• Are there entries in the DNS or firewall log?

If resolution does not work, first check:

• Is the domain spelled correctly?
• Does the client really use the Sophos Firewall or the correct DNS server?
• Does a firewall rule block DNS?
• Is there a missing route to the DNS server?
• Does the DNS server respond to queries from the firewall?

A sensible test separates IP reachability and DNS resolution:

1. Test the target system by IP, for example, ping, TCP port, or application.
2. Reach the DNS server itself by IP.
3. Resolve names via the expected DNS source.
4. Only then test the application via the name.

If access works by IP but not by name, the focus is on DNS Request Route, DNS suffix, client DNS, or reverse lookup. If access already fails by IP, first check routing, firewall rule, NAT, or VPN. For this distinction, Test firewall rule with Log Viewer, Policy Test, and Packet Capture and Check causes if Sophos Firewall rule does not match can help.

Test Commands for Firewall and Clients

On the Sophos Firewall, the Device Console can help test DNS from the firewall’s perspective:

dnslookup server01.company.local
dnslookup example.com

On clients, you should also check which resolver is actually used.

Windows:

ipconfig /all
nslookup server01.company.local
nslookup server01.company.local <firewall-ip>
Resolve-DnsName server01.company.local

macOS:

scutil --dns
dig server01.company.local
dig @<firewall-ip> server01.company.local

Linux:

resolvectl status
dig server01.company.local
dig @<firewall-ip> server01.company.local

<firewall-ip> stands for the internal interface address of the Sophos Firewall in the respective network. If the query against the firewall works, but the normal client query does not, the problem usually lies with DHCP, VPN profile, DNS suffix, local resolver, or browser/system DNS behaviour. If the query against the firewall also fails, the next checkpoints are request route, target server, routing, or firewall rule.

For clients with modern browsers or endpoint agents, also check whether DNS-over-HTTPS or a local security agent bypasses the normal DNS query. In that case, the firewall may not see a classic DNS request on UDP/TCP 53 even though the network configuration looks correct.

Define Positive and Negative Tests

A DNS Request Route is only properly tested when not only the desired internal name resolves, but also a counterexample has been checked. Otherwise, it remains unclear whether the route matches exactly the internal zone or whether DNS is being redirected too broadly.

A short test plan is usually enough:

• Positive test: An internal name from the target zone resolves to the expected private IP, for example server01.ad.firma.local.
• Negative test: An unaffected public domain continues to use the intended default path, for example global DNS, DNS Protection, or an internal forwarder.
• Client test: Run the test from the affected VLAN, VPN profile, or site, not only directly on the firewall.
• Log check: Firewall log, DNS log, or Packet Capture shows that the query reaches the expected resolver.
• Regression: Repeat the same test after changes to VPN, DHCP, DNS Protection, or site routing.

This small negative test prevents typical side effects: public domains being answered internally, DNS Protection being bypassed, Split-DNS only working from some networks, or a VPN client still using an old resolver.

Operational Check

DNS Request Routes should be as specific as possible. A route for the exact internal domain is better than a too broad configuration. For larger environments, a small table with domain, DNS server, site, and purpose is worthwhile to keep later changes traceable.

Practical documentation:

• Domain or Reverse Zone: ad.company.local
• Target Servers: 10.10.10.10, 10.10.10.11
• Purpose: Active Directory DNS for main site.
• Affected Networks: LAN, Admin VPN, Zurich site.
• Dependencies: Site-to-site VPN, domain controller, firewall rule DNS.
• Test: server01.ad.company.local resolves to expected internal IP.
• Negative test: for example, example.com continues to use the intended default path.

Troubleshooting

If DNS does not work, do not change the request route immediately. Often the client uses a different resolver, a firewall rule blocks DNS, or the reverse zone does not exist on the target server.

Common Errors

• Internal name does not resolve: Incorrect domain, e.g., company.local instead of ad.company.local Check domain in the request route and client’s search domain.
• VPN client does not resolve internal names: Client does not use the firewall or uses the wrong DNS server Check VPN DNS settings, client DNS, and firewall rule.
• Firewall cannot reach DNS server: Missing route, VPN, or firewall rule Check ping, packet capture, and route lookup.
• Firewall resolves externally but not internally: Check DNS Request Route, target server, and Test name lookup. Then use Packet Capture towards the internal DNS server.
• Reverse lookup does not work: Missing PTR zone or PTR records Check reverse lookup zone on the internal DNS server.
• Individual sites provide incorrect answers: Wrong target server or outdated zone data Check order of target servers and DNS replication.
• Public names are suddenly answered internally: Request route is too broad Use a more specific domain and avoid wildcard thinking.
• First DNS server answers NXDOMAIN: The firewall treats this response as valid and does not automatically query all further target servers. Check zone state and server order.
• DNS Protection does not apply to all clients: Check whether clients really use the firewall as DNS resolver or whether external resolvers, DoH/DoT, local agents, or manual DNS settings are in the way.

In VPN environments, you should also check whether the VPN clients receive the correct DNS servers and search domains.

FAQ