cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post

Using DNS FQDN for object names in policy creation

Jump to solution

Team can you please let me know, how to use DNS FQDN for object names in policy creation. What are the advantages and disadvantages and any things I need to take into consideration before deploying them.

Thanks

Chandru

1 Solution

Accepted Solutions
Employee+
Employee+

Re: Using DNS FQDN for object names in policy creation

Jump to solution

In R80.10 there are now two modes: FQDN and non-FQDN:

FQDN:

If using FQDN mode (R80.10), the traffic will only match the exact domain.  For example:  If you defined checkpoint.com, then ONLY checkpoint.com will be matched, traffic that is community.checkpoint.com will NOT be matched.    This is supported in R80.10 and is the default and recommended option.

non-FQDN:

If FQDN is unchecked, then traffic to the domain and subdomains are matched.  So using the example above, if checkpoint.com is defined, then both checkpoint.com and community.checkpoint.com will be matched

DNS reverse lookup is used if the IP addressed is not cached.  So the DNS server will need to support reverse lookup.

In R80.10, domain objects do not disable SecureXL templates, so there is support for template acceleration.  In previous releases, the order of the rules using domain objects will impact how SecureXL is used.

11 Replies
Employee+
Employee+

Re: Using DNS FQDN for object names in policy creation

Jump to solution

In R80.10 there are now two modes: FQDN and non-FQDN:

FQDN:

If using FQDN mode (R80.10), the traffic will only match the exact domain.  For example:  If you defined checkpoint.com, then ONLY checkpoint.com will be matched, traffic that is community.checkpoint.com will NOT be matched.    This is supported in R80.10 and is the default and recommended option.

non-FQDN:

If FQDN is unchecked, then traffic to the domain and subdomains are matched.  So using the example above, if checkpoint.com is defined, then both checkpoint.com and community.checkpoint.com will be matched

DNS reverse lookup is used if the IP addressed is not cached.  So the DNS server will need to support reverse lookup.

In R80.10, domain objects do not disable SecureXL templates, so there is support for template acceleration.  In previous releases, the order of the rules using domain objects will impact how SecureXL is used.

Re: Using DNS FQDN for object names in policy creation

Jump to solution

There was a long discusstiob about this issue.

This example is not always true "  For example:  If you defined checkpoint.com, then ONLY checkpoint.com will be matched, traffic that is community.checkpoint.com will NOT be matched."

The website might still be hosted under the same ip.

For example server that host both google.com and checkpoint.com on the same ip. Using fqdn object to allow google.com will also allow checkpoint.com

0 Kudos
Employee+
Employee+

Re: Using DNS FQDN for object names in policy creation

Jump to solution

Correct.  I should have clarified that.  If community.checkpoint.com and checkpoint.com are not the same IP address. Thanks for clarifying that.

0 Kudos

Re: Using DNS FQDN for object names in policy creation

Jump to solution

Thanks All. Just wondering where should I select the mode - FQDN and non-FQDN

0 Kudos
Admin
Admin

Re: Using DNS FQDN for object names in policy creation

Jump to solution

The TL;DR is:

  • If gateway is lower version than R80.10, you must select non-FQDN.
  • If gateway is R80.10 and above, use FQDN

Re: Using DNS FQDN for object names in policy creation

Jump to solution

Use extreme caution when deploying domain objects in your rule base. We added a domain object to our blacklist rule and it took down one of our data centers. Our diamond engineer said:

"I did some research and asked internally. 
so there is a timeout for Domain Object - it would be related to how long it would take for a DNS request to fail/timeout.

Which is likely only configure for a couple seconds, but what would cause the slow response as every connection going to this gateway is be queued and going though this and why we eventually were able to connect to the gateway.

every connection going to the firewall would need to be queued and attempt the dns request before it got proceed to the next rule."

He also said the Check Point recommends that you use domain objects only if absolutely necessary. 

0 Kudos
Admin
Admin

Re: Using DNS FQDN for object names in policy creation

Jump to solution

This is relevant for non-FQDN Domain Objects and has been the case for a while.

For FQDN, the DNS lookup process should be non-blocking.

0 Kudos
Employee+
Employee+

Re: Using DNS FQDN for object names in policy creation

Jump to solution

Pre-R80.10, domain objects used only non-FQDN.  This basically means if a DNS lookup is required almost every time.  A domain defined as checkpoint.com might have a different IP as www.checkpoint.com, community.checkpoint.com, ftp.checkpoint.com, etc... (Ref:  sk90401)  The enforcement point is at the mercy of DNS server latency.   (I'm summarizing here to get to my point).  You are correct in saying to use extreme caution because you need to understand what you are using and the technology behind it.  R80.10 implementation is different than previous releases.  (Ref:  sk41632 and sk120633) 

0 Kudos

Re: Using DNS FQDN for object names in policy creation

Jump to solution

Has anyone used FQDN objects in a VSX environment on R80.10 ? Trying to determine what ip actually performs the lookup for a VS. Would it be the domain (cma) ip or the chassis ip itself ?

Re: Using DNS FQDN for object names in policy creation

Jump to solution

Hello Guys,

Is there a way to track the current resolution of the FQDN object? For instance an CLI command showing something like:

CNAME, class IN, cname googleapis.l.google.com type A, class IN, addr 172.217.23.10 type A, class IN, addr 216.58.198.234 type A, class IN, addr 216.58.212.74 type A, class IN, addr 216.58.201.42 type A, class IN, addr 216.58.208.138 type A, class IN, addr 216.58.201.10 type A, class IN, addr 216.58.198.170 type A, class IN, addr 216.58.212.106 type A, class IN, addr 216.58.210.42 type A, class IN, addr 216.58.206.74 type A, class IN, addr 216.58.206.138 type A, class IN, addr 216.58.204.42 type A, class IN, addr 216.58.204.74 type A, class IN, addr 172.217.23.42 type A, class IN, addr 216.58.206.106 type A, class IN, addr 216.58.214.10

Thanks.

Best regards

0 Kudos
Admin
Admin

Re: Using DNS FQDN for object names in policy creation

Jump to solution
0 Kudos