Protected public edge
Cloudflare fronts the public service for TLS termination, DDoS mitigation, and web application protection. API and DNS origins are restricted to the trusted edge and use strict TLS to the origin.
Security practices · maintained by QueryWarden
Security you can inspect, not just a badge.
QueryWarden combines private encrypted DNS endpoints, scoped authorization, privacy-enforced event storage, and monitored recovery controls. This page describes the safeguards operating in the public beta and the limits of our claims.
A restricted path from the public edge to the resolver.
Public services are separated from private control surfaces, and each layer receives only the access it needs to perform its role.
Separated service boundaries
Application, database, resolver, and edge roles are separated by internal network boundaries. Workloads use read-only filesystems where practical, reduced Linux capabilities, and no-new-privileges controls.
Private resolver administration
DNS filtering runs behind a tenant-aware authorization gateway. Resolver administration is not exposed as a customer-facing public interface, and unknown private endpoints are rejected.
Encrypted and validated DNS
Devices can use private DNS-over-HTTPS endpoints. Resolver traffic uses encrypted upstream DNS, DNSSEC validation, and an independent encrypted fallback provider.
Identity and authorization are checked server-side.
Browser state is not authoritative. Sessions, resource ownership, roles, and endpoint access are evaluated by the service on every protected path.
Account sessions
Sign-up and sign-in use short-lived, single-use email links. Session identifiers are random and stored as hashes; production cookies are Secure, HttpOnly, host-only, and SameSite=Lax.
Administrative access
Service administrators must complete TOTP multi-factor authentication. Customer accounts currently use verified passwordless email, so we do not present MFA as available to every account.
Abuse resistance
Sensitive routes apply bounded request sizes, trusted-origin checks, route-specific rate limits, and human verification for public signup, passwordless sign-in, and unauthenticated contact requests. Authorization and session values are redacted from application logs.
Scoped authorization
Customer and organization resources are authorized from the active session or scoped token. Organization roles have explicit permissions, and administrative audit records are append-only at the database boundary.
Privacy settings change what reaches durable storage.
QueryWarden treats retention and anonymization as enforcement rules, not just dashboard preferences. Provider, transfer, and legal-basis details remain in the Privacy Policy.
Privacy before durable storage
Each profile can retain full domain history, retain anonymized aggregate activity, or turn domain-level logging off. Anonymized events omit hostname, endpoint attribution, and matched-rule detail; logging off prevents new durable DNS events for that profile.
Retention is enforced
Every retained DNS event receives an expiry no later than the account plan allows. A profile can shorten, never extend, that boundary. Reducing retention updates existing events, and the Privacy Receipt reports the effective state.
Limited network metadata
Durable DNS-event rows do not store source IP addresses. Limited source-IP and request metadata is still processed for endpoint authorization, abuse prevention, and service operations as described in the Privacy Policy.
Careful encryption claims
Off-site backups are encrypted, and sensitive credentials are encrypted or stored as one-way hashes where the design requires it. We do not use this page to make a blanket claim that every live database field has application-level encryption at rest.
Failure is planned for, monitored, and rehearsed.
Continuity controls preserve known-good authorization during bounded failures, while recovery checks test more than whether a backup file exists.
- 01
Resolver nodes accept bounded, signed policy snapshots and reject invalid, stale, or rolled-back revisions.
- 02
A verified last-known-good policy can continue through a temporary control-plane interruption; authorization fails closed after the snapshot expires.
- 03
Automated checks cover public API readiness, DNS authorization and filtering, certificate horizon, service health, storage capacity, and backup freshness.
- 04
Encrypted off-site backups run daily, and recurring isolated restore drills verify that database and resolver state can be recovered.
- 05
External monitoring observes the public path from a failure domain separate from the core service.
Multi-origin availability remains a launch-gated public capability. Unless a separate written SLA applies, this page does not promise a specific uptime level.
Claims and controls travel through the release process together.
Automated checks focus on security boundaries that can regress: authentication, isolation, privacy, secret handling, authorization, and recoverability.
Product-truth gates
A canonical capability registry distinguishes available, beta, planned, and launch-gated functionality. Build checks prevent selected gated features from silently appearing as generally available.
Security-focused automated tests
Release checks exercise sessions, trusted origins, tenant isolation, role denials, privacy modes, endpoint authorization, signed snapshots, secret handling, and webhook destination defenses.
Release and operations checks
The delivery process includes linting, production builds, dependency auditing, secret scanning, service readiness checks, DNS canaries, backup evidence, and rollback-aware deployment procedures.
CLEAR LIMITS
What this page does not claim.
Transparency includes saying where the current security boundary ends.
- DNS filtering is an additional security layer, not a VPN, antivirus, EDR, or guarantee that every threat will be detected.
- Customer-wide MFA, public DNS-over-TLS/QUIC, signed native clients, and a contractual uptime tier are not represented as generally available here.
- A passing automated check is evidence for a control at a point in time; it is not proof that a system can never be compromised.
RESPONSIBLE DISCLOSUREThe reporting form is opened by the QueryWarden application and uses human verification for public requests.
Found something that may put people or data at risk?
Send the minimum information needed to reproduce the concern through our protected form. Do not include passwords, complete private DNS endpoints, sign-in links, session cookies, recovery codes, API credentials, or unrelated customer data.
Good-faith testing boundaries
- Test only accounts, endpoints, and data you own or are explicitly authorized to use.
- Do not perform denial-of-service tests, disruptive high-volume scanning, social engineering, physical attacks, or actions that degrade service for other people.
- If you encounter customer data or a secret, stop, do not retain or share it, and report only the minimum evidence needed for us to investigate.
- Give us a reasonable opportunity to investigate and remediate before any public disclosure, and coordinate disclosure timing with us.
Publishing this policy or security.txt does not grant access to QueryWarden systems. We do not currently offer a monetary vulnerability bounty.
QueryWardenManaged DNS security
QueryWarden is operated and provided by Digiport OÜ, Viru väljak 2, Tallinn 10111, Estonia. Registration, VAT, and contact details are published in our Company details.