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 integrity checks that help reject malformed identity values early. Those checks are not cryptographic authentication and are not treated as secrets.

Boundary 2: Resolver Credential V1#

The wire credential is cryptographically authenticated by the resolver before it is trusted as a policy binding. An inexact, modified or obsolete-format credential does not authenticate, and an unauthenticated credential receives no policy authority. The exact construction and validation mechanics are private implementation details; the public contract is authentication before authority, with no compatibility bypass.

Boundary 3: transport confidentiality#

Resolver Credential V1 is carried over encrypted DNS. Credential authentication is not a replacement for TLS and is not intended to make an observed exact credential harmless: resolver configuration artifacts must be treated as sensitive.

Transport encryption protects the resolver exchange on the network path. 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 authenticated credential 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: transport infrastructure trust#

Intermediate transport infrastructure is deliberately given less trust than the resolver itself. Regardless of transport, the ClearDNS resolver remains the single authority that authenticates the credential and resolves it to a current binding. Reducing the number of components that hold authentication capability reduces the attack surface.

Boundary 6: dashboard session#

Resolver-Verified Dashboard Access establishes browser identity through the authenticated ClearDNS DNS relationship. The Dashboard validates the current policy/member/device binding and applies separate session, security-factor and role controls before granting administrative authority.

For established members, the PIN or MFA requirement is enforced separately from resolver possession, with applicable trusted-browser handling. The one-time initial session before PIN enrollment and the limits of session continuation are documented in Accountless Dashboard Authentication.

Authenticated Dashboard APIs enforce session validity, current binding authority, CSRF protection and policy scope. Resolver credentials, browser sessions and recovery grants remain distinct security objects.

Boundary 7: enrollment capability#

A QR code or invitation link is a temporary bootstrap capability. It is unpredictable, 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 uses validating upstream resolvers for DNSSEC validation. Before forwarding a query, ClearDNS clears the client's Checking Disabled (CD) flag so the client cannot request that upstream validation be skipped. The Dashboard does not expose a DNSSEC on/off control. Signature verification takes place at the upstream resolver; ClearDNS does not run a separate signature-validation engine at the edge.

CD flag in responses. The response returned to the client copies the CD flag exactly as the client sent it, as RFC 4035 section 3.2.2 requires, on every response path: freshly resolved, served from a ClearDNS cache, consolidated with an identical concurrent request, or generated by policy. That copy is a header contract only. It does not change the validation described above: a client that sets CD=1 receives the same validated answer as any other client, with its own CD flag copied back, and ClearDNS does not implement the remaining CD semantics of RFC 4035 under which a CD=1 client would receive unvalidated data.

Signed and unsigned domains. DNSSEC authenticates DNS data when a valid chain of trust exists. Unsigned domains and insecure delegations can still resolve, subject to the filtering policy, but their answers are not authenticated by DNSSEC. An unsigned domain is different from a signed domain with invalid or missing signatures. DNSSEC does not encrypt queries or establish that a domain is safe.

Validation failures. A validating upstream normally returns SERVFAIL when DNSSEC data is bogus. ClearDNS preserves that failure instead of retrying with validation disabled. SERVFAIL can also have causes unrelated to DNSSEC, so the response code alone does not identify a signature failure. Broken DNSSEC configurations can prevent resolution; unsigned domains are not rejected merely for lacking DNSSEC.

AD and DO flags. For forwarded binary DNS responses, ClearDNS preserves the upstream Authenticated Data (AD) flag. AD reflects the upstream resolver's authentication result, not an independent ClearDNS signature check or a filtering verdict. An unset AD flag alone does not prove that validation failed. The DNSSEC OK (DO) flag requests DNSSEC records in the response; it is not a validation-success signal. The legacy policy field named dnssecValidation controls whether ClearDNS forces DO on, while CD is cleared on the upstream query regardless of that field and copied back unchanged on the response to the client. The JSON response format does not expose AD or CD fields.

Negative answers and policy responses. Upstream validation also covers authenticated denial of existence for signed domains. ClearDNS forwards upstream negative answers and their available DNSSEC data. Responses generated by ClearDNS filtering, such as a blocked-domain NXDOMAIN, NODATA or sinkhole answer, are policy results. They do not carry AD or DNSSEC denial-of-existence proofs from the domain.

Multiple upstream paths. ClearDNS can use alternate upstream paths for resolution. Queries on those paths retain CD cleared. Upstream selection does not compare DNSSEC verdicts or require agreement between providers: the selected response supplies the validation outcome. A returned SERVFAIL is not treated as permission to disable validation.

Untrusted-input handling#

Upstream DNS responses are treated as untrusted input: parsing is bounded and defensive, unexpected structure fails safe instead of becoming resolver state, and client-supplied extension data is sanitized before queries leave ClearDNS.

Fail-closed design#

ClearDNS uses fail-closed behavior at security-critical boundaries. Examples:

• a missing authentication capability does not disable authentication; service fails closed instead;
• a 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: 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; PIN Recovery Codes as the supported PIN-recovery mechanism, 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, credential construction and validation mechanics, 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.

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.

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.

Policy Recovery security boundary#

Policy Recovery is owner-only and multi-factor by construction, and it is scoped so that a successful recovery cannot become general authority:

• possession of the Policy Recovery Code alone is insufficient; the owner's current security factor (Security PIN, or MFA when enabled) is also required;
• the Policy ID is not a secret and is not, by itself, recovery authority;
• MFA cannot be downgraded to PIN during recovery; an MFA-mode owner must satisfy MFA;
• a successful recovery yields only single-purpose authority to provision a new device into the one matched, eligible policy. It is not an ordinary dashboard session: it cannot edit policy settings, change the PIN, disable MFA, recover a different policy, or return another device's resolver artifacts;
• a destroyed policy is terminal and is never recoverable;
• recovery secrets never appear in URLs or logs, the endpoint is rate-limited and source-abuse protected, and uncertain state fails closed.

The Policy Recovery Code is a distinct credential from the PIN Recovery Codes and the MFA Backup Codes; none is ever repurposed for another. Exact token, storage and rate-limit internals are outside this public specification.

Threat-model summary#

Related technical references#

• Identity and Resolver Credentials
• Accountless Dashboard Authentication
• Device and Member Enrollment
• Identity Lifecycle and Recovery
• Privacy and Observability