Use Sophos Firewall FQDN hosts and wildcard FQDNs correctly

FQDN hosts are useful when a destination cannot be described reliably with a fixed IP address. Typical examples are cloud services, update servers, authentication endpoints or vendor services whose IP addresses can change.

An FQDN host is not a replacement for a web policy, not full URL control and not a guarantee that every application will match cleanly. The important question is how Sophos Firewall resolves the name or, for wildcards, learns it from DNS traffic.

When FQDN hosts make sense

FQDN hosts fit rules where a technical destination is better described by a DNS name than by individual IP addresses. This is especially useful for outbound traffic.

Useful examples:

An internal server may only connect to updates.vendor.example.
An application needs access to a few known vendor FQDNs.
A specific cloud endpoint must be used in a firewall rule, NAT rule, SD-WAN route or VPN configuration.
A troubleshooting case must show whether a rule matches the expected name or an unexpected IP address.

FQDN hosts are less suitable for broad web access such as “everything under one SaaS service” when the application uses many domains, CDNs, APIs, telemetry and login endpoints. For web traffic, web policies, URL groups, DNS Protection, Application Control or TLS Inspection are often the better control layer.

Sophos Firewall can use FQDN hosts not only in firewall rules, but also in settings such as SD-WAN policy routes, VPN settings, and technical host objects for mail, proxy, DNS, authentication, remote access, web, or syslog servers. Still, check each use case to confirm whether a DNS name is really more stable than an IP object or a dedicated policy layer.

For the firewall rule itself, start with understanding and configuring Sophos Firewall rules securely. If a rule does not match, use Sophos Firewall rule not matching: check the causes.

Normal FQDN host or wildcard FQDN

Sophos Firewall handles normal FQDN hosts and wildcard FQDNs differently. This is the most important operational detail.

Normal FQDN host

For a normal FQDN host, such as updates.vendor.example, the firewall resolves the name through DNS. The returned IP addresses are used for the object. If the DNS record has a TTL, the firewall refreshes the resolution after that TTL expires.

An important IPv6 limit applies to SFOS 22: FQDN host objects do not resolve IPv6 addresses. This does not prevent DNS Lookup or normal clients from receiving AAAA responses, but the object itself does not maintain these IPv6 destinations. Sophos Firewall IPv6 support and limitations in SFOS 22 distinguishes this from the other supported and unsupported functions.

This works well when:

the FQDN points directly to the required IP addresses,
the application uses exactly that name,
the DNS responses do not constantly switch between many CDN targets,
the test uses the same name resolution that the firewall sees.

Wildcard FQDN

For a wildcard FQDN, such as *.example.com, the firewall does not simply resolve “all possible subdomains”. DNS does not provide a complete list of all subdomains.

Instead, the firewall learns matching IP addresses from DNS responses. To do so, it must see the matching responses; for transit DNS, learn-subdomains must also be enabled. Visible DNS traffic alone does not guarantee successful learning. The documented learning paths are:

Sophos Firewall is the DNS server for the clients.
Or DNS traffic passes through the firewall and is detected by DPI.
According to Sophos, this learning applies to UDP DNS traffic on port 53 to external DNS servers.

If clients use DNS-over-HTTPS, DNS-over-TLS, another DNS path or a local resolver, the firewall may not see the relevant DNS responses. A wildcard FQDN can then remain empty or incomplete even though the domain works in the browser.

Create an FQDN host

The menu path is:

Hosts and services > FQDN host > Add

Only a few fields matter for a clean object:

Name: descriptive and technically stable, for example fqdn_vendor_updates or wfqdn_example_subdomains.
FQDN: the full name, for example updates.vendor.example or *.example.com.
FQDN host group: optionally select an existing group or create a new group. An FQDN host can belong to multiple FQDN host groups.
Spelling: write FQDNs in lowercase. Sophos states that uppercase letters in FQDN hosts are not supported.

After entering the fields, save the object with Save.

After saving, do not immediately place the object blindly into production rules. Run a short test first: does the firewall resolve the name, does the Log Viewer later show the expected destination IP, and does this IP match the client DNS response?

Use multiple FQDN hosts as a group

An FQDN host group combines several existing FQDN hosts into one reusable object. Groups can be selected in firewall rules and SD-WAN policy routes, among other places.

Go to Hosts and services > FQDN host group > Add. Enter a unique label under Name, select the required hosts, and click Save. For an application with separate endpoints, the group grp_vendor_service could contain login.vendor.example, api.vendor.example, and updates.vendor.example. A host can belong to more than one group. Include only required names because each additional host expands every rule that uses the group.

The FQDN host and FQDN host group lists can be searched by any displayed attribute. Before changing or deleting an object, separately check which firewall rules, SD-WAN policy routes, or other configurations use it. A shared-group change affects all of those uses.

Use in firewall rules

In most designs, an FQDN host belongs in outbound rules under Destination networks. The rule then describes which internal sources may connect to which dynamic destination.

Typical flow:

Create the FQDN object under Hosts and services > FQDN host.
Open or create the matching rule under Rules and policies > Firewall rules.
Define Source zones and Source networks and devices narrowly.
Choose Destination zones deliberately, usually WAN.
Select the FQDN object under Destination networks.
Allow only the required ports under Services, for example HTTPS.
Enable logging.
Run a real test and check Rule ID, Destination IP, NAT Rule ID and service in the Log Viewer.

An FQDN host does not make a rule secure by itself. If Source is Any, Service is Any and Destination is a broad wildcard object, the result can quickly become very open. A small rule with clear source, clear service, active logging and documented purpose is better.

Special case: preconfigured groups for web proxy rules

The preconfigured SafeSearch enforcement, YouTube restrictions enforcement, and Google app enforcement groups are intended only for rules that enforce SafeSearch, YouTube restrictions, or Google Workspace sign-ins through the web proxy. They do not replace a custom list of general SaaS destinations.

Before enabling such a rule, ensure that the devices in a pilot group trust the CA, define suitable decryption exclusions, and prepare specific HTTP and HTTPS acceptance tests. Roll out Sophos Firewall TLS inspection step by step covers that process.

In the dedicated firewall rule, set Action to Allow and Destination zones to WAN. Select the required preconfigured groups under Destination networks, and HTTP and HTTPS under Services. Also enable Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine, and Decrypt HTTPS during web proxy filtering. Place the rule above rules that process the same traffic with the DPI engine.

After the test, use the Log Viewer and a browser to confirm that only the intended pilot group uses this rule and that the required restriction works. To roll back, disable the new proxy rule and verify that traffic is again processed by the DPI rule below it. Delete the proxy rule only after confirming that state.

Limits and pitfalls

Many FQDN problems do not come from the rule list, but from the DNS behavior of clients or applications.

The firewall sees different DNS responses

If client and firewall use different DNS resolvers, they can receive different IP addresses for the same name. This is normal with CDNs. A rule may then match one IP while the client uses another.

When troubleshooting, compare:

Which IP does nslookup or dig return on the client?
Which Destination IP appears in the Log Viewer?
Which DNS servers do the client and firewall use?
Is DNS using port 53, DNS-over-HTTPS or DNS-over-TLS?

Wildcard FQDN learns nothing

A wildcard FQDN only works if the firewall sees the matching DNS responses. If a client uses DoH in the browser or a DNS path that does not pass through the firewall, the firewall cannot learn the subdomains. For DNS traffic that only passes through the firewall, also check whether learn-subdomains is enabled. This is an additional prerequisite, not a guarantee of success.

In these cases, moving the firewall rule is not the fix. Decide on the DNS design instead: use the firewall as DNS forwarder, route DNS traffic through the firewall in a controlled way, or use another control layer for web traffic.

The FQDN is too broad

A wildcard such as *.example.com can include much more than intended. Modern SaaS services use login domains, API domains, media CDNs, telemetry, support services and third parties. Sometimes a single wildcard object is too coarse.

If the access must be broad by design, a web policy, URL group or Application Control is often easier to understand and review than a very large FQDN firewall rule.

Multiple domains point to the same IP

Sophos explicitly documents that FQDN hosts do not support multiple domains that resolve to the same IP address. An FQDN object works with the resolved IP addresses and cannot distinguish such domains from one another at the IP layer. Reliable separation of these domains must therefore not be expected.

For domain-based web decisions, the web layer is therefore more suitable than a pure IP-based firewall rule with an FQDN object.

Troubleshooting

If an FQDN rule does not behave as expected, first check the real connection. The name in the object is not decisive; the IP address used at the moment of the test is.

Rule does not match

Check:

Does the Source Zone match?
Does the Source IP or source network match?
Does the service match, for example TCP 443 instead of only HTTP?
Does the Log Viewer show another Rule ID?
Does the Log Viewer show a Destination IP that does not match the current DNS response?
Is a more general rule active above the FQDN rule?

If the Log Viewer shows another rule, rule order matters more than the FQDN object. If the Log Viewer shows nothing, traffic not reaching the firewall or inactive logging are possible causes, but not the only ones. Also check the selected module and the time, field and search filters. Firewall rule sessions are logged only when the connection closes with a received Destroy event; if the connection closes without this event, the session log may be missing. A connection that is still open must therefore also be considered. Use a targeted packet capture to check whether the test packets reach the firewall; an empty Log Viewer alone does not prove that they do not.

Wildcard FQDN remains empty

Check:

Does the client use the firewall as DNS server?
Is DNS visible through the firewall?
Does the client use DoH or DoT?
Is UDP 53 used?
Is learn-subdomains enabled for transit DNS? Visible DNS responses alone do not guarantee a learned binding.
Is there a DNS request route or internal resolver hiding the response before the firewall sees it?

If DNS is intentionally routed internally, configure DNS request routes on Sophos Firewall helps with the DNS design.

DNS changed, rule reacts later

FQDN objects work with DNS responses and caches. If a vendor destination changes, there can be a delay until the firewall uses the new state. For normal FQDN hosts, the TTL of the DNS record is decisive.

In the Device Console, Sophos provides the system-wide set fqdn-host command family; it does not change only one selected host object. cache-ttl uses dns-reply-ttl by default or can be set from 60 to 86400 seconds. idle-timeout removes unused bindings after a configurable interval of 60 to 86400 seconds; the default is 3600 seconds. eviction controls whether and after which interval learned IP addresses for wildcard subdomains are removed; the interval ranges from 60 to 86400 seconds. learn-subdomains enables or disables learning these addresses from transit traffic that passes through the firewall but neither originates from nor is destined for it. When cache-ttl is changed, the new value only applies to newly resolved entries; already cached entries keep their existing value until they expire.

Do not change these values as a first reaction. First check whether the DNS design, resolver path, and rule base are correct. Before a change, record all current values, change only one parameter at a time, and test its effect with newly resolved entries. The rollback value is the recorded original value; for the default TTL it is dns-reply-ttl. Tuning belongs in a documented operations or support procedure.

Operational recommendation

FQDN hosts stay manageable when they are treated as technical dependencies, not spontaneous exceptions.

Good practice:

Document a clear purpose for each FQDN object.
Use wildcards sparingly.
Combine FQDN objects with narrow source and service definitions.
Enable logging for new or critical rules.
Test changes with Log Viewer and DNS lookup.
Do not hide broad web access in a large FQDN rule.
For SaaS or cloud services, regularly check whether the vendor requires additional domains.

The CLI documentation states up to 16,000 FQDN hosts. For SFOS 22, however, Sophos documents a combined limit of 16,000 hosts across all host types; this must not be taken to imply additional, independent FQDN capacity or free headroom. This limit is not an invitation to uncontrolled growth. Many old FQDN exceptions make reviews, troubleshooting, and rule maintenance harder. A smaller, documented object list with owner, purpose, and review date is better.

If an object was created only because “an application otherwise does not work”, review it later. These emergency objects often become permanent exceptions that are hard to explain.

FAQ

What is the difference between an FQDN host and an IP host?

An IP host describes a fixed address or network. An FQDN host describes a DNS name whose current IP addresses the firewall can use. This helps with dynamic destinations, but depends on DNS resolution and cache behavior.

Does `*.example.com` automatically work for all subdomains?

Not as a complete domain list. The firewall must see matching DNS responses and learn IP addresses from them. If DNS is not visible through the firewall, a wildcard FQDN can remain incomplete.

Why does my FQDN rule not match?

Usually the rule context, order or actually used destination IP does not match. In the Log Viewer, check which Rule ID, Destination IP, Destination Port and NAT Rule ID appear during the real test.

Do FQDN hosts work with DNS-over-HTTPS or DNS-over-TLS?

Wildcard FQDNs are problematic when clients use DoH or DoT and the firewall cannot see the DNS responses. The firewall then cannot reliably learn the required subdomains.

Should FQDN hosts be used for web filtering?

Only selectively. For real web control, web policies, URL groups, DNS Protection, Application Control or TLS Inspection are usually more suitable. FQDN hosts are useful for technical destinations in network rules, but they are not a full URL policy.