FQDN - how does it work under the hood?

[S_E_]

hi,
I was asked today how FQDN objects work, especially when the client resolved the URL already in the LAN.

1. Assuming NON-FQDN mode
e.g.
- client resolves apps.apple.com from internal DNS server to IP address 95.1.1.1
- client forwards request to default router and then via firewall to internet
- The firewall has an NON-FQDN object apple.com which allows the traffic.
However, the firewall see the IP address and not the URL, correct?
Does the firewall always do a reverse DNS lookup to see if the destination IP is part of any FQDN object?
Default TTL = 60 seconds

The FQDN-A-Deeper-Dive-Customer.pdf did refer to older version.
https://community.checkpoint.com/t5/Management/Domain-Objects-FQDN-An-Unofficial-ATRG/m-p/40789/thre...

2. Assuming FQDN mode and destination www.apple.com
Default TTL = 3600 seconds
Does the firewall always do a reverse DNS lookup to see if the destination IP is part of any FQDN object?
Same question

Any idea?

Thanks; Regards

[G_W_Albrecht]

sk90401: How are Domain Objects enforced by the Security Gateway?

sk161612: Domain Object Enhancement - DNS Passive Learning

sk157493: Fully qualified domain name object (FQDN) does not match properly, causing traffic drop

[S_E_]

hi

thanks, I saw these SK but it did not answer the underlying question.

Thanks

[G_W_Albrecht]

Open an SR# with CP TAC !

[Bob_Zimmerman]

FQDN objects cause the firewall to look up the name periodically and cache the results in a table. The table is then used to populate the object. This works a lot like dynamic objects. For FQDN objects to work properly, the clients and the firewall must use the same DNS resolution path so they get the same answers. FQDNs do not involve any reverse lookup.

[the_rock]

You can confirm with TAC, but to me logically, I would say yes to both ?s

Andy

[emmap]

Non-FQDN does a reverse lookup on IPs as they are seen to see if they match the URL defined. As such it's not the best tool as reverse lookups rarely match the URL used and it's a lot of DNS queries.

FQDN mode polls configured DNS servers every 60 seconds for the domain name configured and caches the result. Any traffic to the IP address that was resolved is matched against the FQDN object. 

[S_E_]

hi,

I miss somehow the puzzle piece regarding the trigger:

..The firewall see the desired destination IP address and not the URL, correct? 

Regards

[emmap]

Yes, the firewall sees packets from/to IP addresses with source/destination ports and makes decisions from there. Anything in a basic access policy (so no APPC/URLF) has to be matched to something based on that. 

[S_E_]

hi,

ok, that means if firewall only see the destination IP address, how does it know that it belongs to an access-rule when the is only a FQDN object like apple.com ?

Regards

[emmap]

If the domain object is enabled in FQDN mode, the gateway is doing a DNS lookup every minute to resolve that to an IP address. When it sees a packet to that IP address, it matches against the FQDN object and will match the rule if everything else matches the rule criteria.

[S_E_]

OK,

means having hundreds of FQDN objects, DNS queries will be made independent if the is a current request?

Regards

[emmap]

It's performing the lookups when there might be a connection that could match the rule that contains the object.

When a connection that traverses the Security Gateway is being evaluated against the rulebase, if the Unified Policy mechanism encounters a possible match that includes a Domain Object, the object must be resolved before a verdict can be reached.

• If all Domain Objects in the Access Policy are in FQDN mode, the Security Gateway performs direct DNS resolution of each of the Domain Objects and caches the results

• If any domain object is not FQDN, and the IP address isn't in the cache, the Security Gateway must perform a reverse DNS request to determine whether the IP belongs to the Domain Object.

From: https://support.checkpoint.com/results/sk/sk90401

[S_E_]

Ok,

Thanks. I'm afraid I still don't get it.

I still miss the trigger when the firewall sees only the destination IP request.

I guess, I will setup a TAC case.

Thanks a lot for your help!!

Regards

[emmap · Accepted solution]

OK, let's say your rule is: Source: 10.1.1.0/24 ; Dest: apple.com ; Service: https

If the gateway sees HTTPS traffic from a source 172.16.1.1 to any IP, the gateway does not do a lookup on the FQDN because the source cannot match the rule.

If the gateway sees SSH traffic from 10.1.1.1 to any IP, the gateway does not do a lookup on the FQDN because the service cannot match the rule.

If the gateway sees HTTPS traffic from 10.1.1.1 to any IP, the gateway DOES do a lookup for apple.com, because the connection could match the rule. If the destination IP matches the returned IP address from the lookup, the rule is matched. If it does not match, the rule matching continues down the policy.

[Bob_Zimmerman]

I'm not so sure there's a traffic requirement to trigger the FQDN lookups. I have a standalone firewall I use as an API development target. All it has is a single External interface. It's looking up several of my FQDN objects (but not all) even though there's nothing behind it to be hitting any rules.

[the_rock]

Excellent explanation!