White Paper - Implementing Non-FQDN Domain Objects

[PhoneBoy]

Author: @Michael_Behum 
Security Engineer
12/31/2018

This whitepaper will explain how to properly implement legacy domain objects for wildcard network objects compared to FQDN. The disadvantage to the legacy model is DNS queries on each rule hit and the lack of acceleration on traffic in pre-R80.10 gateway code. These objects can be very helpful when you need to have large amounts of cloud traffic sites or dynamic DNS subdomain names where FQDN are not possible. Implementing legacy domain objects incorrectly can cause network outages due to high load on the gateway or DNS server.

Use Case: Inbound wildcard objects

1. Create new domain object via New -> Other -> Domain
2. Name the objects with a ‘.’ in the beginning with this meaning *.domain.com. This example would be *.aws.com . Make sure FQDN is not checked boxed in this scenario.
   
   
   
   
3. Create three new rules above the existing cleanup rule. The top will be a new cleanup rule and will be hit frequently. This rule will be key in protecting the gateway and DNS servers from being overloaded. The next rule is an exceptions for the destination IPs or ports depending on how often the domain object is being hit. The third rule will be the actual domain rule.
4. Create a new group for source IPs that need to use the domain objects and another group for destination exceptions.
5. Set the rules as follows:
   1. Rule 1 – Negated source of new group needing domain access.
   2. Rule 2 – Source of domain access group and destination of new exceptions group
   3. Rule 3 – Source of domain access group and destination of domain objects.

For the full list of White Papers, go here. 

[Kaspars_Zibarts]

Hi, thanks for the article! Was this setup verified in production environment? I was forced to remove all non-fqdn objects from our VSX running R80.10 (fairly recently JHF) as it caused total outage on all domain objects. Wsdnsd process went nuts. We had around 50 non-fqdn objects. Unfortunately due to production impact I had no time to dig into it but removing non-fqdn objects restored gateway behaviour. Could be that we had multiple VSes with fair amount of cores allocated, probably 20+ and each trying to to DNS resolutions.

I know the behaviour is changed completely in R80.20 when only one core will do DNS lookups but we haven't upgraded yet. 

So for now I would careful regarding non-fqdn objects if you ask me.

[Kaspars_Zibarts]

Imagine I had a proxy rule above your rule 1. Source proxy, destination any. Does that mean any IP hitting proxy rule would be checked for reverse IP lookup? And then response cached if it matched your aws domain object?

[HeikoAnkenbrand]

Hi Dameon, thanks for the nice information.