nantevo → How it works

The architecture behind
zero-agent DNS authentication.

A technical walkthrough of how Nantevo authenticates every DNS-over-HTTPS query at the transport layer — without installing software on any device. From credential generation to threat detection, every step explained.

End-to-end query flow

A DNS query, authenticated and resolved
in under 50 milliseconds.

Every authenticated DNS query follows this path — from the device through the authentication layer, into the resolver, through RoCi's threat analysis, and back. Click play to watch it happen.

DevicemacOS · iOS
Windows · Android
DoH request
Reverse ProxyAuth layer
credential check
verified
DNS Resolverresolution +
threat filter
RoCi analysis
RoCi AIbehavioral
analysis
01 — Device

Encrypted DoH request

Device sends DNS query over HTTPS to its assigned high-entropy endpoint. All traffic is encrypted. No plaintext DNS leaves the device.

02 — Proxy

Credential validation

Reverse proxy extracts the endpoint subdomain and ClientID. Both are validated before the request proceeds. Unrecognized credentials receive no response.

03 — Resolver

DNS resolution + filtering

Authenticated query reaches the resolver. Domain is checked against threat intelligence feeds. Malicious domains are blocked before resolution completes.

04 — RoCi

Behavioral analysis

Query metadata is scored against the client's behavioral baseline. Anomalies are flagged. Threat classifications are logged to the per-client telemetry dashboard.

05 — Response

Encrypted response returned

Clean response is returned to the device over the same encrypted DoH channel. Total round-trip time under 50ms on cloud infrastructure.

Click play to animate the query flow
Authentication mechanism

How a URL becomes an identity.

Traditional DoH is unauthenticated by design — the resolver answers any query that reaches it. Nantevo changes this by embedding identity into the endpoint structure itself, validated before the resolver ever sees the request.

Authentication flow at the proxy layer
Device
POST https://ed5491583e45eba7b4778cd.nantevo.com/q/{clientID}
Content-Type: application/dns-message
HTTP/2 · TLS 1.3 encrypted
↓ request arrives at edge
Reverse Proxy — authentication layer
extract endpoint: ed5491583e45eba7b4778cd
extract clientID: {clientID}
lookup: credential pair in keystore

if valid: → forward to resolver
if invalid: → drop · no response · no error
↓ only authenticated queries proceed
DNS Resolver
receives query with client identity attached
applies per-client filtering policy
resolves domain · returns response
logs metadata to per-client telemetry
01

The endpoint subdomain is the first factor

Each client receives a unique high-entropy subdomain — a randomly generated 23-character string that becomes part of their DoH URL. This subdomain is non-enumerable and non-guessable. Scanning or brute-forcing it is computationally infeasible.

02

The ClientID is the second factor

The ClientID is a second high-entropy identifier embedded in the request path. Both the subdomain and the ClientID must be present and valid — either alone is insufficient. The combination creates a credential pair with ~138 bits of effective entropy.

03

Validation happens before the resolver sees anything

The reverse proxy validates the credential pair on every request before routing to the DNS resolver. Unauthenticated requests receive no response at all — not a rejection, not an error, simply silence. This prevents fingerprinting or enumeration of the resolver infrastructure.

04

Revocation is instantaneous and requires no device action

Removing a credential pair from the keystore immediately blocks all further queries from that client — within the current connection's lifetime. No software to uninstall, no policy to push, no MDM action required. The credential simply stops being valid.

MDM enrollment

Zero-touch fleet deployment
in four steps.

For Apple device fleets, Nantevo's MDM profile generation pipeline takes the entire enrollment lifecycle from credential creation to system-wide DoH protection — without a single direct interaction with any device.

01

Generate a unique credential pair

The Nantevo dashboard generates a unique high-entropy endpoint subdomain and ClientID for the client group. Filtering policy, content categories, and RoCi sensitivity thresholds are configured at this stage — before any device is touched.

# credential generation endpoint: ed5491583e45eba7b4778cd.nantevo.com clientID: a7f3c91b2d8e4f6a policy: enterprise-strict roci: enabled · sensitivity: high
02

Auto-generate the MDM configuration profile

Nantevo generates a signed Apple MDM configuration profile (.mobileconfig) containing the unique DoH endpoint URL, the ClientID credential, and the DNS-over-HTTPS resolver configuration. The profile is ready to deploy immediately — no manual editing required.

<!-- .mobileconfig excerpt --> <key>DNSSettings</key> <dict> <key>DNSProtocol</key> <string>HTTPS</string> <key>ServerURL</key> <string>https://ed549...nantevo.com/q/{id}</string> </dict>
03

Push via your existing Apple MDM

The generated profile is deployed through your existing MDM infrastructure — Jamf, Kandji, Microsoft Intune, Mosyle, or any MDM that supports Apple configuration profiles. The profile installs silently at OS level. There is no user interaction, no permission prompt, and no visible change to the user experience.

# MDM push result profile: eng-fleet-01.mobileconfig scope: OS resolver — all processes status: installed · active visible: no user-facing change coverage: system-wide · immediate
04

Protection is immediate and system-wide

From the moment the profile installs, every DNS query from that device — from every application, background process, and system service — is routed through the authenticated Nantevo endpoint. The device begins appearing in per-client telemetry within seconds of the first query.

# first queries after enrollment ✓ client:eng-0x4f2a authenticated ✓ api.github.com → 140.82.112.3 9ms ✓ prod.datadog.com → 18.235.24.1 11ms ✓ telemetry logged to dashboard

Other platforms: Windows 11 supports native DoH configuration via Group Policy. Android devices enroll via the Intra app or native Private DNS settings. Browser-level DoH is supported in Chrome, Firefox, Brave, and Edge. Linux and BSD systems configure via stub resolver. Legacy infrastructure is handled through an on-premise DNS forwarder — see deployment models.

Query lifecycle

What happens inside every
DNS request.

From the moment an application makes a DNS lookup to the moment a response arrives, here is every step in sequence. Select a step to see the detail.

01

Application triggers DNS lookup

Any process on the device — browser, app, background service — requests name resolution

02

OS routes to authenticated DoH endpoint

MDM profile intercepts at OS resolver level, routing to the unique endpoint

03

Request encrypted over TLS 1.3

DNS payload wrapped in HTTPS — no plaintext DNS leaves the device at any point

04

Reverse proxy extracts and validates credentials

Endpoint subdomain + ClientID checked against keystore before proceeding

05

Per-client policy applied

Filtering categories, allowlist/blocklist overrides, and RoCi sensitivity loaded for this client

06

Domain checked against threat intelligence

Domain matched against live feed of known malicious, phishing, and C2 domains

07

DNS resolution performed

Clean queries are resolved recursively — authoritative response retrieved and cached

08

RoCi behavioral scoring

Query metadata scored against per-client baseline — anomalies flagged for review

09

Metadata logged to telemetry pipeline

Timestamp, client ID, response code, latency, and threat classification recorded

10

Encrypted response returned to device

IP address delivered over the same DoH channel — total round trip under 50ms

Deployment models

The same architecture,
three different data paths.

Nantevo's authentication architecture is identical across all three deployment models. What changes is where the resolver runs and where DNS queries travel — a decision driven by your infrastructure requirements, latency needs, and data residency constraints.

Model 01 — Cloud

Nantevo-hosted resolvers

Device
DoH over HTTPS
Nantevo reverse proxy
authenticated query
Nantevo resolver + RoCi
encrypted response
Device receives response
Queries pass through Nantevo cloud infrastructure. DNS content and metadata processed on Nantevo servers. Fastest to deploy.
Model 02 — Hybrid

Split resolver path

Device
DoH to customer subdomain
Customer DNS forwarder (DC)
internal: local resolver
external: Nantevo upstream
Nantevo resolver + RoCi
Internal domains resolve locally. External queries route to Nantevo. Custom subdomain endpoint (dns.yourdomain.com). Unified telemetry across both paths.
Model 03 — On-Premise

Air-gapped resolver

Device
DoH to customer subdomain
Nantevo appliance (your DC)
resolves locally
Queries never leave your network
RoCi signals only (no query data)
RoCi intelligence pipeline
DNS queries never leave your infrastructure. Only anonymized threat signals stream to RoCi. Sub-10ms response times on-network. CDN outages have zero impact.
Redundancy architecture

Distributed globally.
Resilient by design.

Every Nantevo DoH endpoint resolves to all active resolver nodes simultaneously — on both IPv4 and IPv6. Redundancy is built into the DNS layer itself: nodes are added and removed from rotation with TTL-aware precision, allowing zero-downtime maintenance and graceful failover with no client impact.

Global resolver network — deployment roadmap
Active now
Near-term expansion
Long-term global
Americas
Atlanta Chicago Dallas San Francisco Bay Area Los Angeles Miami New York Area Seattle Toronto Honolulu Mexico City Santiago São Paulo
Europe
Amsterdam London Madrid Paris Frankfurt Manchester Stockholm Warsaw
Middle East & Africa
Tel Aviv-Yafo Johannesburg
Asia Pacific
Seoul Singapore Sydney Tokyo Bangalore Delhi NCR Melbourne Mumbai Osaka
DNS-layer redundancy

Every endpoint resolves to all active nodes simultaneously

Each high-entropy DoH endpoint returns A and AAAA records for all active resolver nodes in rotation. Clients receive multiple addresses and connect to the nearest or most responsive — providing geographic distribution and implicit failover without a load balancer in the critical path.

TTL-aware failover

Node removal propagates before clients notice

When a node needs to be removed from rotation — for maintenance, an incident, or a scheduled upgrade — it is removed from DNS at least one full TTL period before any impact would occur. By the time the maintenance window begins, no client resolver has a cached record pointing to that node. Re-addition follows the same discipline in reverse.

Automated maintenance windows

Scheduled downtime coordinated with TTL precision

Maintenance windows are managed by automated processes that remove a node's DNS records ahead of the window and restore them on confirmed health. This eliminates human error from the most critical step — the timing of the DNS change — and is the operational mechanism behind near-100% resolution availability across two years of production operation.

TTL-aware maintenance window — step by step
T minus TTL
Remove node from DNS

Automated process removes the maintenance node's A and AAAA records from the endpoint DNS zone.

dns: remove CHI
records: A + AAAA
ttl: 60s remaining
T minus 0
All cached records expired

After one full TTL period, no client resolver holds a cached record for the removed node. Traffic has naturally shifted to remaining active nodes.

cached: 0 clients
active: SFO · DFW · ATL
client impact: none
Maintenance
Work performed safely

Update, restart, reconfigure, or replace the node with zero client impact. Resolution continues across remaining nodes uninterrupted.

node: CHI offline
resolution: 3-node
availability: 100%
Completion
Node re-added to rotation

On confirmed health, records are restored. Clients naturally begin resolving to the node again as their TTL cycles refresh.

dns: restore CHI
records: A + AAAA
active: all nodes

The current four-node US infrastructure has sustained sub-50ms response times and 99.97% resolver availability across two years of production operation — validating the redundancy architecture at scale before global expansion. Near-term expansion targets the highest-density enterprise markets, with full global coverage on the longer-term infrastructure roadmap.

A note on DNS privacy

The bootstrap resolver: one honest caveat

When a device first needs to reach its assigned Nantevo DoH endpoint, it must resolve the hostname of that endpoint using standard DNS. This initial lookup — typically a single query to the device's configured resolver — is the only DNS query that travels outside the encrypted channel.

This is a known characteristic of all DoH implementations, documented in RFC 8484. It is not a vulnerability — it reveals only that the device is resolving a hostname on nantevo.com, not what queries follow. All subsequent resolution is fully encrypted.

Hardening options

Eliminating the bootstrap lookup entirely

For high-security environments where even the bootstrap lookup is unacceptable, Nantevo MDM profiles can be generated with the resolver IP address hardcoded rather than using hostname resolution. This bypasses the bootstrap lookup entirely — the device connects directly to the IP without any prior DNS query.

On-premise deployments eliminate this consideration entirely — the appliance IP is known and local, and no external hostname resolution is required at any point in the query path.

ServerAddresses: ["203.0.113.42"]
ServerURL: https://ed5491...nantevo.com/q/{id}
# IP hardcoded — no bootstrap lookup

What Nantevo doesn't do

Explicit commitments on
what never happens.

Enterprise security buyers need to know not just what a platform does, but what it explicitly doesn't do. These are hard commitments, not marketing language.

No software installed on any device

Authentication lives in the transport layer. No agent, no kernel extension, no background service, no binary on any device at any point.

No query content logged by default

The actual domain being resolved is not stored in default configuration. Metadata only — timestamp, client ID, response code, latency, threat classification.

No third-party data sharing

Your DNS telemetry is never shared with, sold to, or accessible by any third party for any purpose. It is yours, for your security operations only.

No plaintext DNS on enrolled devices

OS-level DoH configuration means plaintext DNS cannot be sent by any application on the device after enrollment. System-wide, tamper-resistant.

No single point of failure for on-premise

On-premise deployments resolve DNS entirely within your infrastructure. A CDN outage, a Nantevo cloud event, or an internet disruption does not affect your DNS resolution.

No blind spots for BYOD or unmanaged devices

Any device that supports DoH — managed, unmanaged, or BYOD — can be enrolled. Coverage is not conditional on IT ownership of the endpoint.

Ready to see this architecture
protect a real fleet?

Live demo. Your devices. The authentication, the MDM enrollment, the telemetry — all of it, in under 60 seconds.

Request a demo Explore RoCi AI →