topic Using DNS FQDN for object names in policy creation in Firewall and Security Management

Using DNS FQDN for object names in policy creation

Chandhrasekar_S — Mon, 13 Nov 2017 17:25:19 GMT

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

Re: Using DNS FQDN for object names in policy creation

grandpafirewall — Mon, 13 Nov 2017 18:49:41 GMT

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

Dor_Marcovitch — Mon, 13 Nov 2017 19:12:31 GMT

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

Re: Using DNS FQDN for object names in policy creation

grandpafirewall — Mon, 13 Nov 2017 19:17:41 GMT

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

Re: Using DNS FQDN for object names in policy creation

Chandhrasekar_S — Mon, 13 Nov 2017 20:33:09 GMT

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

Re: Using DNS FQDN for object names in policy creation

PhoneBoy — Mon, 13 Nov 2017 23:06:35 GMT

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

Kirk_Vaughan — Thu, 23 Nov 2017 17:33:23 GMT

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.

Re: Using DNS FQDN for object names in policy creation

PhoneBoy — Thu, 23 Nov 2017 19:49:22 GMT

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.

Re: Using DNS FQDN for object names in policy creation

grandpafirewall — Fri, 24 Nov 2017 06:28:02 GMT

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)

Re: Using DNS FQDN for object names in policy creation

Leandro_Nicolet — Mon, 12 Nov 2018 11:41:04 GMT

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

Frederic_Kasmir — Wed, 06 Feb 2019 10:16:29 GMT

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

Re: Using DNS FQDN for object names in policy creation

PhoneBoy — Fri, 21 Jun 2019 09:01:54 GMT

Think such a command is listed here: https://community.checkpoint.com/docs/DOC-3476-domain-objects-fqdn-an-unofficial-atrg

Re: Using DNS FQDN for object names in policy creation

Suresh_Shah — Wed, 28 Sep 2022 07:58:33 GMT

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."