- CheckMates
- :
- Products
- :
- General Topics
- :
- FQDN and non FQDN
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FQDN and non FQDN
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 toexample.com
andwww.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 matchftp.example.com
andsupport.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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You got it! Something like below.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe best explanation would be in below sk.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
