FQDN and non FQDN

[BikeMan]

Hello team,

As a lot of us I am using Domain Object in my policies. As you know we can choose option FQDN or NOT.

What if an object is a domain (non-FQDN) and also a FQDN?

Version are 81.10 and 81.20.

Any idea ?

Thanks.

[CheckMatesAI]

This answer is provided by Infinity AI Copilot and should be confirmed by reviewing official documentation in Support Center.

When using Domain Objects in your policies with Check Point R81.10 and R81.20, you have the option to configure them in either FQDN (Fully Qualified Domain Name) mode or non-FQDN mode. Here's how each mode works:

• FQDN Mode: This mode matches traffic to the exact domain specified. For example, if you configure a domain object as .example.com, it will only match traffic to example.com and www.example.com. The Security Gateway performs a direct DNS query to resolve the domain and caches the IP addresses for up to 60 minutes, respecting the DNS TTL.

• Non-FQDN Mode: This mode matches traffic to the domain and its sub-domains (up to 10 levels). For example, .example.com would match ftp.example.com and support.example.com. The Security Gateway uses reverse DNS lookups to resolve the IP addresses, which can sometimes be less reliable due to potential DNS server limitations.

If an object is both a domain (non-FQDN) and an FQDN, you would need to decide which mode to use based on your specific needs. FQDN mode is generally more accurate and faster, while non-FQDN mode provides broader matching capabilities but may introduce latency due to reverse DNS lookups.

For more detailed information, you can refer to the R81.10 Security Management Administration Guide and the R81.20 Security Management Administration Guide.

[PhoneBoy]

Note that Domain objects ultimately need to be resolved to an IP address.

FQDN refers to a specific host only by DNS name. (e.g. community.checkpoint.com)
This can be resolved via a simple forward lookup, which in this case will be Cloudfront IPs.
The gateway does this for each non-FQDN object in the Access Policy periodically. 

For non-FQDN objects (which *.checkpoint.com can be matched), reverse DNS has to work.
It usually doesn't, especially for cloud-hosted objects (e.g. Cloudfront, which resolve to *.cloudfront.net).

If the firewall is in the path between the client and DNS server (i.e. the firewall can see the forward DNS lookup) the firewall can learn these IP/name associations via Passive DNS.
In the above example, if a client looked up community.checkpoint.com, the IPs returned by the DNS query would be recognized as being part of *.checkpoint.com.

In general, non-FQDN Domain Objects are not recommended.

[BikeMan]

Thanks for your answer.

To be sure about my understanding, according to the fact that we are using DNS Passiv Learning (dns request are crossing our fw):

Main fqdn: ftp.all.com

But sub domain:

super.ftp.all.com

admin.ftp.all.com

I would have to use ".ftp.all.com" as a Non-FQDN object.

Thanks,

[the_rock]

You got it! Something like below.

Andy

 

[PhoneBoy]

Correct.
It’s important that the clients and gateway use the same DNS server for forward DNS lookups.
Discrepancies in results from different DNS resolvers can create enforcement issues. 

[the_rock]

I believe best explanation would be in below sk.

Andy

https://support.checkpoint.com/results/sk/sk120633

[Wolfgang]

@BikeMan interesting question. From my experience I would ever avoid using none FQDN objects. It has a bad performance impact especially if something goes wrong with the reverse DNS requests or your DNS servers are not really fast. Passive learning helps only a little bit. If you need such objects place them at the end of your policy.

[the_rock]

I heard TAC say the same to customers before, though me personally, I had not noticed any issues with it, even for clients who use large numbers of non-fwdn domaon objects.

Andy

[Neil_Deane]

Hi all,

I noticed recently that the HCP report now contains references to Non-FQDN objects and highlights them with a warning and suggested solution to switch to well defined FQDNs.

Also I see in a recent JHFA a new kernel parameter to disable reverse-DNS, which should effectively disable non-FQDN functionality. 

It seems there's more significant concerns and implications around the usage of non-FQDNs in general.

My question is about Updateable Objects however. Many UO's contain wildcard domains. Does anyone know are these treated the same as non-FQDNs, requiring PTR record resolution for the wildcard to work ?

Thanks

[the_rock]

I believe they would be treated as such.

[PhoneBoy]

This is only relevant for non-FDQN domain objects where we explicitly set the expectation in the documentation that PTR records must exist.
I don't believe we've ever supported reverse DNS for Updatable Objects.
In this case, we can create domain/IP mapping from the SNI verification process as most of the traffic is HTTPS or use Passive DNS.

[Neil_Deane]

Thanks for replies.

Useful takeaways ...

UOs with wildcard domains don't impose the same system overheads as non-FQDNs because they don't require reverse-DNS.

The HCP report accurately omits wildcard domains contained in UOs from its analysis since they are not treated the same as non-FQDN objects.

Thanks guys