Zone Heat Map Showing 0% DNS Sinkhole Adoption Between Two Zones

[fhewiufhwefhwe]

Every single security policy is using the same anti-virus and anti-spyware profile, but the zone heat map is showing 0% DNS Sinkhole adoption for some rules.

There are three Source/Destination Zone pairs where it is showing 0% URL Filtering (because I have rules from specific ipaddresses to specific known FQDNs that should not be blocked by url filtering).  Rather than create separate Url Filtering policy for each rule, I am choosing a url filtering profile that only blocked malicious/phishing/etc. sites.

Any way to resolve?  This seems like a false positive particularly for DNS sinkhole adoption rate.

[LAYER_8]

Two possible issues here. Please make sure you have in your rule hierarchy towards the top a rule of application going to the predefined Sinkhole IPv4 and IPv6 address object set to allow with logs or block depending on your security posture (as noted, best practice is block).

Second, inside your Antispyware profile and DNS signatures, all those should be set to sinkhole as these are known or determined bad DNS requests. 

[fhewiufhwefhwe]

I have Sinkhole as the 3rd rule.  I will try making destination zone any from untrust.  I manually listed every zone for source zone, because it caused a false positive on zone protection adoption rate if you use any on any security policy rule.

Anti-spyware already is using sinkole and single-packet capture or extended-capture for listed options on DNS security

[fhewiufhwefhwe]

Still having the same issue.  If I go to Adoption Heatmap -> Tags, it's blocklists and denies that show up with 0% DNS Sinkhole adoption.  There are some other policies with 57-86% adoption rate, and every single policy has the same anti-spyware policy.

[LAYER_8]

That's interesting. I wonder if there's some logic in there that since the traffic is explicitly denied, it can't actually be scanned by AV/AS/VP so it will show as not best practice. I can't say I've seen that error before, super strange.