On-premise forwarder

nantevo-fwd ForWarDer · FireWall DNS

A standalone DNS-to-DoH secure forwarder — written in Rust — that brings the full Nantevo Zero Trust DNS stack to server fleets, legacy hardware, IoT devices, and anything else that speaks plaintext DNS. No agents. No device changes. Full per-device attribution.

fwd
ForWarDer
plaintext DNS → authenticated DoH
fwd
FireWall DNS
1.18M domains · 15M IPs blocked locally
Request a demo See the architecture →
nantevo-fwd · 0.0.0.0:53 · fleet overview
▪ Fleet Overview
◈ Threat Events
◎ Protection
≡ Query Log
? Unknown Devices
Active
0.0.0.0:53
12 clients enrolled
Fleet Overview
Total Queries
290
TIF Blocks
0
Avg Latency
116ms
CLIENTQUERIESBLOCKEDTIFAVG LAT
mixpost
10.17.89.18
11000108ms
conduit
10.17.89.66
11700166ms
nantevo
10.17.89.53
300029ms
synapse
10.17.89.44
———offline
1.18M
Domain blocklist entries loaded
HaGeZi TIF · refreshes every 24h
15.16M
IPv4 addresses covered by IP blocklist
Spamhaus DROP · 58K exact + CIDR expansion
2.29M
Newly registered domains tracked
Stamus NRD · flag only · never blocked
~300MB
Memory footprint at full load
Rust · zero GC pauses · single binary
Device coverage

Every device on your network.
Even the ones that can't run software.

nantevo-fwd accepts plaintext DNS on UDP and TCP port 53 and maps each source IP to a unique Nantevo DoH upstream. Static IPs and DHCP reservations give you per-device attribution on hardware that has never heard of DoH — and never needs to.

Server fleets

Linux, FreeBSD, and Windows servers. Static IPs map directly to unique Nantevo DoH upstreams. Full query telemetry, per-server blocking, and RoCi behavioral attribution — without touching a single server config.

Static IP mapping

Legacy hardware

Printers, SCADA systems, PLCs, network appliances, medical devices, building management controllers. If it sends DNS queries, nantevo-fwd intercepts and routes them through your authenticated Nantevo endpoint.

No device changes required

IoT and OT fleets

IP cameras, smart building sensors, industrial controllers, IoT gateways. DHCP reservations give each device a predictable IP and therefore a unique authenticated Nantevo identity. Full attribution, no agents.

DHCP reservation mapping
Local threat intelligence

Three independent blocking layers.
All enforced before the query leaves your network.

nantevo-fwd filters locally — before forwarding to Nantevo upstream. Your devices are protected even during the forwarding hop. Three independent threat intelligence sources, each targeting a different attack surface.

Domain blocklist — TIF
1,185,391
HaGeZi Threat Intelligence Feed. Malware, C2, phishing, and tracking domains blocked at DNS resolution time.
1 source · refreshes every 24h
Block response: NXDOMAIN
IP reputation — DROP + XBL
15,163,255
Spamhaus DROP (hijacked netblocks) + XBL DQS (real-time botnet and compromised host lookup). Blocks DNS responses that resolve to known malicious infrastructure.
58,231 exact IPs · 1,714 CIDR ranges
15,105,024 IPv4 from CIDRs · +96 IPv6 subnets
NRD observe — Stamus DGA
2,294,186
Newly Registered Domain tracking by Stamus Networks. DGA and phishing domain flagging — observe mode only, never blocked. Surfaces suspicious resolution patterns to RoCi for behavioral analysis.
2 sources · flag only · never silently blocked
Feeds RoCi async analysis pipeline
Severity hierarchy — highest to lowest
Critical
XBL
Real-time botnet lookup · compromised hosts
→
High
DROP
Hijacked netblocks · malicious ASNs
→
Medium
TIF
Domain blocklist · malware C2
→
Policy
Cloud
Nantevo upstream policy block
Platform capabilities

Everything a security-first DNS
forwarder should do.

Zero Trust Architecture

Fail closed — unmapped clients get SERVFAIL

Any source IP without a configured client mapping receives SERVFAIL. No silent forwarding, no fallback to an unprotected resolver. Devices that aren't enrolled cannot resolve DNS — period. The Unknown Devices dashboard surfaces any device that attempts a query without a mapping.

# Unmapped source IP → immediate SERVFAIL
# No forwarding · no logging · no oracle signal
client 10.17.89.53 → nantevo-endpoint-A
client 10.17.89.18 → nantevo-endpoint-B
10.17.89.99 → SERVFAIL (not enrolled)
Safe Search Enforcement

Six search engines — moderate or strict

DNS-level safe search enforcement rewrites resolution for Google, YouTube, Bing, DuckDuckGo, Yandex, Qwant, and Pixabay to their respective safe search endpoints. Configured once on the forwarder — applies to every device on the network including those that can't be individually configured.

safe_search: strict
# Enforces: google · youtube · bing
# duckduckgo · yandex
# qwant · pixabay
Privacy Architecture

RFC 8484 / RFC 8467 — full privacy stack

User agent suppressed. No compression hints. Cache-Control: no-store. EDNS body padding per RFC 8467. HTTP/2 multiplexing with frame padding. Randomized query IDs. ECS stripping. DNS rebinding protection blocks responses resolving public domains to private addresses.

strip_ecs: true
edns_padding: RFC8467
rebind_protection: enabled
user_agent: suppressed
http2_frame_padding: enabled
Caching + Prefetch

Per-client cache with intelligent prefetching

Each enrolled client gets an independent cache with configurable TTL bounds. Prefetching refreshes popular records before they expire, keeping cache hit rates high and latency consistently low. The Fleet Overview dashboard shows per-client cache hit rates and latency distributions in real time.

cache: per_client
prefetch: enabled
max_ttl: 3600s
# fleet avg cache hit: ~71%
# p95 latency: 477ms (warm cache: <5ms)
DNSSEC

Off, opportunistic, or strict validation

Three DNSSEC modes selectable per deployment. Strict mode validates all responses and fails closed on validation errors. Opportunistic mode validates where supported and passes through unsigned records. RRSIG consistency checks run locally before responses are served from cache.

dnssec: opportunistic
# modes: off | opportunistic | strict
# RRSIG consistency: enabled
# validation failures: SERVFAIL
Observability

Native Prometheus export + live dashboard

Every metric the forwarder tracks is exported natively to Prometheus — per-client query counts, block rates, cache hit ratios, latency percentiles, threat event counts by source. The built-in dashboard provides live fleet overview, query log, threat events, protection settings status, and unknown device detection — bound to loopback by default.

# Prometheus endpoint: /metrics
# Dashboard: /dashboard
nantevo_queries_total 48211
nantevo_blocked_by_source_total{source="tif"} 1462
nantevo_client_latency_avg_ms{client_name="web-01"} 11.2
Privacy architecture

Multiple layers of privacy
before the query reaches upstream.

nantevo-fwd implements the full RFC 8484 and RFC 8467 privacy stack plus several non-standard protections. By the time a query reaches the Nantevo upstream resolver, it carries as little identifying information as is technically possible.

EDNS Client Subnet stripping

Removes ECS options from all outgoing queries. Upstream resolvers and authoritative servers never see the client's network subnet — preventing geographic and network identity leakage up the DNS delegation chain.

strip_ecs: true · no subnet disclosure to upstreams

DNS rebinding protection

Blocks DNS responses that resolve public domain names to private, loopback, or link-local addresses — the core mechanism of DNS rebinding attacks that allow external sites to interact with internal network services.

rebind_protection: enabled · RFC1918 + loopback + link-local

HTTP/2 multiplexing and frame padding

DoH requests are multiplexed over HTTP/2 connections with frame-level padding per RFC 8467. This prevents traffic analysis attacks that attempt to identify queried domains from packet size and timing patterns.

http2_multiplexing: true · frame_padding: RFC8467

Randomized query IDs and user agent suppression

All outgoing query IDs are randomized — preventing correlation between queries across connections. HTTP User-Agent headers are suppressed entirely. No-store Cache-Control prevents intermediary caching of query responses.

query_id: randomized · user_agent: none · cache-control: no-store

Two-phase bootstrap — one plaintext query only

Startup requires a single plaintext DNS query to resolve the forwarder's own DoH endpoint. Every subsequent query — including all utility and management traffic — uses the Nantevo DoH endpoint. The bootstrap phase is auditable, logged, and the only window where plaintext DNS is permitted.

bootstrap: 1 plaintext query · all subsequent: DoH only
Deployment

Single binary. Runs on anything
Rust compiles to.

nantevo-fwd is a statically-linked Rust binary with no runtime dependencies. Tested in production on FreeBSD and Linux — cloud servers, on-premise hardware, and ARM single-board computers. Compiles and runs on macOS for development and testing. If you can run a binary on it and it forwards DNS, nantevo-fwd can protect it.

FreeBSD amd64 Linux amd64 Linux aarch64 macOS arm64 macOS amd64 + any Rust target
FreeBSD · rc.d

FreeBSD RC service

Ships with a complete rc.d service script for FreeBSD 13+ and 15. Starts at boot, restarts on failure, logs to syslog. Full Prometheus metrics export. The same deployment model used by the Nantevo cloud resolver nodes.

# /etc/rc.conf
nantevo_fwd_enable="YES"

service nantevo-fwd start
FreeBSD · BastilleBSD

Isolated jail deployment

Deploy inside a BastilleBSD jail for kernel-enforced process isolation. The jail gets a dedicated IP and separate network namespace — the same isolation model used by the Nantevo cloud resolver nodes. Zero overhead versus bare metal.

bastille create fwd-01 \
  15.0-RELEASE 10.0.0.53
bastille template fwd-01 \
  nantevo/fwd-template
Linux · systemd

Linux systemd service

Ships with a systemd unit file for any modern Linux distribution — Ubuntu, Debian, RHEL, Alpine, and others. Runs as an unprivileged user with CAP_NET_BIND_SERVICE to bind port 53. Tested on both amd64 and aarch64.

# /etc/systemd/system/
systemctl enable nantevo-fwd
systemctl start nantevo-fwd

journalctl -u nantevo-fwd -f
Linux · Raspberry Pi

ARM single-board computers

Tested in production on Raspberry Pi 4 (aarch64 Linux). Runs comfortably within the Pi's memory and CPU envelope — the ~300MB footprint leaves ample headroom for other services. An ideal home-lab or branch-office edge deployment for network-wide IoT and legacy device coverage.

# Raspberry Pi 4 · aarch64
# tested: Raspberry Pi OS 64-bit

./nantevo-fwd fwd.toml
Any platform · DHCP

Network-wide via DHCP

Point your DHCP server's DNS option at the host running nantevo-fwd. Every device on the network — regardless of OS, age, or capability — immediately routes through the forwarder. No configuration changes on any client device.

# ISC DHCP / dnsmasq
option domain-name-servers
  10.22.22.1;

# nantevo-fwd listens :53
macOS · development

macOS local development

Compiles and runs on Apple Silicon (M-series) and Intel Macs for development, configuration testing, and client mapping validation. Not a recommended production deployment, but a complete and functional environment for testing configs before pushing to FreeBSD or Linux nodes.

# macOS (Apple Silicon / Intel)
cargo build --release

sudo ./target/release/nantevo-fwd \
  -f fwd.toml

Ready to protect every device
on your network?

nantevo-fwd extends the Nantevo ZTA DNS stack to infrastructure that was previously out of reach. One binary. No agents. Full attribution.

Request a demo Read the deployment guide →