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 15.52ms — production average.

Every authenticated DNS query follows this path — from the device through the authentication layer, into the resolver, through RoCi's threat analysis, and back. 15.52ms is the measured production average across 2.5 years of live operation. 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. Production average: 15.52ms total round trip — measured across 2.5 years of live operation.

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://r7mxk4bqe9yzw2nt6p3dh8f5a.nantevo.com/q/{clientID}
Content-Type: application/dns-message
HTTP/2 · TLS 1.3 encrypted
↓ request arrives at edge
Reverse Proxy — nginx virtual host
vhost: r7mxk4bqe9yzw2nt6p3dh8f5a.nantevo.com
location: ~ ^/q/{clientID}$
match result: → proxy_pass to resolver
no match: → 444 · silent drop · no response
↓ only authenticated queries proceed
DNS Resolver
receives query with client identity attached
applies per-client filtering policy
resolves domain · returns response
logs metadata with 1:1 device attribution
01

The endpoint subdomain is the first factor

Each client receives a unique high-entropy subdomain — a randomly generated 25-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 removes the virtual host — the endpoint ceases to exist

Revoking a client means removing their nginx virtual host configuration and reloading nginx. The subdomain stops responding to anything — there is no location block left to match. No device action required, no MDM push, no agent to uninstall. The endpoint simply ceases to exist at the infrastructure layer.

05

Every query carries 1:1 device attribution — regardless of network

Because identity is structural — embedded in the virtual host and location block configuration rather than derived from IP address — the authenticated ClientID travels with every query on any network. When RoCi detects a threat, the SOC receives the exact device identity immediately. No VPN logs, no DHCP correlation, no manual reconstruction. MTTR is limited by reading speed, not data availability.

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: r7mxk4bqe9yzw2nt6p3dh8f5a.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:f8qr2ym6xjd3nt9vc5pw4kzbe 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 matches nginx virtual host; ClientID matches location block exactly

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 — production avg 15.52ms total round trip

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.
CIA triad mapping

Confidentiality, Integrity,
Availability — addressed at the DNS layer.

Enterprise security audits and compliance frameworks evaluate solutions against the CIA triad. Nantevo's architecture addresses all three independently — each layer effective on its own, stronger in combination. This is Defense in Depth at the DNS resolution layer, aligned to NIST SP 800-81r3 (2025).

Confidentiality
DNS traffic encrypted.
Invisible to observers.

All DNS queries are encapsulated within standard HTTPS using TLS 1.3. Traffic originating from remote employees on untrusted hotel WiFi, satellite connections, or public networks remains completely confidential — ISPs cannot profile browsing habits, and man-in-the-middle observers see only that a connection was made to a Nantevo endpoint, never its content.

→ DoH over TLS 1.3 — RFC 8484 compliant
→ No plaintext DNS after MDM profile enrollment
→ ISP profiling and MitM eavesdropping mitigated
→ 0% of roaming device DNS was encrypted pre-deployment
protocol: DoH · RFC 8484
transport: TLS 1.3
plaintext DNS: eliminated at enrollment
NIST SP 800-81r3 (2025) compliant
Integrity
Resolutions verified.
Spoofing prevented.

Strict TLS certificate validation ensures every device communicates exclusively with Nantevo's authorized resolver nodes — preventing DNS spoofing and cache poisoning attacks. The threat intelligence filtering layer actively maintains resolution integrity by sinkholing known malicious infrastructure before it can redirect users to fraudulent destinations. No silent redirects, no credential harvesting via DNS manipulation.

→ TLS certificate validation on every connection
→ DNSSEC validation on resolved records
→ Threat feed sinkholing prevents malicious redirects
→ Cache poisoning attacks structurally prevented
tls: strict cert validation
dnssec: enabled on resolver
sinkholing: malicious infra blocked
DNS spoofing: structurally prevented
Availability
99.97% uptime.
Zero-downtime maintenance.

Four geographically distributed resolver nodes across the US, each endpoint resolving to all active nodes simultaneously on IPv4 and IPv6. TTL-aware maintenance windows remove nodes from DNS rotation before maintenance begins — guaranteeing no client resolver holds a stale record. The result: 99.97% resolver availability across 2.5 years of production operation, with zero user-reported service interruptions beyond known CDN events.

→ 4-node geographic distribution — SFO, CHI, DFW, ATL
→ IPv4 + IPv6 on all nodes — implicit failover
→ TTL-aware maintenance — zero client disruption
→ On-premise appliance: CDN outages have zero impact
uptime: 99.97% · 2.5 years production
avg latency: 15.52ms measured
maintenance: zero-downtime by design
on-premise: fully CDN-independent

This CIA triad implementation aligns with NIST SP 800-81r3 (2025) — the current federal standard for Secure DNS Deployment — which frames encrypted DNS transport as essential for maintaining the integrity and confidentiality of the resolution process. The distributed availability architecture mirrors the deployment model recommended by the CISA Protective DNS Resolver for federal agencies. Together, they form a Defense in Depth security posture at the DNS layer.

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
San Francisco Bay Area Chicago Dallas Atlanta New York Area Los Angeles Seattle Miami Toronto Honolulu Mexico City São Paulo Santiago
Europe
London Amsterdam Frankfurt Paris Madrid Stockholm Warsaw Manchester
Middle East & Africa
Tel Aviv-Yafo Johannesburg
Asia Pacific
Tokyo Singapore Sydney Seoul Bangalore Mumbai Delhi NCR Melbourne 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.

Honest caveat

The Cloudflare dependency

Cloud-hosted resolution currently routes through Cloudflare's edge network. Major Cloudflare outages affect cloud-hosted resolution for the duration of the incident. This is the architectural motivation for the on-premise deployment model, where DNS resolution is entirely independent of any CDN, and for the multi-CDN redundancy on the infrastructure roadmap.

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 a 15.52ms production average query response time and 99.97% resolver availability across 2.5 years of continuous 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.

Queried domain logged — essential for security telemetry

The domain name being resolved is part of standard telemetry alongside timestamp, client ID, response code, latency, and threat classification. This is what enables blocked domain event lists, RoCi's DGA analysis, and per-client behavioral baselines. Source IP addresses are not retained — used transiently for routing only.

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 →