- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Dear CP,
according to your sk120633 (Domain-Objects) the Non-FQDN mode "... uses DNS reverse lookup (if the IP address is not already in cache)."
There is a example where you state that a Non-FQDN-object with
would also match
(as stated by reverse-looking up the IP)
Therefor I resolved both (using dig):
So the client will, for example resolve the domains and get the above IP's.
The package arriving at the Firewall with the ".checkpoint.com" FQDN-object will now try to resolve these IP's, therefor:
Did I understand the procedure/technic correct? If yes, how should the FW be able to determine that these IP's are belonging to ".checkpoint.com" if it is either a NX-entry or plenty completely different entries?
Thanks for your help and best regards
Linus
Neither of the above IPs would be considered part of *.checkpoint.com.
Specifically because the reverse DNS of those IPs do not resolve to something related to *.checkpoint.com.
This is why we added the new method for domain objects in R80.10+.
The sk120633 decribes this procedure within R80.10+ and was referenced above. Is there a completely new method or did I missunderstand you?
You're describing the technique correctly.
dig is a "forward" lookup tool, meaning it takes a name and turns it into an IP address.
IP address to name mapping doesn't have to match.
And, in fact, if the IP address is part of a CDN, a cloud provider, or something else, it may not match.
So, for example, when a connection to 209.87.209.88 hits a rule destined for *.checkpoint.com, we look up 88.209.87.209.in-addr.arpa.
As that results in an NXDOMAIN response, that IP will never be considered part of *.checkpoint.com.
I've used dig with the <-x> parmeter what enables the mentioned reverse resolution to get the PTR RR to a given IP. I think it would be a good idea to change the sk's example to one that works (with given subdomains that are all resolved to one IP which again is resolvable to the domain itself).
Otherwise people reading this sk get confused if they are trying to figure out function & limitations of this technique while comprehending the given example.
I recommend leaving feedback on the SK to that effect.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY