Reading notes on resolver fuzzing, RFC-compliance testing and DNS security research
Short notes on papers about fuzzing and testing the DNS, from resolver query-response fuzzing to RFC-compliance checking. One post per paper.
Updated September 21, 2026
ResolverFuzz goes after the resolver — the stateful, cache-holding middle of DNS that most fuzzers skip. It drives a resolver under test inside a controlled client-resolver-authoritative loop, mutating both the client's query and the authoritative response, then leans on differential testing across BIND, Unbound, Knot Resolver and PowerDNS…
SCALE builds an executable model of how DNS resolution is supposed to work, then uses symbolic execution to generate tiny zone files paired with queries that are likely to make implementations disagree. Run against real authoritative servers (that's the Ferret tool), it surfaced dozens of cases where popular…
Updated May 6, 2026
Coverage-guided fuzzers assume one input maps to one run, and network servers break that assumption: behaviour depends on the sequence of messages and the server's current state. AFLNet records real message exchanges, infers a state machine from the server's response codes, and mutates message sequences with coverage feedback…
Instead of fuzzing a live server, GRoot reasons symbolically over a set of zone files and enumerates every equivalence class of queries, so it can prove properties and surface misconfigurations — lame delegations, rewrite loops, inconsistent records — before anything's deployed. It's the static-analysis counterpart to the fuzzing…
Fuzzing network servers is slow for boring reasons: TCP handshakes, sleeps, file I/O and teardown dominate each run. SnapFuzz snapshots the server once it's initialised, swaps sockets and timers for fast in-memory equivalents, and restores from the snapshot each iteration — and reports big throughput gains on servers…