MeshDNS: A Cooperative DNS Resolution Framework for Resource-Constrained IoT Networks

Abstract: Domain Name System (DNS) resolution in Internet of Things (IoT) networks presents unique challenges due to resource constraints, unreliable connectivity, and security vulnerabilities. Traditional centralized DNS architectures introduce single points of failure. This paper presents MeshDNS, a cooperative DNS resolution framework designed for resource-constrained IoT environments operating under shared-key admission. MeshDNS employs a decentralized architecture where nodes maintain cache awareness using hash-based summaries and secure cold-cache misses via Ed25519-signed, identical-answer quorum voting. Our implementation on commodity ESP8266 microcontrollers (sub-50 KB usable RAM, 80 MHz) achieves a 0.47 ms warm-cache resolution, outperforming native mDNS baselines (1.39 ms). To secure initial cold-cache misses, MeshDNS trades a predictable ~1.3-1.7s cryptographic penalty to successfully isolate Byzantine faults among admitted peers. Assuming a threat model where physical hardware extraction remains out of scope, MeshDNS demonstrates Byzantine fault isolation. We validated the framework via a 5-node physical testbed and discrete-event simulations scaling to 1,000 nodes; the results demonstrate that MeshDNS maintains resilient local name caches for persistent edge telemetry under network churn. Code is available at https://github.com/mahbubasif/MeshDNS-Artifact.

• The paper introduces a cooperative DNS resolution system specifically engineered for low-resource IoT devices, leveraging local caching and peer-quorum voting for fast and secure lookups.
• It employs a hybrid architecture that isolates control, gossip, and admission phases to mitigate Byzantine faults and achieve sub-millisecond warm-cache performance.
• Extensive evaluations demonstrate predictable latency, energy efficiency, and resilience under adverse conditions, while highlighting challenges in Sybil resistance.

MeshDNS: Cooperative DNS Resolution for Resource-Constrained IoT Networks

Introduction and Problem Formulation

The paper "MeshDNS: A Cooperative DNS Resolution Framework for Resource-Constrained IoT Networks" (2607.00122) addresses a fundamental operational challenge in IoT environments: secure, low-latency, and decentralized DNS resolution under severe resource constraints and adversarial conditions. Traditional DNS architectures, with their hierarchical and centralized model, are ill-suited to IoT deployments that require privacy, low energy use, resilience to churn, and robustness against Byzantine peers. Standard alternatives such as DHT-based overlays, blockchain-based naming, or even mDNS, either exceed memory/compute/energy capabilities of commodity edge hardware or lack the required security guarantees for environments with untrusted participants.

MeshDNS System Architecture

MeshDNS introduces a peer-to-peer DNS resolution system tailored for IoT devices operating within a single Wi-Fi broadcast domain. The architecture is explicitly designed for platforms like the ESP8266 microcontroller (50 KB usable RAM, 80 MHz), combining a warm-cache fast path, deniable peer-quorum signed resolution for cold cache requests, and hash-based gossip for cache awareness. All protocol planes—cache lookup, voting, gossip, admission—are strictly isolated, ensuring that failures or malice in one cannot easily compromise the others.

Figure 1: MeshDNS architecture overview illustrating local cache lookup, authenticated peer admission, signed quorum voting, cache-summary gossip, telemetry/control, and upstream DNS fallback.

The physical and logical topologies reinforce this design. At the physical layer, all devices form a Wi-Fi star topology, while logically, devices interact as a fully connected, single-hop UDP broadcast mesh. This avoids multi-hop overlays and bounded-staleness issues, trading wide-area scalability for predictable performance, reliability, and deployment simplicity at the LAN edge.

Figure 2: MeshDNS Network Topology. The physical layer (right) utilizes a standard Wi-Fi star topology centered on an Access Point, while the logical protocol layer (left) functions as a fully connected, single-hop UDP broadcast domain.

Secure Cooperative Resolution and Byzantine Fault Isolation

MeshDNS’s resolution process is multi-phased. A node seeks answers directly from its local cache (string-keyed, LRU-managed, reputation-gated). On miss, it invokes an on-demand signed quorum voting cycle. Vote requests are keyed with BLAKE2b using a secret network PSK; all replies must be Ed25519-signed and match exactly in answer. Only once a strict identical-answer quorum is assembled is a resolution accepted and cached. This per-query voting mechanism does not establish global consensus, but is sufficient for secure, repeatable DNS answers in the presence of a bounded number of Byzantine nodes.

The system depends vitally on the separation of authoritative and gossip planes: gossip is used solely for cache awareness, never for authoritative answers, and is protected by signature and nonce schemes but cannot by itself poison the resolution path. Admission to the mesh is gated cryptographically via pre-shared network keys, and per-peer trust is maintained using an EWMA-updated local metric.

Empirical Evaluation and Performance Results

Resolution Latency and Resource Overheads

MeshDNS demonstrates exceptional warm-cache performance, achieving sub-millisecond average lookup times—0.47 ms vs. 1.39 ms for mDNS—while imposing only moderate cold quorum penalties (1.3–1.7 s, median 1.4 s) for initial, authenticated peer-majority agreement. Once an answer is cached, subsequent lookups remain instantaneous. Latency breakdowns further reveal that Ed25519 operations dominate during cold paths, but this is amortized away for steady-state workloads.

Figure 3: OS mDNS baseline vs. MeshDNS—MeshDNS achieves lower latency for warm-cache hits due to optimized local cache design.

Stability and Stress Under Load

In stress tests, the system sustains high success rates (78.2% hit under warm-cache burst), with mean lookup latencies stable amid network buffer exhaustion. Network traffic overheads for protocol control remain modest (<30 kbps), even during aggressive bursts.

Figure 4: Success rate vs latency during a 500-request burst; the system maintains stable sub-millisecond latencies as packet loss rises.

Byzantine and Sybil Attack Resilience

Under adversarial evaluation, the identical-answer quorum design proves robust: with up to $f=1$ Byzantine node(s) in a five-node setting, no incorrect records were accepted; the system consistently detected equivocation and forced resolution retries rather than propagating incorrect data. Notably, Sybil attacks exploiting multiple synthetic Ed25519 keys (backed by legitimate PSK) did yield quorum failures and some false acceptances, highlighting the insufficiency of PSK-only admission for large-scale Sybil resistance. The authors argue that further hardware-bound identity mechanisms (e.g., TPMs) are required to eliminate this weakness.

Scalability and Churn Recovery

Simulated population sweeps (up to 1,000 nodes) confirm that time to stable cache recovery after churn remains nearly constant, and the fraction of cold-resolution attempts shrinks with increasing $N$. The protocol demonstrates predictable convergence and fault-tolerance properties within the operationally scoped LAN setting.

Figure 5: Churn recovery and peer-quorum attempt success versus population size; MeshDNS maintains rapid coverage recovery and successful quorum rates even as population scales.

Energy Efficiency

Energy benchmarking on ESP8266 hardware shows that a single cache-hit requires only 2 µJ (SRAM read path); cold-quorum voting incurs one-off 557 mJ due to Wi-Fi TX/RX and cryptographic overhead, which is amortized as cache hits dominate. Power consumption traces confirm that network idleness and sporadic burst TX are the dominant contributors to aggregate energy usage.

Figure 6: Empirical power consumption trace of the ESP8266 node during a 1,000,000-lookup loop-aggregation microbenchmark.

Security Model, Practical Guarantees, and Limitations

MeshDNS guarantees are scoped tightly to intra-mesh queries and rely on the physical security of the deployed devices. While authenticated quorum resolution reliably eliminates logical equivocation and guards against replay and impersonation, physical extraction of PSK/keys from the device invalidates all properties. Upstream fallback (to legacy DNS) is outside the threat model; no on-device DNSSEC validation is feasible within the ESP8266 memory envelope, though the architecture admits cross-checking against DoH on more capable gateways.

Sybil resistance is only partial: without hardware identity binding, a malicious insider with PSK can provision multiple valid keypairs and subvert majority quorums. This is a nontrivial limitation for federated or adversarial deployments at scale and requires future integration with stronger cryptographic attestation or provisioning discipline.

Implications and Future Directions

MeshDNS fills a critical gap in the IoT security and performance landscape, providing a system that is both tailored for practical deployment on commodity edge hardware and robust to a wide spectrum of attacks and failures at the LAN scale. It demonstrates that strong cryptographically enforced agreement semantics, typically unavailable on devices with sub-100 KB RAM, are feasible with careful protocol and memory engineering. Notably, MeshDNS’s design is incompatible with wide-area, multi-domain federation and cannot address global-scale Sybil resistance or routing—its operational domain is strictly local, within a broadcast-connected enclave.

From a theoretical perspective, MeshDNS exemplifies the utility of scoped, per-query agreement (as opposed to global state consensus) as a viable path for deploying BFT primitives on severely constrained endpoints. The approach could inform protocol evolution for other resource-strained distributed systems (e.g., edge learning, collaborative sensing). Practically, the open-source availability of firmware and simulation artifacts supports future extensions in gateway-based scaling, hybrid admission control, and direct integration with privacy-preserving or authenticated naming systems.

Future work identified includes support for full DNSSEC validation (on higher-spec microcontrollers), hierarchical clustering for cross-LAN routing, formal security proofs (potentially in TLA+), tighter communication/energy optimization (compressed summaries, adaptive protocols), and hardware-enforced identity or attestation to close the Sybil loophole.

Conclusion

MeshDNS defines a rigorous, empirically validated cooperative DNS resolution protocol for resource-constrained, adversarial IoT environments, achieving strong local security, energy and latency efficiency, and resilience to Byzantine failure modes. Its operational guarantees remain conditioned on the physical trust model, but within that bounded scope, it delivers a feature space unmatched by existing centralized, DHT, or blockchain-based alternatives. This work is a concrete template for deploying robust distributed infrastructure within the physical and computational realities of edge IoT hardware, while surfacing critical research directions in practical BFT and decentralized admission control for the next generation of secure, autonomous networks.