Configure and test DNS host entries on Sophos Firewall

A DNS host entry allows Sophos Firewall to answer a specific hostname directly with a configured IP address. This is suitable for a small number of fixed internal systems, such as an appliance, a management service, or a server name that the firewall itself must resolve.

The entry only has an effect if the DNS query actually reaches the firewall. If a client uses a domain controller, a public resolver, or DNS over HTTPS, the firewall doesn’t see that query as the DNS resolver. A DNS host entry also replaces neither a rule object nor routing, NAT, or a firewall rule.

⚠️ Publish on WAN remains turned off for internal entries. Public publishing requires a deliberate authoritative DNS design, appropriate NS records, tightly restricted device access, and a negative recursion test. A DNS ACL permission from WAN alone isn’t a reason to expose the DNS service publicly.

DNS host entry in eight steps

1. Confirm that the name is static and that an entire internal DNS zone doesn’t need to be forwarded.
2. Check whether the affected clients actually use Sophos Firewall as their DNS server.
3. Document the FQDN, destination address, IP version, TTL, and an optional PTR record.
4. Enter the name and address under Network > DNS > DNS host entry > Add.
5. Leave Publish on WAN turned off for an internal entry.
6. Check the firewall’s view under Network > DNS > Test name lookup.
7. Query the firewall IP explicitly from the client and test forward and, if required, reverse resolution.
8. Only then test the actual application and document the entry and its dependencies.

When a DNS host entry is suitable

A DNS host entry is suitable for a single, stable name whose answer is maintained directly on the firewall. Typical examples include:

• an internal appliance without its own DNS record;
• a fixed management FQDN for LDAP, RADIUS, or another service;
• a single hostname for a controlled migration;
• a public service with deliberately planned inbound DNS load balancing across multiple WAN addresses.

For an entire domain, Active Directory, or dynamically maintained internal zones, a DNS request route is cleaner. It forwards the zone to the responsible DNS server instead of maintaining every name individually on the firewall.

An IP host or FQDN host also serves a different purpose. These objects are used in firewall and NAT rules; they don’t answer a client’s DNS query. Use IP hosts, services, and groups correctly explains the object types.

A Dynamic DNS configuration, by contrast, updates a name at an external provider when a WAN address changes. The complete procedure is described in Configure Dynamic DNS on Sophos Firewall.

SFOS supports the record types A, AAAA, and PTR for DNS host entries. The function is therefore not a full authoritative DNS server for CNAME, MX, TXT, or SRV. Each DNS host entry supports up to eight addresses; the firewall supports up to 1024 DNS host entries in total.

Example and replaceable values

The example maps a single internal application server:

• Hostname: app01.corp.example
• IPv4 address: 192.0.2.20
• Client network: 10.20.30.0/24
• Firewall IP as DNS server: 10.20.30.1
• Test client: 10.20.30.50
• TTL: 300 seconds
• Publish on WAN: turned off
• Reverse DNS: optionally turned on

The .example zone and 192.0.2.0/24 are reserved for documentation. In a production environment, replace the FQDN, address, client network, and resolver IP with the actual values. The name should match the internal naming strategy and must not unintentionally override an existing authoritative zone.

The TTL of 300 seconds is a controlled example value for testing and migration, not a universal recommendation. A short TTL speeds up planned changes but generates more DNS queries. A long TTL reduces queries but leaves old responses in caches for longer after a change.

Add the DNS host entry

Under Network > DNS, scroll to DNS host entry and select Add:

1. Enter app01.corp.example under Host/Domain name.
2. Use an IP address as the Entry type.
3. Enter 192.0.2.20 under IP address.
4. Enter 300 under Time-to-live.
5. Don’t treat Weight as a load-balancing tool when only one address exists.
6. Leave Publish on WAN turned off.
7. Turn on Add reverse DNS lookup for this host entry only if the firewall should also return a PTR response for this address.
8. Select Save.

For an IPv4 address, the firewall returns an A response; for an IPv6 address, it returns an AAAA response. The optional reverse lookup maps the address back to the name as a PTR. However, it doesn’t create a PTR record on a domain controller or an external DNS server.

If several hostnames point to the same IP address, only one of them can serve as the reverse target. It should therefore be clear which name is expected as the canonical PTR response before this option is turned on.

Use an interface instead of a fixed address

An interface can be selected as the entry type instead of a fixed IP. This is suitable when the response should deliberately follow the current address of that interface, for example in a planned public multi-WAN design.

Selecting an interface doesn’t replace verification of the actual WAN path. After an address change, link change, or HA failover, test the DNS response, reachable service, and return path again with a new connection.

Test resolution on the firewall and client

First, use Network > DNS > Test name lookup to verify that the firewall returns the expected address for app01.corp.example. If reverse DNS is turned on, query 192.0.2.20 as well.

This test only confirms the firewall’s resolver view. The affected client must then explicitly query the firewall IP 10.20.30.1.

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux or macOS:

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

The response must contain the expected record, the correct address, and, for reverse lookup, the intended name. Then test the application by its FQDN. A correct DNS response doesn’t yet prove that routing, the firewall rule, NAT, the TLS certificate, and the service work.

If it is unclear whether the query reaches the firewall, use a narrow filter under Diagnostics > Packet capture, such as:

host 10.20.30.50 and port 53

The query and response must be visible on the expected interface. Packet capture on Sophos Firewall explains safe recording and analysis in detail.

Use multiple addresses and weights deliberately

A DNS host entry can contain up to eight addresses. This is intended for inbound DNS load balancing or failover across multiple WAN links, not for a random collection of internal servers.

The Weight values determine the ratio in which responses are distributed across the listed links. Verify this behavior with repeated DNS queries and real application connections. DNS response distribution alone confirms neither the availability of the published service nor a correct DNAT and return path.

Multiple addresses don’t automatically become a general health check for internal applications. For a public design, Sophos documents failover for an unreachable or failed interface. This doesn’t guarantee that a reachable WAN interface also delivers the application service behind it correctly.

Weighted DNS and the DNAT configuration generated by Server Access Assistant must not be planned as a simultaneous shared mechanism for the same DNS host entry. Publishing requires a consistent design covering the DNS response, WAN address, DNAT, firewall rule, TLS, and return path. Publish a server using DNAT explains the data path separately.

Use Publish on WAN only for authoritative designs

Publish on WAN alone isn’t sufficient for a public response. For Sophos Firewall to answer as a name server for a published service, the authoritative zone must be delegated to name server names whose A/AAAA or glue records point to the intended WAN addresses.

The following items are also required:

1. The public domain and the responsible DNS zone are clearly documented.
2. The NS delegation and the associated address or glue records lead to the intended WAN addresses.
3. Under Administration > Device access, DNS is allowed only through the required WAN zone or a narrow Local Service ACL Exception.
4. Publish on WAN is turned on only for the intended addresses.
5. The published name is tested successfully from an external resolver.
6. Non-authoritative names and recursive queries are tested negatively from outside.
7. DNAT, the firewall rule, certificate, and return path of the actual service are verified separately.

An additional DNS ACL exception doesn’t narrow an already active broad WAN zone permission. Either DNS remains turned off for WAN in the matrix and is allowed through a targeted exception, or the broader permission is documented as deliberate exposure. Device Access and Local Service ACL explains a lockout-safe approach to this layer.

If the delegation, response scope, or protection against recursive use can’t be verified clearly, don’t turn on Publish on WAN. For ordinary public DNS zones, a dedicated authoritative DNS service is usually the clearer solution.

Narrow down errors by symptom

Firewall resolves, but client doesn’t

• Check which DNS server is actually configured on the client. DHCP can distribute the firewall IP; the procedure is described in Configure DHCP Server on Sophos Firewall.
• Check DNS over HTTPS, VPN client settings, and static resolvers on the client as alternative paths.
• Under Administration > Device access, check whether DNS is allowed from the client zone.
• Use Packet Capture to confirm whether the query and response pass through the firewall.
• Don’t change routing or NAT while the client isn’t querying the firewall at all.

Client still receives the old address

• Check the current entry for typos, duplicate hostnames, and multiple addresses.
• Take the still-valid old TTL and local, browser, or application caches into account.
• Send a new explicit query to the firewall IP instead of only reloading the application.
• Before a planned migration, lower the TTL in good time and allow the previous TTL to expire fully.

Flushing a cache can clean up a single test client, but it doesn’t change responses in other resolvers or application caches. It therefore doesn’t replace controlled waiting and a test through the DNS chain actually in use.

Reverse lookup is missing or returns the wrong name

• Check whether Add reverse DNS lookup for this host entry is turned on.
• Ensure that multiple names aren’t claiming the same address as their PTR target.
• Send the reverse query explicitly to the firewall IP.
• If an internal reverse zone is hosted on a domain controller, use the appropriate DNS request route instead of a local PTR entry.

Public query receives no response

• Check the NS delegation and reachability of the WAN addresses from outside.
• Check Publish on WAN for every intended address.
• Check Device Access, Local Service ACL, upstream filters, and UDP and TCP port 53.
• Record a Packet Capture during one specific external query.
• Don’t enable a broad DNS permission as an attempted fix.

DNS is correct, but the application remains unreachable

DNS only supplies the destination address. Routing, the firewall rule, NAT, TLS, and the actual service follow. The test should therefore check the IP address, port, and application protocol in sequence. For rule and path issues, see Test a firewall rule with Log Viewer, Policy Test, and Packet Capture.

Changes, HA, and rollback

Before a change, document the name, current response, TTL, reverse lookup, client resolvers in use, and dependent services. With multiple addresses, include the weights, WAN association, NS delegation, DNAT, and return path in the baseline.

In an HA cluster, perform a new DNS query after a planned failover. For public publishing, also test both WAN paths and a new application flow. This article assumes neither synchronized DNS caches nor an uninterrupted active connection.

For rollback:

1. Before a planned migration, lower the TTL and wait for the previous TTL to expire.
2. Document dependent applications and the public DNS path.
3. Restore the address, interface, or host entry to the confirmed baseline.
4. Remove a temporary Device Access exception and WAN publishing that is no longer required.
5. Query explicitly again from the firewall and client.
6. Retest forward lookup, optional PTR, reachability, and the actual application.

Checklist

• Sophos Firewall sees the DNS query from the affected client.
• A single static name fits better than a DNS request route.
• FQDN, IP version, address, and TTL are documented.
• Publish on WAN remains turned off for internal entries.
• A PTR entry is turned on only for the canonical name of the address.
• The firewall and client return the same expected response.
• DNS access is restricted to the required sources in Device Access.
• For multiple addresses, weights, link state, and application path have been tested.
• For WAN publishing, NS delegation, name server addresses, and a negative recursion test are documented.
• The rollback and cache waiting time are known before the change.

Frequently asked questions