Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
biskit
Advisor

Domain Object CNAME Question

I have a query regarding how Domain objects handle CNAMES following trying to configure specific access for a customer system, which doesn't work when I specify the domains they've told me to allow.

I’ve done some testing in my lab.  Please also refer to the screenshot lower down.

A DNS lookup on zadarastorage-install.s3.amazonaws.com returns s3-1-w.amazonaws.com, which in turn returns s3-w.us-east-1.amazonaws.com, which in turn gives an IP address to connect to.  The IP address is different every time you refresh.

In my lab I allowed the name zadarastorage-install.s3.amazonaws.com.  The page timed out and other traffic was also dropped.

In my lab I then allowed all three names:

  • zadarastorage-install.s3.amazonaws.com
  • s3-1-w.amazonaws.com
  • s3-w.us-east-1.amazonaws.com

The page still timed out.

In my lab I then allowed *.amazonaws.com  (i.e .amazonaws.com with the FQDN box unticked).  The page now loads immediately.

I’m not yet sure why it didn’t work when I allowed all of the names shown in the tcpdump.  But it seems quite clear that allowing a specific domain name in the rule doesn't automatically allow any CNAME's it resolves to.  I don't want to allow the whole of amazonaws.com.

Does anyone have any thoughts?  Am I doing something wrong?

zadara.png

0 Kudos
4 Replies
Marcel_Gramalla
Advisor

I don't know exactly how CNAME is handled but you can check each domain object following this sk: Domains Tool (domains_tool) (checkpoint.com)

It probably works correctly but as a domain object is a simple DNS lookup (from what I know) it's not that reliable if the IPs change very often which seems to be the case in your scenario. So first check what the gateways think about the domain name with the domain tool from the sk. 

0 Kudos
Tobias_Moritz
Advisor

When using FQDN objects (domain object with FQDN checkbox ticked), all gateways using this object in their policy are periodically (once per minute) do DNS forward lookups for this FQDN and cache the results in a table. This cache table is used for rulebase lookups with new connections.

This means that you have to give your gateway some time to cache all possible ip addresses for this FQDN in its cache table before doing your tests. Otherwise it could happen that your test client uses an IP address, not already known to the gateway. You can observe this growing table with the command provided by Marcel.

This only works that way, when your version is not to old. R80.10 JHF T142, better R80.20 and above.

Edit: It does not matter how long the CNAME (or DNAME) chain is. You can use ".zadarastorage-install.s3.amazonaws.com" as FQDN object without problems. Please make sure not to forget the leading dot (even if it makes no sense on the first sight).

0 Kudos
Bob_Zimmerman
Authority
Authority

It's also important that clients use the same DNS path as the firewall. This is mostly a concern for older topologies where clients in an office go over a WAN connection into a datacenter somewhere else to be filtered by a firewall in the datacenter. I've seen some environments where there were multiple such central datacenters around the country, all client DNS went out one by default, but actual client traffic could go out any of them. That caused problems because the site they were trying to reach used DNS-based load distribution, so the firewalls didn't all learn the same IPs for it.

Mikael
Collaborator
Collaborator

I asked this question a while back and the answer I got at that point was that the gateways resolve the FQDN during policy installation and caches the result with the TTL from the DNS-response.

I haven't verified this but it makes sense to follow the TTL configured for the DNS-name to avoid unnecessary DNS-queries.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events