Impact of FQDN Address Objects on the CPU
03/26/2020 75 11772
When creating FQDN Address Objects, more DNS queries are made by the firewall. When we have unresolved Address Objects, the SonicWall will stop querying the server after the threshold specified.
However, when we have wildcard FQDN Address Objects like *.microsoft.com or *.google.com, many subdomains need to be resolved every time the TTL Expires. So we added an option to delete all the subdomains resolved after the TTL Expires so the SonicWall doesn't have to query the DNS every x seconds.
The diag option "Refresh sub-domains of wildcard FQDN address objects" (the diag page is available at https://IPofyourSonicWall/diag.html) might be enabled should you want to trigger the DNS resolution for all the expired sub-domains on an FQDN after the TTL expires
Let's explain it better:
The last resolution for support.microsoft.com will be deleted as soon as the TTL Expires (every DNS resolution has a TTL). Now we could think that it's better that the SonicWall doesn't delete it so next time the DNS resolution will be already there.
However, for big domains like *.microsoft.com or *.google.com, in 1 hour we will probably have in memory hundreds/thousands of sub-domains and the SonicWall has to refresh all of them every, let's say, 60-120 seconds or even less (it depends on the TTL set by the DNS Server). You understand that this will highly impact the CPU performances and you could get the firewall locked up or worse, rebooting.
DNS Queries for FQDNs are one of the most impacting processes on the SonicWall's CPU in general.
There isn't a resolution for this as this is something related to the configuration.
If you see a high CPU Usage you may want to double check your FQDN Address Objects configuration. First of all you can download the TSR from System | Diagnostics | Download Report and search for "RESOLVE ERROR": here you will be able to see all the FQDNs currently not resolved and then check why they're not resolved (delete them if not needed any longer).
After that you will need to check all the wildcard FQDNs with big domains: it is never suggested to use wildcard FQDNs like *.microsoft.com as they will require too many DNS queries.
However, should you noticed a huge impact on performances, please check in the diag page that everything as configured as below: