Security Model
ClearDNS's accountless architecture does not remove authentication. It moves authentication away from a conventional email/password account and divides authority across narrower objects:
- internal policy/member/device identity;
- Resolver Credential V1;
- authoritative binding state;
- temporary dashboard sessions;
- temporary invitations;
- configuration/recovery artifacts.
A security review should evaluate those boundaries separately. The request path itself decomposes into four distinct questions:
Authentication Is the transport credential authentic?
Binding Which current policy/member/device relationship does it represent?
Authorization What service or administrative authority does that relationship currently have?
Policy evaluation What DNS response should this DNS request receive?Passing one stage does not automatically grant the next.
Boundary 1: internal identifiers#
Policy IDs and Device IDs include structural check letters. Those checks help reject malformed identity values. They are not cryptographic authentication and are not treated as secrets.
Boundary 2: Resolver Credential V1#
Internal identity is encoded into a separate 33-letter canonical transport form. A private server-held HMAC key determines the exact capitalization pattern.
The resolver:
- validates wire shape;
- authenticates exact case;
- decodes the canonical value;
- reconstructs and validates internal IDs;
- verifies binding/policy authority.
Wrong-case and obsolete formats do not receive a compatibility bypass.
Boundary 3: transport confidentiality#
Resolver Credential V1 is carried over encrypted DNS. The mixed-case HMAC is not a replacement for TLS and is not intended to make an observed exact credential harmless. Resolver configuration artifacts must therefore be treated as sensitive.
The case mechanism adds authentication against malformed or case-normalized copies; transport encryption protects the resolver exchange on the network path. Encrypted DNS protects the DNS exchange itself: transport metadata can still reveal the resolver service being contacted, and device and configuration security remain part of the possession boundary.
Boundary 4: authoritative binding#
A validly decoded identity does not mean "this device is active forever." ClearDNS consults current binding and policy state, which allows device removal, device disablement, policy lifecycle enforcement, role changes, and exact-binding recovery rules.
This separates possession of an old configuration from current backend authority.
Boundary 5: DoT gateway compartmentalization#
The DNS-over-TLS gateway does not own Resolver Credential V1 identity decoding. It preserves the exact mixed-case credential and attests the gateway-to-resolver request, while the resolver remains the authority that holds the case-authentication capability and decodes the identity.
Compartmentalization reduces the number of components that need the identity-authentication secret.
Boundary 6: dashboard session#
A resolver credential is not the browser administration session. The dashboard creates separately limited session state and binds it to a policy/member/device relationship proven through the resolver path.
Authenticated dashboard APIs additionally enforce same-origin behavior, CSRF protection, session lifetime, role checks, policy scope, revocation, and active-session rules.
Boundary 7: enrollment capability#
A QR code or invitation link is a temporary bootstrap capability. It is randomly generated, time-bounded, purpose/role constrained, and single-use after acceptance. Successful enrollment creates a durable binding; the invitation itself does not become a permanent account credential.
Boundary 8: configuration artifacts#
Platform configuration artifacts may contain resolver-bearing information and must be handled more carefully than ordinary UI state. Where the ClearDNS app retains these artifacts, it uses platform secure storage rather than treating them as general analytics or preference values.
Artifact-recovery authority is a separate sensitive capability and should not be confused with a Policy ID.
DNSSEC handling#
ClearDNS delegates cryptographic DNSSEC validation to the validating upstream resolution paths it queries, and enforces that model in two ways. First, the client's checking-disabled (CD) bit is stripped before a query goes upstream, so validation cannot be switched off from the client side. Second, the DNSSEC-OK (DO) mechanism is supported so DNSSEC records can flow to clients that request them. ClearDNS does not perform its own independent signature validation at the edge; the accurate summary is enforced delegated validation, not independent validation.
Untrusted-input handling#
Upstream DNS responses are treated as untrusted input. Wire parsing is bounded and defensive: record and name lengths are checked against buffer limits, unexpected structure terminates parsing rather than being reinterpreted, and extension data from clients is sanitized (private options and client-subnet data stripped) before queries leave ClearDNS. A malformed response fails safe instead of becoming resolver state.
Fail-closed design#
ClearDNS uses fail-closed behavior at security-critical boundaries. Examples:
- missing Resolver Credential case-authentication capability does not disable case verification; service fails closed instead;
- malformed resolver identity does not fall back to legacy parsing;
- sensitive artifact issuance requires the intended binding to exist in authoritative state;
- ambiguous platform/binding state refuses artifact issuance rather than guessing;
- revoked session state does not become an anonymous administrative session.
Availability failures and authorization failures are different states and remain different in APIs: a temporarily unreachable authority is reported as unavailability, not converted into either access or permanent denial.
Device security remains part of the trust boundary#
ClearDNS can authenticate and authorize the configuration presented to its service, but it cannot make a fully compromised client device incapable of revealing locally available configuration or authenticated sessions. Protecting physical and administrative access to configured devices is therefore part of the security model, just as it is for passwords, browser cookies, VPN credentials and other locally held authentication material.
The positive architectural point is the credential surface ClearDNS removes: there is no separate ClearDNS username/password combination, no ClearDNS password-reset email, and no reusable ClearDNS password exposed to credential-stuffing attacks. Accountless does not mean credentialless; it changes which credentials must be protected and removes several conventional account attack surfaces.
Security and Privacy Contract#
ClearDNS is designed to enforce: exact Resolver Credential authentication before policy authority; current policy/member/device binding; browser-session authority separate from resolver transport; mandatory Dashboard security-factor satisfaction for established members, with Security PIN as the baseline credential and MFA as the interactive factor when enabled; server-side protection of Dashboard APIs until the resolved security requirement is satisfied; role preservation after factor satisfaction; revocation of prior factor-satisfaction state after a PIN change or reset; one-time PIN Recovery Code recovery without a support master PIN; no conventional ClearDNS password credential existing at all; billing identity never independently recovering policy authority; session revocation and policy-bound sessions; single-use, time-bounded enrollment capabilities; per-rail separation of retained data with the disclosures on the privacy page.
ClearDNS relies on: transport encryption between the device and the resolver; configured devices protecting locally held authentication and configuration material; browser and session security on administration devices; server-held authentication material remaining secret; the platform app stores for entitlement truth on store subscriptions; validating upstream resolution paths for DNSSEC validation.
ClearDNS does not claim: that DNS filtering controls traffic which never uses the configured resolver; that a fully compromised device cannot expose its configuration; that an exact copied resolver credential is harmless; that accountless means credentialless; that email/password account systems are universally less secure; that operational or network records can never constitute personal data; or 100 percent security of any kind.
Sensitive values and logs#
A recurring security rule is that possession-bearing values are not copied into ordinary logs. This includes, depending on context: resolver credentials, invitation capabilities, artifact-recovery capabilities, and configuration URLs that embed sensitive material.
Diagnostic messages prefer redacted, hashed or non-redeemable correlation values when a trace reference is necessary.
Security properties vs secrecy of implementation#
ClearDNS publishes the design properties necessary to understand its trust model. It does not publish every implementation detail. Withheld details include secret names/material, internal mint/recovery endpoints, anti-abuse thresholds, private infrastructure topology, proprietary intelligence source recipes, internal allowlists, scoring weights, and operational caches and dataset names.
Those details do not need to be public in order to explain the security contract.
Scope of case authentication#
The case-authentication layer protects representation integrity and defeats normalized-copy attacks: the resolver never accepts a credential whose case pattern does not match the server-derived expectation. An exact mixed-case copy is a different possession threat: because the authenticated case pattern is already present, that scenario is governed by device/configuration security and current server-side binding authority rather than by the case-authentication layer.
If an exact resolver credential is exposed, the response path is ClearDNS's device and configuration controls: creating a new device binding creates a new resolver identity and credential, and removing the old binding withdraws the previous configuration's authority. The case pattern is defense in depth, not secrecy.
Accountless does not mean unrecoverable by definition#
Recovery and identity are separate design questions. ClearDNS can support policy/device recovery through specific possession or platform-authority mechanisms without creating a permanent email/password account. A recovery mechanism exposes only the authority required for the recovery operation and does not silently turn a public Policy ID into a master key.
Threat-model summary#
| Threat / failure | What the design provides | Boundary that remains |
|---|---|---|
| Passive network observer | Encrypted DNS hides the query payload between device and resolver | The observer still sees that the device talks to ClearDNS, and destination-IP traffic after resolution |
| Case-normalized or malformed credential | HMAC-derived exact-case authentication rejects it before any state | An exact-case copy is not detected by this layer |
| Exact copied Resolver Credential | Resolver possession under the copied binding only; established Dashboard administration still requires an authenticated browser session and satisfaction of the session's current Dashboard security requirement | The copied credential resolves DNS until the binding is removed or replaced, and alone is not sufficient for established Dashboard administration |
| Legacy resolver identity presented | Strict rejection, no fallback parser | none |
| Public Policy ID observed/guessed | Not sufficient for dashboard authorization or artifact recovery | It identifies the policy but does not grant resolver or Dashboard authorization |
| Removed/stale device configuration | Current binding authority withdraws service | Configuration bytes still exist on the old device |
| Stolen browser session before security-factor satisfaction | A valid base Dashboard session context only; protected Dashboard functionality remains unavailable until the session's resolved security requirement is satisfied | The base session context is still short-lived, revocable and subject to expiry |
| Stolen factor-satisfied browser session | The authority already present in that authenticated and factor-satisfied session, limited by the binding's existing role and session controls | No stronger role is created by factor satisfaction itself; session expiry, revocation, role checks and other authorization boundaries continue to apply |
| Copied invitation link | Time-bounded, single-use acceptance | Valid until first use or expiry; treat as sensitive while live |
| Retry during enrollment | Convergence on the exact claimed tuple | none |
| Sensitive capability in logs | Redaction and non-redeemable correlation rules | none |
| Upstream resolution path | Sees the DNS question on cache miss, arriving from ClearDNS infrastructure; the original client IP, identifiers and credential are not forwarded | The question itself is visible to the upstream resolver |
Related technical references#
- Identity and Resolver Credentials
- Accountless Dashboard Authentication
- Device and Member Enrollment
- Privacy and Observability
Ready to try ClearDNS?
Private DNS protection without a conventional account.