Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Chandhrasekar_S
Collaborator
Jump to solution

Using DNS FQDN for object names in policy creation

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
grandpafirewall
Collaborator

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.

View solution in original post

12 Replies
grandpafirewall
Collaborator

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.

Dor_Marcovitch
Advisor

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
grandpafirewall
Collaborator

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
Chandhrasekar_S
Collaborator

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

0 Kudos
PhoneBoy
Admin
Admin

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
Suresh_Shah
Employee
Employee

What does it mean by (up to 10 levels) described in sk120633 in below sentence? any example to refer for it .

"When FQDN mode is unchecked, traffic to the domain and its sub-domains (up to 10 levels) is matched on the rule using the non-FQDN Domain object."

0 Kudos
Kirk_Vaughan
Explorer

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
PhoneBoy
Admin
Admin

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
grandpafirewall
Collaborator

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
Leandro_Nicolet
Contributor

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 ?

Frederic_Kasmir
Participant

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
PhoneBoy
Admin
Admin
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events