Troubleshooting & FAQ

The issues that actually come up during rollout, in the order you're likely to hit them — plus the questions evaluators ask most.

Verifying protection is active

1. Check the dashboard. A device appears in your client list with live query telemetry as soon as it makes its first authenticated query. If it's listed and the query count is moving, the device is protected.
2. Check the profile (Apple fleets). On the device, confirm the Nantevo configuration profile is installed under Settings → General → VPN & Device Management. An installed profile configures DoH at the OS level, silently.
3. Check filtering. Blocked domains answer NXDOMAIN. Attempting to resolve a domain your policy blocks (an ad or tracker domain under default policy) should fail to resolve, and the block event appears in the dashboard's blocked-events list with the device attributed.

Device enrolled but not appearing in the dashboard

• No query yet. Attribution is per-query; a device that hasn't resolved anything won't have telemetry. Open any website or app on it.
• Profile not actually installed. An MDM push that's pending or declined leaves the device on its previous resolver. Verify installation state in your MDM console and on the device.
• Port 443 egress blocked. DoH rides HTTPS. If a network segment blocks outbound 443 to the endpoint, resolution falls back per OS behavior and the device stays silent in telemetry. Confirm the device can reach its assigned endpoint over HTTPS.
• Wrong profile / revoked credential. A revoked or mismatched credential pair receives no response by design (silent drop). Re-issue the profile from the dashboard and push again.

Browser DoH conflicts

Chrome, Firefox, Brave, and Edge each ship their own DoH ("secure DNS") implementations that can bypass the system resolver — this is the Encrypted DNS Gap.

• Managed Apple devices: no action needed. The MDM-installed OS-level DoH configuration takes precedence over browser DoH, so browser traffic is covered automatically.
• Unmanaged devices: either disable the browser's built-in secure DNS so the OS configuration applies, or configure the browser's custom DoH provider with the endpoint shown in your dashboard.
• Diagnosing: if a device shows some queries in the dashboard but browser activity is missing, the browser is resolving through its own DoH provider. Fix per above.

Captive portals (hotels, airports, cafés)

Captive portals intercept DNS to redirect you to a login page — which encrypted DNS is specifically designed to prevent. Symptoms: the portal page never loads on a freshly joined network.

• Modern OSes detect captive portals through dedicated probe mechanisms and handle portal login before normal traffic flows; on most networks this resolves itself within a few seconds of joining.
• If the portal never appears, open the portal address directly if the venue posts one, or briefly toggle Wi-Fi off and on to re-trigger the OS captive-portal probe.
• Once the portal grants access, DoH resumes automatically — no re-enrollment or profile change is ever needed.

Forwarder (nantevo-fwd) issues

• A device gets SERVFAIL for everything. That's fail-closed working as intended: the source IP has no client mapping. Check the Unknown Devices dashboard view, then add a mapping (static IP or DHCP reservation) for the device.
• A device's identity changed. Attribution is source-IP based. If DHCP reassigned the address, telemetry follows the IP, not the hardware — use DHCP reservations for anything you want stable attribution on.
• Startup stalls. The forwarder makes exactly one plaintext DNS query at boot to resolve its own DoH endpoint. If host firewall rules block that bootstrap resolution, startup can't complete. Permit the initial resolution path.
• Strict DNSSEC returning SERVFAIL. In dnssec: strict mode, validation failures fail closed by design. If a domain you need is failing validation, verify with the domain owner or switch that deployment to opportunistic.
• Watching it live: journalctl -u nantevo-fwd -f (Linux) or syslog (FreeBSD), the /dashboard query log, and Prometheus at /metrics.

Frequently asked questions

Does Nantevo see or store our source IPs?

Client IPs are used transiently for routing and rate limiting and are not written to telemetry records. On-premise deployments never send query data to Nantevo at all — only anonymized RoCi threat signals leave your network.

What exactly is in the logs?

Timestamp, authenticated client ID, queried domain, response code, latency, and threat classification, with configurable retention (90-day default for query telemetry, 12 months for RoCi incident records). Details in Logging & retention and the privacy policy.

Can RoCi slow down our DNS?

No — architecturally, not just operationally. RoCi analyzes the log stream after responses are delivered and is never in the query path. Its detections update the synchronous threat feed that the resolver consults inline.

How do we revoke a lost or compromised device?

Revoke the credential in the dashboard. Enforcement happens at the proxy immediately — the device's endpoint + ClientID pair simply stops resolving. No device access, MDM push, or user action is required.

What happens during an upstream CDN incident?

Cloud deployments depend on upstream infrastructure, and incidents are disclosed transparently on the status page (including upstream events). On-premise deployments resolve locally and are unaffected by CDN outages. If that failure mode matters to your environment, the on-premise model exists for exactly this reason.

Is there an SLA?

Business-tier agreements carry a 99.9% uptime SLA; enterprise terms are negotiated per contract. See pricing.

Something else?

Email [email protected] — technical questions get answered by the engineer who built the platform, typically same business day.