When blocked domains spike, compare the increase with total lookups, active devices, recent policy changes, and reported breakage before changing a rule. Start with aggregate outcomes, investigate one named resource and short time window only when necessary, then make the narrowest correction and verify both a required task and a safe expected block.
The practical outcome is a block-spike review that distinguishes a real policy problem from ordinary volume changes without watching everyone. A spike is an observation, not a diagnosis. Browsers prefetch domains, applications make background requests, devices retry failed lookups, and one page can trigger many names.1 A useful review preserves required access while keeping the intended boundary intact.
Define the spike against a stable baseline
First define what increased. Raw blocked requests can rise because total DNS volume rose, more resources became active, or one client repeatedly retried the same blocked name. Compare a consistent interval with the previous four similar intervals. Separate blocked requests, distinct blocked domains, affected resources, and the percentage of all policy decisions that were blocks. Note school days, weekends, maintenance windows, and known travel rather than comparing unlike periods.
| Signal | Compare with | Question it answers |
|---|---|---|
| Blocked requests | Total lookups in the same interval | Did blocking rise faster than activity? |
| Distinct blocked domains | Prior comparable intervals | Is the change broad or repetitive? |
| Affected resources | Active resources using the profile | Is the spike isolated or shared? |
| Policy and source versions | Last known stable version | Did classification or policy change? |
| Support reports | Required tasks and times | Did anyone experience actual breakage? |
Record the comparison before opening detail. If the rate, affected-resource count, and user-visible outcome are stable, the raw number alone may require no action. If one profile changed immediately after a category or rule update, that timing provides a concrete question for the next step. NIST configuration guidance supports controlled evaluation and verification rather than reacting to an isolated metric.2
Triage without assuming human intent
Check operational explanations first: a new device, resolver-path change, software release, category-source update, scheduled job, or retry loop. Then ask whether the spike coincides with a failed required task, a security alert from another authorized control, or no visible effect at all. A blocked lookup does not establish that a person typed a domain, visited a page, or attempted misconduct.
DNS filtering can decide how to answer a domain lookup and record its allow, block, or redirect outcome. It cannot read page contents, full URL paths, search terms, in-app chats, voice audio, or full browser history. It also cannot prove that a page rendered or code executed. Use endpoint, browser, application, identity, or content controls when the question depends on those facts.
Investigate with bounded evidence
- Write one question, such as whether a profile update blocked the learning platform on one tablet.
- Confirm the resource, assigned profile, resolver path, policy version, and exact interval related to that question.
- Review aggregate outcomes and support context before opening domain-level activity.
- If detail is necessary, limit it to the named resource and shortest useful interval, with an authorized reviewer.
- Group repeated outcomes by domain or policy source so retries do not masquerade as many independent events.
- Close the detail view once the evidence supports a narrow decision, and record what was not established.
This sequence protects privacy and improves diagnosis. The IETF recommends minimizing retained DNS data, limiting access, and using full logs only when necessary.3 Avoid exporting a household-wide domain list into tickets or chat. Keep the evidence beside the policy decision, restrict who can see it, and remove troubleshooting material when its named purpose ends.
Choose the least broad response
If a required domain was misclassified, prefer a narrow, documented allowance at the affected profile or resource boundary over disabling a category for everyone. Give the exception an owner and a review condition. If a device is using the wrong resolver or profile, correct that path rather than widening policy. If the spike reflects expected blocking and no required task fails, document the review and leave the rule unchanged.
When another control produces a credible security alert, follow the relevant incident process and correlate only authorized evidence. Do not add a broad blocklist merely because the count looks alarming. Protective DNS can prevent connections to known harmful domains, but the NCSC presents it as one defensive capability whose administration and provider evidence still require care.4
Verify recovery and set a review point
Test from the affected resource on the network path that produced the spike. Complete one ordinary required task, then use a provider-owned harmless test domain for an expected block. Confirm an explicit policy outcome instead of treating every DNS error as evidence. Record the time, resource, profile, policy version, expected result, and observed result.
Set a short review point based on the cause: after the next software cycle, when a temporary exception expires, or after several comparable intervals. Compare normalized outcomes again. Close the item when required access works, the safe block still holds, the resolver path is correct, and no unexplained resource-specific spike remains. Escalate unresolved diagnosis instead of repeatedly changing policy.
Blocked-domain spike answers
Does a block spike mean a device is infected?
No. Repeated background requests, a software update, a newly active device, or a classification change can all raise the count. Treat the spike as a prompt to confirm coverage and context, not as proof of malware or a person's intent.
Should every domain in the spike be reviewed?
No. Begin with aggregate categories, outcome rates, affected resources, and known changes. Open domain-level detail only for a named troubleshooting or security question, use the shortest useful time window, and stop when the decision is supported.
When should an admin change the DNS rule?
Change it only after identifying a policy outcome that is wrong for a required task or a documented risk. Narrow the change to the affected profile or resource when possible, then test an allowed task and a harmless expected block.
Review one Veilty policy boundary
In Veilty, select the affected resource in its household Space or team Tenant. Confirm its assigned profile, resolver path, and policy boundary before changing anything. Reusable baseline and enforced policy belong at that boundary; a resource may adapt baseline policy when permitted but cannot weaken enforced policy. Keep any allowance narrow, then test one required task and one safe expected block before applying it wider.
Start with aggregate outcomes. Retained DNS activity is scoped to its Space or Tenant, end-to-end encrypted with user-held keys, and available only through permitted roles, while the resolver necessarily processes live requests to answer them and apply policy. Open the shortest detail window needed for the named question, record the reason and review condition, and return to aggregate monitoring.