Early DNS design makes filtering broad, distributed, and cache-sensitive. Policy can act when a resolver receives a domain lookup, but delegation, multiple resolver choices, cached answers, aliases, and application behavior limit what one decision proves or controls. Modern filtering works best as a domain-level layer with verified resolver paths, narrow rules, and complementary controls.
The practical outcome is a better filtering decision: first prove which resolver sees a fresh lookup, then apply the smallest domain rule that owns the job, test both the intended outcome and an ordinary allowed task, and hand finer distinctions to controls that can observe them.
Translate design choices into policy
| DNS property | Original purpose | Filtering consequence |
|---|---|---|
| Hierarchical names | Organize a general namespace | Rules act on names, not page meaning |
| Delegated authority | Distribute administration | One service can depend on several independently managed domains |
| Recursive and iterative resolution | Find answers across servers | The selected recursive path becomes the practical policy point |
| Caching and TTLs | Reduce work and latency | Old answers can outlive a policy edit |
| Extensible records | Support varied applications | An answer or alias is not proof that an application connection succeeded |
Put the decision at the resolver
RFC 1034 describes resolvers as the programs that obtain information from name servers, either answering from available information or pursuing referrals.1 A filtering resolver adds a policy decision at that lookup point. It can answer normally, block, or provide another configured outcome before the application tries to connect. This position covers many browsers and apps without requiring the filter to understand each application protocol.
That policy works only on the path the resolver actually receives. A browser, VPN, operating system, or application can select a different recursive service. RFC 8484 allows applications to use a DNS-over-HTTPS resolver identified by URI, while RFC 9076 discusses application-specific resolver choices.23 The first filtering question is therefore path ownership, not rule syntax.
Expect distributed authority
DNS distributes administration through zones and delegation. That solved the growth problem of a single shared host table, but it also means a modern application rarely maps neatly to one domain suffix. Sign-in, media, payments, storage, content delivery, and telemetry may use names controlled by different organizations. Blocking a visible brand domain may leave dependencies reachable; blocking a shared provider suffix may damage unrelated services.
Treat observed hostnames as candidates, not an automatic allowlist or blocklist. Reproduce the named task, change one narrow rule, and verify causality. RFC 9076 notes that embedded resources, prefetching, applications, and resolver behavior can generate queries without a deliberate visit.3 A nearby event can guide a test but cannot establish intent or dependency on its own.
Treat names as coarse boundaries
DNS asks for record data associated with a name and type. It does not normally receive the full URL, page text, account, search phrase, message, or media title. A rule for example.test cannot distinguish its learning page from its chat page when both share that hostname. Shared hosting creates the reverse problem: several unrelated services can depend on one infrastructure name.
DNS filtering can act on domain lookups and policy outcomes. It cannot read page contents, full URL paths, searches, in-app chats, voice audio, or full browser history. Use it for domain-level risk and availability decisions. Use browser, application, identity, endpoint, or content-aware controls when the rule requires a person, page, action, or content signal.
Verify the path before the rule
- Write one expected result for one resource and domain, including whether the lookup should be allowed, blocked, or redirected.
- Confirm the device, browser, VPN, and application use the resolver where that policy is attached.
- Create fresh state or wait for the relevant cache lifetime rather than relying on a page refresh.
- Observe the resolver decision and test the real application task separately.
- Run an allowed control task to detect an overbroad suffix, category, or shared dependency.
- Remove or narrow any exception that lacks an owner, reason, and review event.
Caching is expected DNS behavior, not a filtering defect. RFC 1034 makes local caching a design goal and lets data sources control the tradeoff among acquisition cost, update speed, and cache accuracy.1 A test must distinguish the policy result for a new lookup from an address or connection the application already holds.
Match controls to missing signals
- Use DNS policy for domain-level allow, block, redirect, and known-risk decisions.
- Use application controls for accounts, posts, messages, and feature-specific permissions.
- Use browser or web controls for URL paths and page categories when those distinctions are required.
- Use identity controls for authorization and named-user decisions.
- Use endpoint or network controls for process, device posture, connection, and traffic requirements.
Answers about early design and filtering
Why can a site still load after a DNS block is added?
The client may be reusing a cached DNS answer or an existing connection, or it may use another resolver path. A fresh controlled lookup is needed before judging the policy decision.
Can a DNS rule block one page but allow another page on the same domain?
Usually not. DNS policy receives names, not full web paths or page content. When both pages use the same hostname, a URL-aware or application control is required for that distinction.
Does encrypted DNS prevent filtering?
Not inherently. A filtering resolver can apply policy to encrypted queries it receives. Filtering is bypassed only when the client selects a different resolver or path that does not carry the intended policy.
Review one Veilty policy path
In Veilty, choose one Space or Tenant resource, confirm its profile and reusable policy assignments, and test a fresh expected outcome. Baseline policy can be narrowed where permitted, but a resource cannot weaken enforced Space or Tenant policy. Inspect only the activity needed to explain the test: retained DNS history is scoped, end-to-end encrypted with user-held keys, and readable only through permitted roles, while live requests still must be processed by the resolver. Keep the rule only if the application outcome and the allowed control both pass.