As @hisingh indicates, this typically happens when IoC domains are incorrectly being configured as FQDN Address Objects and used in the Destination Address in Security Policies. (There is another possibility which is related to the reporting engine picking up blocked websites or blocked domains to populate IP addresses in pre-defined threat reports).
This will cause the firewall to attempt DNS resolution on the FQDN Address Object, and populate an IP Address for Security Policy match. If the firewall's own DNS traffic is inspected by the firewall, it will trigger the associated Anti-spyware DNS signatures.
Using IoC domains in FQDN Address Objects is incorrect, or simply offers limited protection, since the resolved-ip for the domain from the firewall can be completely different than the resolved-ip from a host for the same domain.
The correct way to block IoC domains is to block them using Anti-spyware DNS. (If you instead did it on a Custom URL profile, you would only be protecting from HTTP based connections. Always keep in mind, when you talk IoC domains, you talk DNS traffic, not HTTP).
To populate custom entries into Anti-spyware DNS you need an EDL of type 'Domain List', pulling in a text file with the list of domains from a web-server. Make sure to set the new EDL of type 'Domain List' to a sinkhole or block action in the DNS Policies tab of the Anti-Spyware profile.
If you want to double-up for HTTP based traffic, that's fine and recommended, and the source text file with the list of domains used for the EDL of type 'Domain List' (i.e named 'ioc-domains-dns') can be repurposed on a separate EDL of type 'URL List' (i.e. named 'ioc-domains-url'), and *also* set it to block in the URL Filtering profile, or directly under the 'Service/URL Category' tab of a Security Policy with a configured Deny action.
And yes, you can triple-up by adding FQDN Address objects as a Destination Address in Security Policies, but just be aware of the hit-and-miss detection capability, and that DNS signatures sourced from the firewall will fire-up. You can find a way to except them by dedicating a Security Policy with the source IP of the firewall and no Anti-Spyware profile attached, or attached to an Anti-Spyware profile configured with specific Anti-Spyware DNS exceptions (the later being the best option since you can still detect other malicious DNS requests sourced from the firewall which may help detect the unlikely case of a compromised Firewall, but of course, not if the firewall is compromised *and* the threat actor is using the threat being excepted).
Furthermore, while you can create independent entries in a Custom URL FIltering profile, these can be used for URL Filtering or the Service/URL Category tab of a Security Policy but cannot be used to feed domains into the Anti-Spyware DNS profile. If you tried creating custom DNS Spyware signatures for the domains, these will be considered 'spyware' signatures and not 'spyware-dns' signatures, which will only allow you to configure a block action, (action 'sinkhole' is not configurable for custom DNS signatures). If you need to sinkhole, your only option with custom Domains is an EDL of type 'Domain List'. If blocking the DNS request is good enough, you can avoid having to host an external list, and you can instead create a custom Spyware signature for the domain. An example is available in this Tech Note (Page 20). If there are multiple domains to cover, they can be created using an OR in the custom signature definitions, or simply create one custom signature per domain.
After everything is configured, commit the configuration and test from a protected Host using the 'nslookup <domain>' command in a system terminal window.
