Best Practices - Working with Domain Objects (Pre R80.10)
For R80.10 and above, refer to sk120633 - Domain Objects in R80.10 and above
Performance for Domain Objects can be an issue. For each packet that transitions the Security gateway and hits the rule using the Domain Object, the system needs to do a reverse DNS Query to see if the Source / Destination (depending on how the rule is constructed) IP address matches the Domain Object.
The results are cached, but not indefinitely. Each time the system performs this lookup, it has to hold the packet until it gets a reply from the DNS server. If the Domain Object is significantly towards the top of the rulebase, then you could potentially be doing a DNS lookup on almost every packet that transitions the rulebase.
If the DNS server is slow to reply, (~200ms) then you are adding 200ms of latency to all packets that do not match the cached results, if they hit the rule containing the Domain Object. If the performance of the DNS server is such that you see timeouts, then the system has to wait for the full timeout before deciding that it must drop the packet, because it cannot tell if the packet matches the rule or not. (A symptom of this would be seeing F_INDOM drops on the Security gateway in kernel debug fw ctl debug - m fw + drop).
Rules of thumb:
- Avoid using Domain Objects, if you can.
- Place them as low in the rulebase, as you can, to maximize the chance that a given packet will hit a rule that uses a network object, before falling to the Domain Object.
- Construct rules above the Domain Object, in such a way, as to catch as much traffic, as you can, before falling through to the Domain Object.