Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Linus_Espach
Participant

Domain-Object matching (exact) procedure

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

  • ".checkpoint.com"

would also match

  • "support.checkpoint.com" or
  • "community.checkpoint.com"

(as stated by reverse-looking up the IP)

Therefor I resolved both (using dig):

  • support.checkpoint.com -> support.us.checkpoint.com -> 209.87.209.88
  • community.checkpoint.com -> e1364.dscb.akamaiedge.net -> 23.203.123.111

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:

  • 209.87.209.88 -> NX
  • 23.203.123.111 -> plenty x.arin.net.

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

0 Kudos
5 Replies
PhoneBoy
Admin
Admin

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

0 Kudos
Linus_Espach
Participant

The sk120633 decribes this procedure within R80.10+ and was referenced above. Is there a completely new method or did I missunderstand you?

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
Linus_Espach
Participant

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.

0 Kudos
PhoneBoy
Admin
Admin

I recommend leaving feedback on the SK to that effect.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events