FQDN Based Firewall Objects

This article describes why and how Admins can use Fully Qualified Domain Name (FQDN) based objects to allow for more flexibility with Firewall configurations while allowing for more granular access to resources. As many popular services utilize dynamic IPs to access their resources, some addresses may be changed over time. Admins can use FQDN objects to more easily create policies for services that use multiple dynamic IPs while leveraging DNS to reduce the need for manually changing addresses in firewall rules when those IPs eventually change. Please view our Objects article for more information on creating objects in your Harmony SASE console. 

FQDN Wildcards:

FQDN objects allow admins to include multiple subdomains in a single FQDN entry using wildcards to configure policies for domains with many subdomains more easily. The syntax of the wildcard entry should be as follows:

*.example.com

The above wildcard would include subdomains such as support.example.com and sales.example.com but would not have the root domain example.com. Admins wishing to block the root domain would need to create a second entry, for example.com

Multi-Level Subdomains:

FQDN Objects support multi-level subdomains, up to 5 levels. For example:

one.two.three.four.five.example.com 

Important Considerations:

The firewall will support a total of 100 FQDN objects. For example:

• One FQDN object per rule, across 100x rules, or:
• 100x FQDN objects contained in a single rule.

Additionally, FQDN objects can contain a maximum of 1000 domains per account. For example: 

• Ten FQDN objects containing 100x domains, or:
• 100x FQDN objects containing ten domains each.

Limitations:

• FQDN firewall rules may be bypassed by using an IP.
• CDN is not permitted, only FQDN.
• If you have two or more FQDNs sharing the same IP, both will be affected by the Firewall rule. (For example, if you block one FQDN, another resource sharing the same IP will also be blocked)
• Limited compatibility with services supported by multiple FQDN (e.g., websites)
• No compatibility with DNS load balancers since they return different IPs for each query.
• The browser and local DNS cache take priority over FQDN Firewall rules
• No compatibility with 3rd party DNS services, e.g., DoH - (An admin must enforce user VPN interface DNS)