Identity and Resolver Credentials

ClearDNS separates internal operational identity from the credential presented to the DNS resolver.

That distinction is important. The internal identifiers organize a policy and its devices. Resolver Credential V1 is a separate per-device transport credential used on encrypted DNS transports. Neither should be confused with a person's real-world identity.

Identity vocabulary#

A ClearDNS device relationship contains three scopes:

Policy ID#

The Policy ID identifies a ClearDNS policy. It is a pseudonymous operational identifier, not a personal identifier and not a secret credential.

Member ID#

A separate middle identifier represents the member/user scope within a policy. It allows multiple people or logical members to exist under one policy without introducing an email/password account identity.

Device ID#

The Device ID identifies an individual device binding under a policy.

Internal identifiers include structural integrity checks, so malformed identifier values are rejected before any state authority is consulted. These checks are a validation convenience: they are not secrets and they are not the cryptographic security mechanism.

Why the internal identity is not sent directly#

Earlier generations of a DNS identity system could concatenate internal identifiers directly into a hostname or URL. ClearDNS does not do that in Resolver Credential V1.

Instead, the resolver wire carries a separate value: a per-device transport credential derived from the current pseudonymous policy/member/device binding and cryptographically authenticated by ClearDNS before it receives any authority. The credential must be preserved exactly as provisioned, including its exact lettering, and is treated as sensitive configuration.

The credential is not encryption and is not intended to conceal the pseudonymous operational identifiers; transport confidentiality comes from the encrypted DNS channel. The exact encoding and authentication construction are private implementation details and are deliberately not part of this public specification. What matters publicly is the contract: the resolver authenticates a presented credential before trusting it as a policy binding, an inexactly copied or modified credential does not authenticate, and an unauthenticated credential receives no policy authority.

Fail-closed behavior#

Resolver Credential V1 is a hard protocol boundary.

Malformed credentials, inexact copies, values outside the valid credential domain and obsolete identity formats are rejected rather than silently accepted through a legacy parser. If a required authentication capability is unavailable, credential authentication fails closed rather than skipping the check.

Derived, not a second identity database#

A device's Resolver Credential represents its current operational binding; it is not a separate human identity or account record.

Two consequences are useful to know as a user. Re-provisioning the same device's existing configuration is not a credential rotation. Creating a new device binding creates a new resolver identity and a new credential, and removing the old binding withdraws authority from every copy of the old credential.

Possession semantics#

Resolver Credential V1 uses the following possession model:

• the credential's usable lifetime is governed by the current binding's authority, not by anything inside the credential itself;
• an exact copied credential can be used for DNS resolution under the same operational binding until that binding's authority is withdrawn;
• the credential is provisioned as configuration for the operational device binding, so protecting the configured device and its configuration is part of protecting the credential;
• the exact resolver configuration is a sensitive possession artifact and must be protected like other security-sensitive device configuration; a Policy ID alone is not dashboard authorization;
• revocation works through binding authority: removing or disabling the device binding withdraws service from every copy of its credential.

Resolver-Verified Dashboard Access uses the authenticated resolver relationship to establish the operational identity for browser access. The Dashboard then validates the current binding and applies its own session, security and role requirements. For an established member, possession of the resolver credential does not satisfy the separate PIN or MFA requirement. The one-time first-use session before PIN enrollment is documented in Accountless Dashboard Authentication.

ClearDNS protects the server-side authority and authentication boundaries of the service; the user remains responsible for protecting access to the device and its locally provisioned resolver configuration, just as with other security-sensitive device configuration.

A different possession model#

Every usable identity system ultimately has something whose possession must be protected. Conventional services commonly ask users to protect an email account, a password, recovery channels and authenticated browser sessions. ClearDNS instead provisions an operational resolver identity to the configured device and does not require a separate ClearDNS email/password login.

An exact copy of sensitive ClearDNS resolver configuration must therefore be protected like other authentication material. If a device or environment containing that configuration is compromised, the configuration can potentially be copied; ClearDNS does not describe device compromise as impossible. The architectural difference is that ClearDNS does not additionally create a reusable email/password credential, a password-reset mailbox dependency or a credential-stuffing surface merely to administer DNS policy.

ClearDNS does not eliminate possession risk; it removes unnecessary identity layers around it.

How the possession model differs#

The comparison describes the credential and recovery surfaces required by each model; security ultimately depends on how those surfaces and the client device are protected. In many account-based services, compromise of the user's email account can become an account-recovery path because password-reset links are delivered to that mailbox; ClearDNS does not create a ClearDNS password-reset email flow because there is no conventional ClearDNS account password to reset.

Identifiers are not credentials#

Knowing a ClearDNS Policy ID, Member ID or Device ID is not equivalent to possessing the Resolver Credential or an authorized dashboard session. Those operational identifiers describe scope; they do not independently grant resolver or dashboard authority, and a usable Resolver Credential cannot be recreated from the visible operational identifiers.

Supported encrypted transports#

Supported encrypted DNS transports present the same per-device Resolver Credential in their provisioned configuration. Regardless of transport, the ClearDNS resolver remains the single authority that authenticates the credential and resolves it to a current binding; intermediate transport infrastructure is deliberately given less trust than the resolver itself. Configurations must preserve and present the provisioned credential exactly.

What Resolver Credential V1 is not#

It is not:

• an email-derived identifier;
• a username;
• a password;
• a public/private keypair;
• encryption of the DNS message;
• an encryption or confidentiality wrapper for the operational identifiers;
• a replacement for TLS;
• proof that a browser is authorized to administer a policy.

Dashboard authorization has its own session-binding mechanism.

Accountless Dashboard Authentication

Security properties at a glance#

Why ClearDNS documents this#

The accountless model should be technically explainable. "Anonymous token" is an incomplete description because it hides the distinction between an internal policy identity, a member scope, a device identity, a resolver transport credential, and an authenticated dashboard session. ClearDNS treats those as separate concepts.

Related technical references#

• Accountless Dashboard Authentication
• Device and Member Enrollment
• Security Model