An earlier control point
A matching DNS decision can prevent the client from receiving the destination address before its intended connection begins.
DNS FILTERING VS URL FILTERING
How DNS filtering works—and how it differs from URL filtering.
DNS filtering decides whether a hostname should resolve before a client connects to it. URL or web filtering operates later and can make a more granular decision about a visible web address or path, depending on where that control runs and how encrypted HTTPS traffic is handled.
DNS policy evaluates hostnames rather than complete URL paths QueryWarden does not inspect page content or HTTPS requests The two control layers can complement rather than replace each other
DNS decision pathIllustrative request
DNS question
Hostname policy
DNS result
Web connection
Policy checked before connectionDecision evidence is reviewable when the profile retains it.
THE PRACTICAL DISTINCTION
A hostname decision is earlier and broader than a page-level decision.
For a request to news.example.test/article, DNS normally receives a question about news.example.test—not the /article path. A DNS block can therefore stop connections to that hostname across participating applications, while URL filtering may distinguish pages only when the web address is visible to its browser, endpoint, or proxy control.
Controls you can use and verify.
Each capability below reflects the current public product, with beta and compatibility limits called out separately.
Coverage beyond one browser
When applications use the configured resolver path, hostname policy can apply to browsers, apps, connected devices, and other DNS-dependent traffic.
Clear hostname scope
QueryWarden previews exact and subdomain matches, audience, decision source, and duration so the reach of a DNS exception can be reviewed.
A useful layered choice
DNS policy can reduce access to known unwanted domains, while endpoint, browser, secure web gateway, and content controls address different evidence and granularity.
Compare what each filtering layer can actually decide.
QueryWarden’s Domain Rules workspace demonstrates a hostname-level DNS decision. The comparison below separates that resolver scope from URL or web filtering, whose path-level visibility depends on an appropriately positioned browser, endpoint, proxy, or inspection system.
Open full-size screenshot DNS filtering and URL filtering are not interchangeable
| Question | DNS filtering | URL or web filtering |
|---|---|---|
| Primary decision input | The hostname in a DNS question, such as news.example.test. | A web address, path, category, or related request context that the deployed control can observe. |
| Where the decision happens | During name resolution, before the intended destination connection. | At the browser, endpoint, proxy, or web-gateway layer around the web request. |
| Typical granularity | A hostname or subdomain range, potentially affecting multiple pages, applications, or services. | A site, page, path, or other web-request attribute, depending on product and HTTPS visibility. |
| HTTPS boundary | DoH encrypts DNS transport to the resolver; QueryWarden still evaluates the hostname and does not inspect the later HTTPS request. | A full encrypted path is not generally visible to an intermediary without suitable endpoint, browser, proxy, or TLS-inspection design. |
| Best fit | Early domain-level protection and policy for participating DNS clients. | Requirements that genuinely need web-page or path-level decisions and accept the deployment trade-offs. |
HOW IT WORKS
From setup to an explainable DNS decision.
QueryWarden applies policy at the recursive DNS layer, before a supported client connects to the requested domain.
- 01
A client asks for a hostname
A configured client sends a DNS question such as news.example.test through its private QueryWarden DNS-over-HTTPS endpoint.
- 02
QueryWarden evaluates domain policy
The resolver checks the applicable profile, managed sources, service controls, schedule, and custom hostname rules before answering.
- 03
The DNS result allows or blocks the hostname
A block prevents the intended connection through that DNS path; an allowed answer lets the client continue toward the destination address.
- 04
A separate web control may evaluate the request later
If an organization needs page or path granularity, a browser, endpoint, proxy, or secure web gateway must have the required web-request visibility.
CLEAR BOUNDARIES
Calling DNS policy “URL filtering” can hide an important limit.
QueryWarden makes domain-level DNS decisions. It does not claim the content and path inspection performed by some browser, endpoint, proxy, or secure web gateway products.
- DNS normally sees the queried hostname, not a complete address such as https://example.test/private/page or its query parameters.
- A DNS block for one hostname can also affect unrelated pages or services that share that hostname, while an allow decision does not approve every path behind it.
- A DNS resolver does not inspect browser DOM, page text, downloaded files, application processes, or encrypted request bodies.
- URL visibility under HTTPS depends on the web-filter deployment; it should not be assumed merely because a network device can see an IP address or domain.
WHO AND HOW
Technical basis and product evidence
Published and reviewed by QueryWarden Engineering, Digiport OÜ. First-party review against the current public QueryWarden product, its documented deployment constraints, and the primary sources listed on this page. This is not an independent audit, certification, approval, or endorsement.
Product screenshots are deterministic captures of the current interface using synthetic accounts, devices, and reserved .test domains. External sources explain protocols and industry guidance; they do not verify QueryWarden implementation claims.
Last reviewed . Product availability can change; dashboard capability labels remain the source of truth. Review our Security & Trust disclosure.Standards and public guidance
These primary sources support the general technical context. Citing them does not mean their publishers evaluated, approved, or endorsed QueryWarden.
- IETFRFC 3986 — Uniform Resource Identifier (URI): Generic Syntax (opens in a new tab)Defines URI components, including the authority, path, query, and fragment used to distinguish a complete web address from a DNS hostname.
- IETFRFC 7754 — Technical Considerations for Internet Service Blocking and Filtering (opens in a new tab)Documents effectiveness limits, circumvention, and unintended consequences of filtering methods.
- IETFRFC 8484 — DNS Queries over HTTPS (opens in a new tab)Defines how DNS questions and answers are carried through HTTPS.
What to know before you change DNS.
How does DNS URL filtering work?
The phrase often combines two different controls. DNS filtering evaluates the hostname requested during resolution. URL filtering can evaluate a fuller web address or path only where that information is visible to the browser, endpoint, proxy, or inspection system. QueryWarden provides DNS filtering, not full-URL inspection.
Can DNS filtering block one page but allow another on the same domain?
Not reliably when both pages use the same hostname. DNS receives the hostname needed for resolution, not the later HTTP path. A path-specific requirement needs an appropriately deployed URL, browser, endpoint, or content control.
Should a business choose DNS filtering or URL filtering?
Choose controls from the requirement. DNS filtering offers an early hostname-level decision across participating clients with relatively little endpoint coupling. Page-level policy, file inspection, application behavior, or complete web-session control requires other layers; organizations can use both.
START WITH THE AVAILABLE FREE PLAN
Start with the hostname-level control you can verify.
Connect one compatible Free endpoint, send fresh DNS traffic, and inspect the result before relying on a wider policy.