Threat domains stopped early
Managed phishing and malware-domain sources can block a known risky hostname before a browser or application reaches it.
PROTECTIVE DNS EXPLAINED
Protective DNS makes an earlier security decision.
Protective DNS evaluates a requested domain before a device reaches its destination. QueryWarden applies managed threat-domain sources, account policy, and custom decisions at that point, then records only the activity allowed by the active privacy setting.
Managed phishing and malware-domain blocking is available now Private DNS-over-HTTPS endpoints are available for compatible clients DNSSEC validation and encrypted upstream DNS are active
DNS decision pathIllustrative request
Device
Private DoH
QueryWarden policy
Allowed destination
Policy checked before connectionDecision evidence is reviewable when the profile retains it.
WHERE IT FITS
A domain-level control beside the rest of your security stack.
Protective DNS can stop a known risky destination before a connection is made, without inspecting content at that destination. It is useful across devices and networks, but its view is deliberately narrower than endpoint or content security.
Controls you can use and verify.
Each capability below reflects the current public product, with beta and compatibility limits called out separately.
Policy with a clear audience
Profiles, service and category controls, schedules, and custom rules determine which decision applies to each configured endpoint.
Decisions you can investigate
Retained query events can show the recorded result and its decision source without treating every detection as proof of compromise.
Privacy choices enforced
A profile can keep full domain history, retain anonymized aggregate activity, or turn new domain-level logging off.
Follow a DNS decision without overstating what it proves.
The current Query Log makes the recorded result visible when the active profile retained enough detail. This example uses synthetic activity so the workflow can be shown without exposing a person’s browsing history.
Open full-size screenshot malware.example.test from Demo laptop
The .test namespace is reserved for examples. The device and hostname shown here are deterministic fixture data, not a customer event.
Blocked · Security threat
The row reports what QueryWarden recorded at resolution time. A blocked request is a useful signal, not proof that the device was compromised.
Separate history from policy now
Explain identifies retained historical evidence and separately shows rules that match the hostname now, avoiding a rewritten version of the past.
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 configured device requests a domain
A compatible client sends the DNS question through its private QueryWarden DNS-over-HTTPS endpoint.
- 02
QueryWarden resolves the applicable policy
Endpoint authorization, profile settings, custom rules, service controls, and managed protection sources are evaluated for the request.
- 03
The resolver returns a decision
A blocked destination receives the configured blocking response; an allowed request continues through validated recursive resolution.
- 04
Eligible evidence follows the privacy setting
Full, anonymized, or off logging determines what, if anything, becomes durable activity for later review.
CLEAR BOUNDARIES
What protective DNS can and cannot establish
The DNS decision is valuable evidence at one layer of a connection, not a complete account of device or content safety.
- QueryWarden does not inspect page content, files, email bodies, or every URL path behind an allowed hostname.
- A permitted result does not certify that a destination is safe, and a block is not by itself proof that a device was compromised.
- Protective DNS is not a VPN, antivirus product, firewall appliance, EDR agent, or guarantee that every threat will be detected.
- QueryWarden currently publishes private DNS-over-HTTPS; public DNS-over-TLS and DNS-over-QUIC remain launch-gated.
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.
- NISTSP 800-81 Rev. 3 — Secure DNS Deployment Guide (opens in a new tab)Current deployment guidance for DNS security, encrypted DNS, policy enforcement, and DNS evidence.
- NSA and CISASelecting a Protective DNS Service — June 2026 update (opens in a new tab)Describes protective DNS evaluation criteria, deployment models, response choices, and bypass limitations.
- UK NCSCProtective DNS for the private sector (opens in a new tab)Explains policy-based recursive DNS, deployment choices, logging, and investigation use cases.
What to know before you change DNS.
Is protective DNS the same as a firewall?
No. Protective DNS makes decisions about domain resolution. A network firewall can also control addresses, ports, protocols, and connection state, while endpoint tools can inspect behavior on the device.
Can protective DNS block phishing before a page opens?
It can block a hostname already identified by the applicable protection sources or policy before the destination connection. It cannot guarantee detection of every new, compromised, or same-domain phishing page.
Does QueryWarden need to retain every domain to protect it?
No. Protection happens in the live resolution path. Each profile separately chooses Full, Anonymized, or Off domain-level logging for durable history.
START WITH THE AVAILABLE FREE PLAN
Start with one private protective DNS endpoint.
The available Free plan protects one compatible device with one profile and up to 48 hours of history when full logging is selected.