No. More DNS blocks can reflect stronger protection, but they can also come from repeated retries, embedded resources, noisy lists, or a broken application. Judge safety by covered resources, high-confidence harmful destinations stopped, required work preserved, bypasses found, and exceptions reviewed. Block volume is a diagnostic signal, not a safety score.
The practical outcome is metric interpretation that leads to a decision. An administrator should be able to look at a change in blocked requests and decide whether to investigate an endpoint, tune a policy, verify resolver coverage, or simply record a known pattern. The count begins the question; it does not answer it.
Read the number as a signal, not a verdict
A block counter records policy outcomes, not prevented incidents or deliberate human actions. One malicious hostname queried once and blocked may matter more than thousands of requests from an advertising component. Conversely, a flat chart does not prove that every intended device is protected. A laptop using a browser-specific resolver, a phone on cellular data, or a device behind another VPN may never reach the policy being measured.
RFC 9076 explains why raw DNS volume needs caution: browsers make secondary requests for embedded content and may prefetch names without a direct user action.1 Applications also retry failed dependencies. A single blocked hostname can therefore produce many records without representing many attempted visits. First group the total by resource, hostname, policy source, and time. Then ask what changed in the system or policy.
Separate useful blocks from noise
| Pattern | Plausible explanation | Next check |
|---|---|---|
| One high-confidence threat domain | A meaningful protective outcome | Confirm the resource is healthy and investigate relevant context |
| One hostname repeated rapidly | Retry loop, embedded component, or persistent software | Inspect timing and the application that depends on it |
| Many categories rise together | Policy, list, resolver, or fleet change | Compare the change time with configuration and inventory |
| Count falls unexpectedly to zero | Quiet use, missing coverage, or alternate DNS path | Run a harmless provider test from an intended resource |
| Blocks rise with support requests | Overbroad or newly inaccurate policy | Reproduce one task before changing scope |
Classification quality matters more than category breadth. CISA describes protective DNS as matching requests against threat intelligence and then blocking, redirecting, or sinkholing matching responses.2 That is a concrete protective function, but it does not make every blocked category equally security-relevant. Keep high-confidence malicious infrastructure separate from nuisance, preference, or acceptable-use categories so a large advertising total does not hide a smaller security signal.
Build a small safety scorecard
- Coverage: which intended resources used the governed resolver during the review window?
- Protective outcomes: which high-confidence malicious or prohibited domains were stopped?
- Usability: which required workflows failed, and how quickly were false positives resolved?
- Control integrity: which alternate DNS paths, disabled clients, or stale resources need attention?
- Governance: which exceptions lack an owner, evidence, narrow scope, or review condition?
Choose a denominator before comparing periods. Blocks per covered resource, per thousand answered requests, or per active day can expose a real change that a raw total obscures. Keep the same categories and resource population when comparing. If either changed, annotate the chart instead of presenting the movement as improved or reduced safety. Metrics become useful when another administrator can explain what the numerator and denominator actually represent.
Pair aggregate metrics with a small number of harmless outcome tests. Confirm an intended resource uses the expected resolver, a safe provider test receives the expected block, an ordinary required workflow succeeds, and a narrow exception does not spread. Never visit live malicious infrastructure to improve a dashboard. A known test proves one policy path at one moment; inventory and recurring verification establish broader confidence.
Investigate a count change in order
- Define the window and confirm that collection, timezone, and active-resource counts are comparable.
- Break the change down by resource, domain, category, policy action, and rule source.
- Check recent list, policy, application, device, network, and resolver-path changes.
- Open detailed activity only for the smallest affected scope and named diagnostic purpose.
- Reproduce one relevant workflow and run one harmless expected-policy test.
- Allow, block, log, or redirect only when evidence supports that action, then document the result and review trigger.
Stop widening the investigation once the question is answered. If a software update caused repeated calls to a blocked telemetry name but work remains healthy, record the pattern rather than treating every retry as a new incident. If one required identity hostname was newly blocked, restore only the verified dependency at the smallest resource scope that policy permits. If coverage disappeared, repair the DNS path before tuning categories.
Keep metric review within DNS limits
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, URL paths, search terms, files, form entries, in-app chats, voice audio, or full browser history. A query may be caused by a person, background software, an embedded object, or prefetching. Do not turn a blocked-domain total into a claim about attention, intent, productivity, or complete exposure to harmful content.
Use aggregates first because detailed DNS transactions can reveal sensitive patterns even when they do not reveal pages.1 When detail is necessary, name the question, resource, authorized reviewer, and end time. Record the conclusion rather than retaining a broad browsing narrative. A good metric review leaves behind a policy decision and a small audit note, not an open-ended archive of unrelated activity.
Questions about blocked DNS counts
Does a sudden rise in blocked DNS requests mean an attack?
Not by itself. It may indicate malicious activity, but it can also come from an application retry loop, a newly enabled list, a category change, or one embedded hostname requested repeatedly. Check the affected resource, hostname, policy source, timing, and endpoint health before escalating.
Should zero blocked requests be the goal?
No. Zero may mean the environment is quiet, but it may also mean resources are not using the intended resolver or protection is misconfigured. Verify coverage with a safe test, confirm required work still succeeds, and compare outcomes over time rather than optimizing for either zero or a large total.
What is a better DNS safety metric than total blocks?
Use a small set: resolver coverage, high-confidence threat outcomes, false-positive rate, unresolved bypasses, time to repair legitimate failures, and exception age. No single number proves safety. The combined trend should show that intended resources receive policy, harmful lookups are stopped, and ordinary work remains usable.
Review one metric in Veilty
In Veilty, begin with aggregate outcomes for one family Space or team Tenant, then open detailed retained activity only for a named question and permitted role. Reusable baseline and enforced policies are scoped to the relevant Space or Tenant. A resource may override its boundary’s baseline, but never its enforced policy. Account invitations grant no Space or Tenant access; accepted members receive access only after roles are assigned. Retained history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is role-gated, while the resolver processes live DNS requests to apply policy. Review one surprising count, document its cause, and change only the narrowest justified policy.345