topic Re: FQDN and non FQDN in General Topics

FQDN and non FQDN

BikeMan — Tue, 17 Dec 2024 13:17:20 GMT

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.

FQDN and non FQDN

CheckMatesAI — Tue, 17 Dec 2024 13:50:08 GMT

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.

Re: FQDN and non FQDN

PhoneBoy — Tue, 17 Dec 2024 14:08:09 GMT

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.

Re: FQDN and non FQDN

the_rock — Tue, 17 Dec 2024 14:33:01 GMT

I believe best explanation would be in below sk.

Andy

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

Re: FQDN and non FQDN

BikeMan — Tue, 17 Dec 2024 15:00:34 GMT

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,

Re: FQDN and non FQDN

the_rock — Tue, 17 Dec 2024 15:03:45 GMT

You got it! Something like below.

Andy

Re: FQDN and non FQDN

PhoneBoy — Tue, 17 Dec 2024 16:02:55 GMT

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.

Re: FQDN and non FQDN

Wolfgang — Tue, 17 Dec 2024 18:25:57 GMT

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

Re: FQDN and non FQDN

the_rock — Tue, 17 Dec 2024 18:41:30 GMT

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

Re: FQDN and non FQDN

Neil_Deane — Mon, 10 Nov 2025 18:40:18 GMT

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

Re: FQDN and non FQDN

the_rock — Mon, 10 Nov 2025 18:51:29 GMT

I believe they would be treated as such.

Re: FQDN and non FQDN

PhoneBoy — Tue, 11 Nov 2025 02:17:06 GMT

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.

Re: FQDN and non FQDN

Neil_Deane — Tue, 11 Nov 2025 11:14:54 GMT

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