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.

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. This works reliably when the firewall can see the DNS traffic:

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

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.

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 points out that FQDN hosts are not intended to cleanly distinguish multiple domains when they resolve to the same IP address. On the IP layer, the firewall cannot always know which domain an application later uses.

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, the traffic does not reach the firewall or logging is not active.

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

Sophos offers CLI options for FQDN hosts, including cache-ttl, idle-timeout, eviction, and learn-subdomains. cache-ttl can use the TTL from the DNS response or a value between 60 and 86400 seconds. idle-timeout removes unused bindings after 3600 seconds by default. eviction controls when learned IP addresses from wildcard subdomains are removed. 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. 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.

Sophos states a limit of up to 16,000 FQDN hosts, but this 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.