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 networks. 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 make sense when the desired DNS behaviour and the responsible DNS servers are clearly defined.

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.

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: Firewall forwards public domains globally and internal domains via DNS Request Route Small and medium sites, DNS Protection, guest/client networks.
• Clients query internal DNS servers directly: Domain controller or DNS server resolves internally and forwards externally Classic Active Directory networks with Windows DNS as the central resolver.
• VPN clients query the firewall: Firewall uses request routes for internal domains Remote access with a simple DNS path via the firewall.
• VPN clients query internal DNS servers directly: DNS runs over VPN to the domain controller or DNS server 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.

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
• 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.

Configure DNS Request Route

The route defines which DNS servers are asked for a specific domain or reverse zone.

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.
3. Select DNS.
4. Switch to the DNS request route section.
5. Add a new DNS Request Route.
6. Enter the internal domain under Host/domain name, for example, company.local.
7. Select the internal DNS server under Target servers or create it as a host via Create.
8. Save.

The firewall will then query the specified DNS server for this domain.

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.

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.

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.

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

DNS changes should always be verified from the firewall and from real clients.

Tests and Validation

After configuration, you should test name resolution:

• Can the firewall resolve the internal 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 behavior. If the query against the firewall also fails, the next checkpoints are request route, target server, routing, or firewall rule.

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 the expected result is missing, work through logging, rule matching and policy behaviour step by step.

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.
• 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.

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

FAQ