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 paths and fields in this guide correspond to SFOS 22.0 MR2 Build 546. Labels may differ slightly in older releases.

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. Up to eight addresses are supported for inbound load balancing of one name; the firewall supports up to 1024 DNS host entries in total.

DNS resolution paths and scope

For queries handled by the firewall itself, the configured handling is as follows:

• If the requested name matches a DNS host entry, the firewall answers with the address stored there.
• If a DNS request route matches, the firewall queries its Target servers in order after an unsuccessful cache lookup. It doesn’t fall back to forwarders or root servers for that name.
• Without a matching local entry or request route, it uses the servers specified under DNS configuration. Static servers are queried in order until a response arrives. NXDOMAIN is already a valid response, so the next server isn’t queried.

The SFOS 22 help describes host-entry and request-route matching separately, but doesn’t specify the result when the same name matches both. Don’t create that overlap: keep a host entry outside a routed zone, or remove the duplicate local entry. After any cleanup, query the firewall IP explicitly to verify the intended answer.

These resolution paths only apply when the firewall is the resolver for the query. A client using a domain controller, public resolver, or DNS over HTTPS directly bypasses these entries. DNS must also be allowed for the source zone or a suitable Local Service ACL Exception under Administration > Device access; a normal firewall rule doesn’t control access to this local service.

Configured DNS servers take precedence over root servers for general DNS resolution through the firewall’s interface IP. This does not guarantee that every unsuccessful query will be resolved through root servers. Queries matching a request route remain with the specified Target Servers.

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, under Network > DNS, use Test name lookup to verify that the firewall returns the expected address for app01.corp.example. Diagnostics > Tools > Name lookup instead queries a selected DNS server IP; Lookup using all configured servers compares the configured DNS servers and their response times. Use that tool only as an upstream comparison, not as proof that the local host entry or a request route matched. 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.

For a support handover or a before-and-after comparison, you can also download dnsd.log under Diagnostics > Tools > Troubleshooting logs. A Consolidated troubleshooting report (CTR) additionally contains status and log data. Because these files can contain configuration and environment details, only share them through a secure support channel.

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.

For two WAN addresses, maintain the same name in one host entry: enter, for example, www.example.com under Host/Domain name and 192.0.2.10 as the first IP address, then use Add within the form to add a second address and enter 198.51.100.10. These addresses are documentation values; replace them with the actual WAN addresses. Turn on Publish on WAN for both intended addresses only when the prerequisites in the following section are met, then select Save. Two different hostnames would not provide load balancing for the same service.

In the documented multi-WAN flow, the external resolver follows the NS delegation and queries the firewall through an active WAN link. The firewall returns the WAN address of the interface on which that query arrived, and the resolver passes this address to the client. The subsequent application access is a separate data flow. During validation, query both WAN paths separately and compare the returned addresses; after a link failure, issue a new DNS query. This does not remove already cached responses before their TTL expires.

Weight is the relative weight of the link compared with the other links in WAN link manager. It isn’t an application health check. During validation, new external DNS queries must only return active WAN addresses; then test a new application connection for every returned address. A DNS response 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.

According to Sophos, a DNAT rule and weighted load balancing can’t be configured simultaneously for the same DNS host entry. Publishing therefore 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.

A name remains cached as localhost for too long

For domains that resolve to localhost, Sophos Firewall doesn’t simply use the TTL in the DNS record. The firewall queries these names again at the localhost-ttl interval. The default is 655360 seconds, and the supported range is 60 to 655360 seconds. When a record changes from localhost to another host, the firewall can therefore retain the old answer longer than a normal client.

First use a direct query to the authoritative or intended resolver to confirm that the record no longer points to localhost. Then read the current SFOS value in the Device Console:

show dns

Only when this exact condition is confirmed should the global interval be reduced temporarily. 300 seconds is an example for a controlled migration test here, not a general recommendation:

set dns localhost-ttl 300

A lower value causes more frequent DNS queries and isn’t an immediate cache flush. After the change, test resolution again from the firewall and a real client. If the reduction was only needed for the migration, restore the product default afterwards:

set dns localhost-ttl default

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.

XML API: object name and DNS name from SFOS 23

For automation, Name and HostName are different fields: Name identifies the configured object, while HostName is the DNS name to resolve. The SFOS 23 documentation requires both fields when adding and editing an object. Name is a single STRING with a maximum of 64 characters; UTF-8 is permitted, but a comma is not. HostName remains DOMAINNAMELOOKUP with a maximum of 253 characters. For example, Name = app01-intern and HostName = app01.corp.example can have different values; this is a field mapping, not executable XML.

For deletion, SFOS 22 documents HostName as the key, whereas SFOS 23 documents Name. Do not therefore replay old SFOS 22 requests unchanged or automatically use the DNS name as the object name. Before a deletion call, check the installed version, read the specific object, and compare its object name, DNS name, addresses, and dependencies with the documented target. If the identity is ambiguous, stop. Afterwards, check the API response and status, and read back the exact target: only the intended object may be absent; other entries must remain unchanged. Transport success alone does not prove successful deletion. No deletion envelope is provided here, and no product test is claimed.

Unresolved reverse DNS conflict: In both versions, the API example shows Enable/Disable for AddReverseDNSLookUp, but the parameter table permits only Enable while also specifying Disable as the default. This does not establish a safe request using Disable or omitting the field. Until the vendor clarifies this, do not use such an API recipe; instead, deliberately configure reverse DNS through the WebAdmin procedure described above and check the PTR separately. The UI instructions do not confirm the API enum semantics.

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

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