c127/mikrodoh repository overview

⁠MikroDoH

A small C++17 daemon that accepts plain UDP DNS queries and forwards them as DNS-over-HTTPS. It targets low-end routers - the reference device is a MikroTik RB4011iGS+ running the proxy in a RouterOS v7 container.

Repository: https://github.com/c127dev/mikrodoh/⁠

⁠Design

• One HTTP/2 connection per event loop. Each worker drives a curl_multi handle with CURLPIPE_MULTIPLEX and CURLOPT_PIPEWAIT, so hundreds of queries share a single TLS connection and no TLS handshake is repeated.
• No thread per query. A producer thread reads the UDP socket and shards queries to N workers. Concurrency is bounded by MAX_INFLIGHT, not by thread count.
• Load shedding. Queries above the in-flight cap are dropped instead of queued, so accepted queries keep bounded latency under burst.
• Cipher selection from CPU features. See below.

⁠Cipher selection

TLS record crypto is the throughput ceiling on CPUs without an AES engine, because AES-GCM then runs in software. ChaCha20-Poly1305 is much faster in that case. CIPHER=auto probes the CPU at startup and picks accordingly:

CIPHER=chacha and CIPHER=aes override the probe. The selection is printed in the startup banner.

⁠OpenSSL assembly

The record crypto belongs to OpenSSL, not to this daemon. OpenSSL carries hand-written assembly for both AEADs and dispatches on CPU features at runtime:

Two things have to hold for a ChaCha20 build to reach those paths:

1. OpenSSL was not configured with no-asm. Some minimal or hardened builds are, and then ChaCha20 and Poly1305 fall back to portable C, which erases the reason to prefer them.
2. The kernel reports NEON in AT_HWCAP. OpenSSL reads it into OPENSSL_armcap at startup and picks the NEON code paths from it.

scripts/crypto-bench.sh checks both and measures the two AEADs on the device:

./scripts/crypto-bench.sh
OPENSSL_armcap=0 ./scripts/crypto-bench.sh   # same run with ARM asm disabled

Its numbers are the ground truth for CIPHER; the CPU probe is only a prediction of them.

⁠Configuration

Every key is read from the environment. boards/ holds ready-made sets, one per supported device, in --env-file format.

⁠Boards

Board files also carry keys the daemon ignores: MIKRODOH_TUNE, the compiler flags scripts/build.sh passes to cmake, plus MIKRODOH_PLATFORM and MIKRODOH_VARIANT, which name the image a board gets built into.

Adding a device means copying the closest generic file, measuring, and pinning the values that differ.

⁠Build

./scripts/build.sh                        # host defaults
./scripts/build.sh mikrotik-rb4011igs     # with that board's tuning flags

Needs cmake, a C++17 compiler and libcurl headers. The binary lands in build/mikrodoh.

⁠Run

set -a; . ./boards/generic-x86_64.conf; set +a
./build/mikrodoh

End-to-end check, builds and resolves a name through the proxy on port 6353:

./scripts/test.sh

⁠License

Apache License 2.0. See LICENSE⁠.