# Domain Objects in versions R80.10 and higher ## Solution ## (1) Introduction to Domain objects A Domain Object allows you to specify a domain name for matching in the Access Control rule base. You can use it in the **Source** and **Destination** columns of the Access Control Policy. ## (2) Working with Domain objects **Part 1 - Configure a new Domain Object** 1. In SmartConsole, in the top right corner, click the **Objects** panel. 2. Click **New** \> **More** \> **Network Object** \> **More** \> **Domain**. 3. Enter the applicable domain. The format depends on the mode - see below. 4. Optional: Enter the applicable comment. 5. Configure the Domain object mode: | | | | | | --- | --- | --- | --- | | "FQDN" Checkbox | Mode Description | Security Gateway Behavior | Notes | | Selected | Enables the FQFN mode that enforces only the specified the Domain.
In the object name, you must enter the domain in this format: `.x.y.z`
For example, if you entered `.www.example.com`, then the Security Gateway matches only `www.example.com`
For example, if you entered `.checkpoint.com`, then the Security Gateway can match only `checkpoint.com`
No need to use the asterisk character "`*`" in the object name. | The Security Gateway:
1. Performs a direct DNS query to resolve the FQDN.
2. Saves the returned IP addresses in a cache.
3. Uses the returned IP addresses to match traffic to the corresponding rule. | The FQDN mode is supported on Security Gateways R80.10 and higher.
The FQDN mode is more accurate and faster than the non-FQDN mode.
The FQDN mode supports SecureXL Accept templates.
Using Domain objects with the FQDN mode enabled in a rule has no effect on the performance of the rule, or on the rules located below it. | | Cleared | Enables the non-FQFN mode that enforces the specified Domain and its Sub-Domains.
In the object name, you must enter the domain in this format: `.x.y`
For example, enter `.example.com` or `.example.co.uk`
For example, if you entered `.example.com`, then the Security Gateway can match `www.example.com` and `support.example.com` | The Security Gateway:
1. Performs a DNS reverse lookup to resolve the domain.
2. Saves the returned IP addresses in a cache.
3. Uses the returned IP addresses to match traffic to the corresponding rule. | The DNS reverse lookups can be inaccurate. | 6. Click **OK**. **Part 2 - Configure the Access Control rules** 1. In SmartConsole, from the left navigation panel, click **Security Policies**. 2. In the top panel, click **Access Control** \> **Policy**. 3. Add a new rule or edit an existing rule. 4. Add the required Domain object it in the **Source** or the **Destination** column of the applicable rule. 5. Install the Access Control policy. ### FQDN Mode > In the FQDN Mode, the Security Gateway matches only traffic to the exact specified domain. > > The timeout of the FQDN cache respects the TTL of the DNS. The default TTL of the internal cache entry is 1 hour (60 minutes). > > No DNS reverse lookup is performed. > > Changes in Gaia DNS servers are implemented only after you run the "`cpstop ; cpstart`" commands or reboot the Security Gateway. If not, the Security Gateway continues to use the DNS servers that were configured at startup. ### Non-FQDN Mode > In the Non-FQDN Mode, the Security Gateway matches traffic to the domain and its sub-domains (up to 10 levels). > > **Note:** Keep rules with non-FQDN Domain objects as low in the Access Control rulebase, as possible. > > Non-FQDN Domain objects may match correctly when configured in environments with DNS traffic passing through the Security Gateway, and DNS Passive Learning enabled. For details, refer to [sk161612](https://support.checkpoint.com/results/sk/sk161612). > > Example: > > > In the rule below, the Domain object "`.example.com`" is configured as a non-FQDN object: > > > > > > > > To potentially match this rule, the destination IP address of the connection must be resolved through a reverse DNS lookup. > > > > Let us assume, your client accessed "`ftp.example.com`". > > > > Your client resolves this domain to the IP address "`192.0.2.21`". > > > > This is the first applicable rule for the connection. > > > > The Security Gateway looks up `21.2.0.192.in-addr.arpa` via DNS. > > > > - If this lookup returns "`example.com`" (or a sub-domain), traffic to that IP address is matched as part of "`.example.com`". > > - If the lookup returns "`NXDOMAIN`" or anything else, traffic to that IP address is not matched as part of "`.example.com`". > > **Disabling DNS reverse lookups:** > > > Some DNS servers do not support DNS reverse lookups or might not be fully updated with all reverse entries. > > > > You can disable the reverse lookups and make Non-FQDN objects work only based on DNS Passive Learning. > > > > This greatly improves performance and reduces the amount of DNS queries sent to the Security Gateways configured as DNS servers. > > > > This functionality is supported in (PRHF-37100): > > > > - [R82 Jumbo Hotfix Accumulator](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/Default.htm) Take 25 and higher > > - [R81.20 Jumbo Hotfix Accumulator](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) Take 99 and higher > > - [R81.10 Jumbo Hotfix Accumulator Take](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/Default.htm) 177 and higher > > > > Procedure: > > > > You can control the Security Gateway behavior with the kernel parameter " **domo_reverse_lookup_disabled**": > > > > | | | > > > | --- | --- | > > > | Kernel Parameter Value | Security Gateway Behavior | > > > | `domo_reverse_lookup_disabled = 0` | The Security Gateway uses reverse DNS lookups.
This is the default. | > > > | `domo_reverse_lookup_disabled = 1` | The Security Gateway does not use reverse DNS lookups and relies only on DNS Passive Learning. | > > > | > > > You can **configure** the applicable value for this kernel parameter temporarily (in the current session only - does not survive reboot), or permanently (survives reboot). > > > **Important** \- In ClusterXL, you must configure all cluster members in the same way. > > > | > > > | | | | > > > | --- | --- | --- | > > > | Deployment | Temporary Configuration | Permanent Configuration | > > > | Security Gateway,
ClusterXL | In Gaia Clish, or in the Expert mode:
`fw ctl set int domo_reverse_lookup_disabled ` | In Gaia Clish, or in the Expert mode:
`fw ctl set -f int domo_reverse_lookup_disabled ` | > > > | Security Group in ElasticXL,
Security Group in Maestro,
Security Group on Scalable Chassis | In Gaia gClish:
`fw ctl set int domo_reverse_lookup_disabled `
In the Expert mode:
`g_fw ctl set int domo_reverse_lookup_disabled ` | In Gaia gClish:
`fw ctl set -f int domo_reverse_lookup_disabled `
In the Expert mode:
`g_update_conf_file $FWDIR/modules/fwkern.conf domo_reverse_lookup_disabled=` | > > > | > > > To **see** the current value of this kernel parameter, run: > > > | > > > | | | > > > | --- | --- | > > > | Deployment | Command | > > > | Security Gateway,
ClusterXL | In Gaia Clish, or in the Expert mode:
`fw ctl get int domo_reverse_lookup_disabled` | > > > | Security Group in ElasticXL,
Security Group in Maestro,
Security Group on Scalable Chassis | In Gaia gClish:
`fw ctl get int domo_reverse_lookup_disabled`
In the Expert mode:
`g_fw ctl get int domo_reverse_lookup_disabled` | > > **Upgrading from versions R77.30 and lower to versions R80.10 and higher:** > > > When upgrading from versions R77.30 and lower, the existing Domain objects are configured in the Non-FQDN mode. ## (3) Acceleration of traffic for Domain objects > Starting from R80.10, Domain objects in the Access Control policy do **not** disable SecureXL Accept Templates anymore and support Templates Acceleration. Hence, Domain objects can be used in upper rules in the security policy with no performance impact. > > For more information, see [sk32578 - SecureXL Mechanism](https://support.checkpoint.com/results/sk/sk32578).