The difference between checkpoint creation domain and Custom Applications/Sites creation URL

[Wang]

Hello, engineers, I would like to know the workflow difference between creating domain and Custom Applications/Sites to create urls

[Maarten_Sjouw]

A Custom Application/Site can only be used in an Application policy and column, where the get url command is compared to the URL in the custom Application.
A domain object is used in a source or destination field where the gateway does a resolution of the domain name to IP addresses and then looks if the IP hitting the gateway is in the domain resolution list.

[Wang]

Okay, thank you very much. Is there an official document describing this problem?

[Maarten_Sjouw]

this is not really a problem, these are just completely different approaches of how to allow something, the one is handled by the FW blade and the other by the URLF blade.

[Wang]

For example, I want to visit ".checkpoint.com" to use the Domain for configuration or the Custom Applications/Sites creation URL？

[Wang]

For example, I want to visit ".checkpoint.com" to use the Domain for configuration or the Custom Applications/Sites creation URL？

[PhoneBoy]

If it is only the site checkpoint.com (and not www.checkpoint.com or somethingelse.checkpoint.com), then you can use a FQDN Domain Object, as that works on being able to resolve checkpoint.com to an IP address.
Non-FQDN Domain Objects rely on being able to reverse-resolve the IP address being accessed to a name that has checkpoint.com in it.
This rarely works in the modern Internet.

The App Control approach works for HTTP/HTTPS traffic.
For HTTPS sites, Categorize HTTPS Sites needs to be enabled and/or HTTPS Inspection must be enabled.
Categorize HTTPS Sites will work much better on R80.40 (or R80.20/R80.30 with latest GA JHF) due to added support for SNI.

[Wang]

I'm very sorry, but I still don't understand. Could you tell me more details? Thank you very much。

[PhoneBoy]

In very simple terms, a Domain Object attempts to make an association between a DNS name and an IP address.

• An FQDN Domain Object translates the FQDN to an IP address.
• A non-FQDN Domain Object confirms that an IP address is associated with a given domain by doing a reverse DNS lookup

You can use a Domain Object in the rulebase similar to a host object that represents a single IP address.
As such, it can be used in a pure firewall rulebase without App Control or other advanced blades as it doesn't require any Layer 7 inspection.
The (reverse) DNS resolution effectively happens "out of band."

This approach has a couple limitations:

• These objects only work with IPv4, if I remember correctly.
• Many sites actually share the same IPv4 address and you'd be allowing (or blocking) all of those sites if you use these objects in a rule.
• Non-FQDN Domain Objects incur a fairly significant performance penalty and, in the end, usually doesn't work as the reverse DNS rarely matches the DNS name you're trying to match (if such records even exist at all).

An Application/Site is effectively an App Control signature that operates at Layer 7.
It's a fairly simplistic App Control signature that identifies that traffic is:

• Web-based (i.e. regular HTTP or HTTPS)
• Is destined to one of the domains you've listed in the definition.

If the traffic is not web-based and/or App Control can't determine it's destined for one of the domains listed, then it will not match the traffic.

There are reasons that both approaches are available.
You have to use the one that is appropriate for the problem you're trying to solve. 
The more information you can provide about your environment and precisely what your goal is, the more likely we can tell you what approach will work best. 

[Wang]

Thank you very much for your reply

[Greg_Harewood]

Hey Daemon, I should have asked you this one 20 years ago.  I kept meaning to test it to see how it operated, but it was never important enough to spend the time on.... I mean, who actually USES domain objects?  I have some follow up questions for clarity if I may...

• When did the FQDN checkbox appear?  Was it always there?
• I thought the prefixed "." differentiated whether it was a forward or reverse lookup... is this true?
• Did it ALWAYS have both forward and reverse options?
• With reverse lookup, when does the lookup take place? What process does it?  While the lookup is happening, is it a default match, no match, or are connections held?
• Finally, any insight on why the third option is not provided that some other firewalls offer, which is to cache relevant forward lookups that the firewalls sees passing through and use them to inform a list of possible IP addresses?

Thanks! Hope you're well 🙂

[PhoneBoy]

The FQDN checkbox (and related functionality) appeared in R80.10.
The . in front of the name also premiered in R80.10.
Without FQDN, the packet is held while the lookup takes place.
Don't recall what process is doing it.
Caching DNS lookups happening through the gateway is an R80.40 feature, but only to ones the gateway is configured to trust--either to same DNS server gateway uses or specific DNS objects created in SmartConsole.

[_Val_]

Also, look here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

It sums up the case quite well

[Luis_Miguel_Mig]

Why hostnames are not supported by FQDN domain objects? So why I could create .checkpoint.com and not .community.checkpoint.com?