Architecture & security reference

A consolidated technical reference for evaluators: how Nantevo authenticates DNS at the transport layer without endpoint software, where your queries travel under each deployment model, exactly what is logged, and how the RoCi analysis engine relates to the query path.

Authentication model

Nantevo authenticates every DNS-over-HTTPS query before it reaches a resolver, using a credential pair embedded in the request itself rather than software installed on the device:

• Endpoint subdomain — each client is issued a unique 25-character, high-entropy DoH endpoint ({endpoint}.nantevo.com).
• ClientID — a second 25-character credential bound to that endpoint, carried in the request path ({endpoint}.nantevo.com/{clientID}).

Each credential is drawn from a 25-character lowercase-alphanumeric space — log₂(36²⁵) ≈ 129 bits of entropy per field — and both must match. The reverse proxy validates the pair before routing anything to the resolver. Requests that fail validation receive no response at all: a silent drop, not an error, so probing yields no oracle signal.

Because identity lives in the transport layer, revocation happens at the proxy — a revoked credential stops resolving immediately, with no action required on the device.

The query path

device
  → DoH over TLS 1.3 (RFC 8484)
  → reverse proxy — endpoint + ClientID validated   (pre-resolver)
  → resolver — threat feed consulted, policy applied
  → response returned to device                      (~16ms production average)
  → telemetry log stream → RoCi                      (asynchronous, never in path)

Two properties follow from this design:

• 1:1 attribution. Every query carries an authenticated client identity, so telemetry is scoped to the individual device — no VPN correlation or reverse-IP guesswork during incident response.
• Latency isolation. Nothing in the analysis layer can add latency to resolution, because analysis happens after the response is already delivered (see RoCi).

Deployment models

The same authentication architecture and RoCi intelligence operate across all three models. What changes is where the resolver runs and where queries travel.

On-premise deployments resolve locally at sub-10 ms on-network, and upstream CDN outages have no impact on resolution.

Platform coverage

Logging & retention

Enterprise security teams need logs; the policy is designed to give you full telemetry with explicit boundaries.

What is logged, per query

• Timestamp, authenticated client ID, queried domain, response code, resolution latency, and threat classification.
• The domain is essential — it powers blocked-event lists, RoCi's DGA entropy scoring, per-client behavioral baselines, and incident forensics.

What is not

• Source IP addresses are not retained. They are used transiently for routing and rate limiting only and are not written to telemetry records.
• No third-party sharing, ever. Telemetry is never shared with, sold to, or accessible by any third party — not for advertising, profiling, or aggregated threat intelligence.

Retention

On-premise deployments keep all query data inside your network boundary. See the privacy policy for the complete data inventory.

RoCi analysis

RoCi never touches a live query. It analyzes the telemetry log stream asynchronously — after responses are already delivered. This is an architectural commitment: DNS resolution latency is a hard constraint, AI inference is not, so inference is kept out of the query path entirely.

What it looks for:

• DGA patterns — subdomain entropy scoring identifies domain-generation-algorithm infrastructure used in ransomware staging and C2.
• C2 beaconing — periodic query timing to novel infrastructure, characteristic of botnet check-ins.
• DNS tunneling — anomalous TXT record volumes and high-frequency lookups to newly registered domains.

When RoCi confirms a detection, it pushes a block rule to the synchronous threat feed that the resolver consults inline — so the asynchronous engine hardens the synchronous path for every client, without ever sitting in it. Each detection carries the exact device, timestamp, and domain.

Framework alignment

• NSA / CISA PDNS guidance (2021) — architecture aligned with the joint advisory recommending Protective DNS.
• NIST SP 800-81r3 (2026) — encrypted DNS transport per NIST's current Secure DNS Deployment guidance; RFC 8484 DoH enforced on enrolled devices. SP 800-81r3 explicitly identifies the DNS service as a Zero Trust policy enforcement point.
• NIST SP 800-207 — every request authenticated; no network implicitly trusted.
• Certifications — SOC 2 Type II is in scoping; FedRAMP and ISO 27001 are on the roadmap. Current status is always listed on the security page.