Policy at the network resolver path
Compatible infrastructure can direct participating LAN clients through one network endpoint instead of configuring a separate DoH app on every stationary device.
NETWORK DNS FILTERING
Apply one DNS policy path to a controlled network.
A router or local forwarder can send LAN DNS through QueryWarden when it accepts a complete custom DNS-over-HTTPS URL. Networks without that capability can evaluate QueryWarden Relay, an unsigned Linux technical preview that requires a maintained host and deliberate local deployment.
Direct router setup requires full custom-DoH URL support QueryWarden Relay is an unsigned Linux beta Live verification should precede broad LAN rollout
DNS decision pathIllustrative request
Device
Private DoH
QueryWarden policy
Allowed destination
Policy checked before connectionDecision evidence is reviewable when the profile retains it.
TWO DEPLOYMENT PATHS
Use direct custom DoH where it exists; use Relay only with its beta boundary understood.
Router firmware differs substantially. QueryWarden therefore treats direct router support as conditional, while Relay provides a credential-bound local forwarding option for an operator prepared to maintain a supported Linux host.
Controls you can use and verify.
Each capability below reflects the current public product, with beta and compatibility limits called out separately.
Relay for evaluated Linux networks
The beta Relay uses a credential-bound enrollment and local DNS listener where the router itself cannot accept a private custom-DoH URL.
Verification before expansion
Fresh endpoint or Relay activity can be checked on one controlled LAN client before DHCP or router settings affect the wider network.
A dedicated network profile
The network endpoint can receive its intended filtering, schedule, custom-rule, and privacy policy without reusing a personal endpoint broadly.
Confirm the network path before promising network-wide coverage.
A router deployment protects only clients whose DNS requests actually follow that path. Use a direct custom-DoH configuration when the router accepts the full private URL; otherwise evaluate the unsigned Linux Relay beta on a maintained local host.
Open full-size screenshot Two current network paths
- 01LAN client
Uses resolver settings supplied by the network and has not selected a bypassing resolver.
- 02Compatible router or Relay beta
The router sends the full private DoH URL directly, or a maintained Linux Relay receives local DNS first.
- 03Private QueryWarden endpoint
Authorizes the deployment and selects its protection and privacy profile.
- 04Policy-controlled DNS result
The answer returns along the configured path; roaming devices need their own compatible setup away from this network.
Router and LAN readiness checklist
| Check | Why it matters | QueryWarden decision |
|---|---|---|
| Complete custom DoH URL field | A plain DNS IP or provider-hostname field cannot carry the private HTTPS endpoint. | Use direct router setup only when the entire URL is accepted. |
| LAN DNS distribution | DHCP and IPv6 router advertisements can send different resolver settings. | Verify both IPv4 and IPv6 clients after the change. |
| Client overrides and VPNs | Applications, operating systems, or tunnels can choose another resolver. | Treat bypass control as a network responsibility, not a QueryWarden guarantee. |
| Failure and rollback behavior | Some routers silently fall back to an alternate resolver. | Test resolver failure and preserve a documented rollback path. |
| Maintained Linux host | Relay needs a supported local host, updates, logs, and operational ownership. | Use Relay only with its beta and unsigned status understood. |
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
Inspect actual router and network capabilities
Confirm whether the firmware accepts a complete custom DoH URL; a nameserver IP or DNS-over-TLS hostname field is not equivalent.
- 02
Choose direct DoH or the Relay beta
Prefer the documented direct path when supported. Choose Relay only when a maintained supported Linux host and beta operating boundary are acceptable.
- 03
Create a dedicated network endpoint and policy
Do not reuse a private personal-device URL across an unmanaged LAN; give the network a deliberate identity and profile.
- 04
Test one client, fallback, DHCP, and IPv6 behavior
Confirm fresh traffic and the expected failure mode before changing the wider network or treating every connected device as covered.
CLEAR BOUNDARIES
Network-wide does not mean every device is always covered
Coverage depends on the actual DNS path chosen by each client and the operational state of the router, forwarder, or beta Relay.
- A device can bypass the network resolver through its own VPN, encrypted DNS setting, hard-coded resolver, mobile connection, or another network path.
- A router endpoint can aggregate many LAN clients as one QueryWarden endpoint; individual device attribution may not be available from DNS alone.
- QueryWarden has not certified every router or Linux distribution, and Relay is an unsigned technical preview rather than a signed managed appliance.
- There is no public native roaming client today, and multi-origin high availability remains launch-gated rather than a standard uptime claim.
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.
- UK NCSCProtective DNS for the private sector (opens in a new tab)Explains policy-based recursive DNS, deployment choices, logging, and investigation use cases.
- 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.
What to know before you change DNS.
Will QueryWarden work with every router?
No. Direct setup requires a field documented to accept a complete custom DNS-over-HTTPS URL. Routers limited to DNS IP addresses, fixed providers, or DNS-over-TLS hostnames cannot use the private URL directly.
What is QueryWarden Relay?
Relay is an unsigned Linux beta that enrolls as a credential-bound network endpoint and forwards local DNS through QueryWarden. It requires a maintained supported host and careful listener, router, or DHCP configuration.
Does router setup protect a laptop when it leaves the network?
No. The network policy applies only while traffic uses that configured network path. QueryWarden does not currently provide a public native roaming client for protection away from it.
START WITH THE AVAILABLE FREE PLAN
Validate the network path before changing the whole LAN.
Review router compatibility or the Relay beta, create a dedicated endpoint, and confirm one controlled client first.