In very simple terms, a Domain Object attempts to make an association between a DNS name and an IP address.
- An FQDN Domain Object translates the FQDN to an IP address.
- A non-FQDN Domain Object confirms that an IP address is associated with a given domain by doing a reverse DNS lookup
You can use a Domain Object in the rulebase similar to a host object that represents a single IP address.
As such, it can be used in a pure firewall rulebase without App Control or other advanced blades as it doesn't require any Layer 7 inspection.
The (reverse) DNS resolution effectively happens "out of band."
This approach has a couple limitations:
- These objects only work with IPv4, if I remember correctly.
- Many sites actually share the same IPv4 address and you'd be allowing (or blocking) all of those sites if you use these objects in a rule.
- Non-FQDN Domain Objects incur a fairly significant performance penalty and, in the end, usually doesn't work as the reverse DNS rarely matches the DNS name you're trying to match (if such records even exist at all).
An Application/Site is effectively an App Control signature that operates at Layer 7.
It's a fairly simplistic App Control signature that identifies that traffic is:
- Web-based (i.e. regular HTTP or HTTPS)
- Is destined to one of the domains you've listed in the definition.
If the traffic is not web-based and/or App Control can't determine it's destined for one of the domains listed, then it will not match the traffic.
There are reasons that both approaches are available.
You have to use the one that is appropriate for the problem you're trying to solve.
The more information you can provide about your environment and precisely what your goal is, the more likely we can tell you what approach will work best.