Domain Objects (FQDN) - An Unofficial ATRG

[Adam_Forester]

In 2018 I wrote an internal (Check Point) unofficial ATRG that covers Domain Objects in a lot more detail than sk120633 covers. I've discussed this document with our developers and confirmed all the details and was given permission to share this on CheckMates! 

The attached document contains basic info on types of domain objects, Information on how domains are looked up and how often, cache of results, and troubleshooting steps with some API to confirm your usage. 

This has since been updated to show the changes in 80.20 where the service, in my opinion, is super optimized and awesome!

Thanks for reading!

For the full list of White Papers, go here. 

[Vladimir]

Thank you! This alone justifies jump to R80.20 if domain objects are used.

Can you describe which blades support domain objects and where those should be avoided (even if officially supported)?

[Wacheki]

I also had a similar question. Are Domain Objects usable with the default Firewall blade or one needs to enable Application and URL filtering blades??

[Adam_Forester]

They are supported in the Source/Dest columns of the Access Policy. Honestly, they are a good use just avoid non-FQDN objects as best you can because reverse lookup is taxing. 

[Vladimir]

Thank you.

I am working with the client who is interested in using FQDNs in the QOS and we were told by CP that they are supported there as well.

For now, we are seeing problems with that, (no logs and no enforcement of the bandwidth limits on rules containing FQDNs in destinations).

Have you, perchance, had a run in with this use case?

[Adam_Forester]

Been a long time since I’ve done QoS on CP. I’m short it was still actually called Floodgate-1 🙂

depending on usage age you could use them in a destination in a unified access policy and then use limits to limit the upload/download on those sites. 

[Vladimir]

Had to look it up to refresh my memory

Sorry, that is a non-starter: CP is adjusting bandwidth by dropping successive packets when using hard bandwidth limits in the unified policy (with questionable logging).

My goal is to actually assign priority weights to some of the critical to the client sites, the task that only QoS seem to be suitable for.

[Kim_Moberg]

Thanks for sharing, it is good stuff to read with technical insights.

I have also read the non-fqdn takes longer to get results and have been searching for ways to fast get an overview which of fqdn and non-fqdn. This document now gave me the necessay insights by using commands in expert mode and API.

More if this If possible 🙂

Thanks 

[Kaspars_Zibarts]

Absolutely awesome - been waiting for this long time as we have used FQDN objects with R80.10 quite extensively and run into ton of problems prior T142  

There is still one case for me that's unsolved (no, I have not raised SR yet as I was trying to find more info how to check cached entries..) - sometimes when FQDN resolves to multiple (seems like more than 3) IPs, one of those will get enforced intermittently

For example

Object set as follows

You can see from logs that the last IP is enforced sporadically - then it works and then it doesn't

That's why I wanted to find actual mapping between FQDN and cached IPs for it. If you know how to find it as  dns_reverse_cache_tbl gives you only IPs but not matching FQDN

[Kamil_Kolo]

I have seen this occur in our environment as well where IP addresses that are resolved for a domain will sometimes work and then sometimes will not work. We are using R80.20 with FQDN checked for the domain objects. Have you had any luck with that?

[Anton_Kazantsev]

Did you solve such behaviour?

[Adam_Forester]

That interesting. When is the first time it appears? It didn't oddly time out did it? I haven't found a better way. I have a really bad script that will covert the hex to IP and then do a reverse lookup in my lab. Problem with it is most of these sites don't use reverse entry so it ends up just failing on a lot things. I will keep digging on it. That cache table is shared accross services and isn't just domain based objects. (from what I can tell)

[Alessandro_Marr]

Adam, great job and thank you for sharing!!

I have a question for you, if I need to create a rule with a destination ww2.checkpoint.com and ww1.checkpoint.com, how to do  this? I  need to create 2 objects FQDN to avoid that you explain on document?

[Kaspars_Zibarts]

Yes you would create two separate FQDN objects

[Alessandro_Marr]

Thanks Kaspars, but I have a new question: I have a rule where port of destination is not 80 or 443 and destination is <several>.domain.com.br... how to proceed? is it  possible, for example, to create a application/custom site to use if wildcard on domain or REGEX and including the port on URL?

for example:  (^|.*\.)*domain\.com\.br\:9090

[Kaspars_Zibarts]

I'm afraid no, you won't be able to use wildcard with FQDN objects. If you read the SK (sk120633 ) you cold use old style domain objects that do reverse lookups but I would strongly suggest to stay away from that idea - it will only screw up DNS cache.

If you are using URL filtering blade, i might work, but I'm no expert on that.

[Alessandro_Marr]

ok, thank you Kaspars.

@ Adam Forester, please, could you explain how to do this? 

[Adam_Forester]

I'm with Kaspars Zibarts‌ on this one. The only way to get a wildcard type approach is to use non-FQDN objects and they are much more intensive for the gateway. As for your port question. The port would be used in the service/applications column of your rule. The domain object should be limited to just the DNS name since that is all we look up.

[Alessandro_Marr]

Thank you Adam.

[Matthew_Hembree]

One-liner for R80.20 DNS cache to dotted decimal IP address:

fw ctl multik print_bl dns_reverse_cache_tbl | cut -f1 -d';' | cut -f2 -d'<' | sort | uniq | gawk --non-decimal-data '{for (i=1;i<=NF;i++) printf "%d%s","0x"$i,(i==NF?"\n":".")}' FPAT='..'

Source: networking - How to convert a hexadecimal value to a "standard" ip address? - Super User 

[Matthew_Hembree]

I'm kind of in the same boat. I would like a bit more information about how the entries are cached relative to the TTL.

[0 sec] For instance: abc.com resolves to 1.1.1.1 with a TTL of 30 seconds.

According to the doc: 1.1.1.1 will be cached for an hour in the access entry. And R80.20 will do a lookup of abc.com every 60 seconds.

[30 sec] What happens when the TTL expires after 30 seconds?

[31 sec]Let's say that the new resolution that the host (gw and host have the same caching resolver) has for abc.com will be 2.2.2.2.

Is the gateway still only allowing 1.1.1.1 in the access entry?

[Adam_Forester]

in 80.20 you can run domains_tool -d update.microsoft.com to show which IP is associated to a domain object

[Raj_Khatri]

Hi Adam, is CNAME support added in the main R80.20 build or a specific jumbo take?  I didn't see it documented anywhere so wanted to confirm.

[Adam_Forester]

Technically speaking you could use a CNAME and enter it into the FQDN name and it would look it up for an A record. What I was talking about directly in the document is if you use an FQDN that points to a CNAME then we will follow the lookup until it returns an A record. 

[David_Evans]

The vast majority of our domain objects do not need and do not have a www record.   It appears that the NXDOMAIN response is cached more a much shorter time than a response with a valid IP.

As I look forward to expanding our use of domain objects, this could easily ramp up to millions of www NXDOMAIN lookups per day,  Especially with the behavior of the 80.10 boxes.

Is there a way to turn the www record lookup off for individual domain objects?   All Domain objects?

[Kaspars_Zibarts]

Same here. Our FQDN on R80.10 on VSX with one VS with 10 coreXL instances is struggling. Almost latest take. Too many alerts that DNS resolution failed in logs. I have raised multiple cases and it seems that only way out is upgrade to R80.20 or 30. That reduces lookups only from one core instead of 10 and adds some useful tools. Probably early next year!

[David_Evans]

Its a kernel parameter to disable the default www lookup:

add_www_prefix_to_domain_name=0

to this file:

/var/opt/fw.boot/modules/fwkern.conf

This reduces the DNS lookups for the new domain objects.   By default when you create a domain object for something like .download.microsoft.com   Checkpoint does a DNS lookup for both download.microsoft.com AND www.download.microsoft.com.   We do not want it to lookup the WWW record.

[Kaspars_Zibarts]

do you know if it works with R80.10? can't find any SK regarding it 🙂

[David_Evans]

We are using it in 80.10 jumbo 225

[Kaspars_Zibarts]

@Adam_Forester not entirely sure if you were planning to update this great guide. Just two small observations after we upgraded to R80.30.

I know it's already in the thread here but maybe add to the PDF domains_tools CLI, that's a massive improvement from R80.10

And additionally we got caught out with some clusters that have been there for million years - there was a rule permitting DNS requests from gateway only on UDP and not UDP+TCP. That resulted in wsdnsd going into "blocked" state and causing a lot of domain resolution alerts in logs:

Basically those DNS responses that were marked as truncated over UDP would trigger TCP DNS lookup but since there was no rule permitting that, it simply died quietly and caused wsdnsd to go into blocked state for 44secs!

So it's a must "check" (domain-tcp) for FQDN and Updatable Objects that utilise DNS.

I run through all relevant SKs (sk120633, sk120558, sk90401) but none of them had it either

K