Protective DNS stops a malicious site when the device asks a participating resolver for its domain. The resolver compares the lookup with threat intelligence and policy, then withholds the destination or returns a controlled response. The connection therefore fails before the page loads, provided that request actually reaches the protected resolver and the domain is already recognized.
That is pre-connection risk reduction, not a promise of perfect prevention. A founder, security lead, or parent can use it to remove many known-bad destinations from the normal path, then keep endpoint protection, secure browsers, updates, account safeguards, and security awareness responsible for the signals DNS cannot see.
Follow the lookup to the decision
A device normally asks a recursive resolver for the address associated with a domain before opening a new connection. A protective resolver adds a policy decision to that job. The UK National Cyber Security Centre describes protective DNS as a recursive service that prevents access to domains known to be malicious, with rules derived from commercial, internal, and open intelligence sources.1
When a rule matches, the resolver can decline to return the real address, return a non-existent-domain result, redirect toward a sinkhole, or support a block page. The exact response varies by service and client. The security outcome is the same: the application does not receive the ordinary destination from that lookup. NCSC guidance also recommends allow-list capability and review processes because legitimate domains can be classified incorrectly.2
Understand the pre-connection advantage
Acting at resolution time is useful because the decision can occur before a browser retrieves a phishing page or an application contacts a malware service. The same boundary can also disrupt a compromised device attempting to resolve recognized command-and-control infrastructure. One resolver policy can protect different applications without requiring each application to recognize every dangerous destination.
| Stage | Protective DNS contribution | Control still needed |
|---|---|---|
| Domain lookup | Compare the name with effective policy | Reliable resolver coverage |
| Policy match | Return a block, redirect, or controlled failure | Current intelligence and corrections |
| Page or app connection | Prevent the ordinary DNS-derived destination | Browser and endpoint protection |
| Device compromise | May interrupt recognized external lookups | Detection, isolation, cleanup, and recovery |
Map the gaps around the block
Protective DNS only decides on lookups that reach it. A browser-selected resolver, VPN, privacy feature, mobile network, hard-coded resolver, cached answer, or direct IP connection can place traffic outside the intended path. Newly created, compromised, or fast-changing infrastructure may also be absent from intelligence when first used. Coverage and classification speed should be measured rather than assumed.
DNS filtering can act on a domain lookup and 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 tell whether a lookup came from a deliberate click, an embedded resource, prefetching, or a background process. Use content-aware, application, identity, and endpoint controls when those distinctions matter.
Verify protection without touching a threat
- Choose one representative device and name the expected malicious-domain policy outcome.
- Confirm which resolver receives a fresh lookup from the operating system, browser, VPN, and off-network context.
- Use a provider-owned test domain or documented harmless test; never browse to live malicious infrastructure.
- Confirm an explicit policy result through a block page, decision record, or supported diagnostic rather than interpreting any DNS error as a block.
- Test a normal allowed domain and the real application task to detect accidental over-blocking.
- Repeat after browser, VPN, device, and network changes, and review aggregate outcomes before opening detailed activity.
Document the result as a path claim, not a universal claim: this resource, in this network context, sent a fresh lookup to this resolver and received this policy response. That wording makes later drift visible. A different browser, VPN state, mobile connection, or cached session requires its own check rather than inheriting confidence from the first result.
Correct malicious-domain policy errors
- Do not disable the entire protective source because one legitimate hostname is blocked; verify the dependency and create the narrowest time-bounded exception.
- Do not test with a dangerous domain merely because it appears on a public list; classifications change and exposure is unnecessary.
- Do not equate a missing DNS event with safety; the device may have used another path or an existing connection.
- Do not treat a blocked lookup as proof of user intent or device compromise; investigate the surrounding endpoint evidence.
- Do not make detailed DNS history the default view; use it only for a named purpose and limited interval.
Answers about protective DNS blocking
Does protective DNS scan a malicious page before blocking it?
No. It evaluates the domain lookup and returns a policy outcome. Threat-intelligence systems may analyze infrastructure separately, but the DNS decision does not require reading the page requested by this user.
Can protective DNS block malware that is already installed?
It can interrupt lookups to recognized command-and-control or download domains, which may contain some activity. It cannot inspect, remove, or remediate code on the device, so endpoint detection and incident response remain necessary.
Why might a known malicious site still open?
The device may use another resolver, reuse a cached answer, connect directly to an IP address, or reach infrastructure not yet classified. Confirm the actual resolver path and layer DNS protection with browser, endpoint, identity, and user safeguards.
Apply one bounded Veilty check
In Veilty, choose one resource in its household Space or team Tenant, confirm the assigned profile and resolver path, and apply the narrowest relevant malicious-domain rule. Reusable baseline and enforced policies belong to that boundary; a resource may adapt baseline policy when permitted but cannot weaken enforced policy. Test one safe expected block and one allowed task before widening coverage.
Start verification with aggregate outcomes. Retained DNS activity stays scoped to its Space or Tenant, is end-to-end encrypted with user-held keys, and is available only through permitted roles, while the resolver necessarily processes live requests to answer and apply policy. Open detail only for the named test window, correct the smallest proven problem, and close the review when the question is answered.