Speakers
Description
CNAME and delegation loops are well-known causes of recursive resolver instability and unnecessary upstream traffic. Although modern resolvers ultimately terminate these failures, they differ substantially in how quickly they recognize a loop, how much work they permit before failure, and whether they suppress repeated equivalent work afterward.
This presentation compares CNAME and delegation-loop handling in BIND 9, Unbound, and OpenDNSCache along four dimensions: exact cycle detection, CNAME-chain limits, bounds on recursive work, and resolution-failure caching and observability. BIND 9 and Unbound provide layered limits on recursive work and targeted detection of fetch or dependency cycles; for ordinary CNAME chains, both principally rely on configurable restart or chain-length limits. OpenDNSCache detects repeated names in its primary CNAME chain, allowing earlier termination of simple alias cycles, but relies on alias limits and state-machine loop bounds for nested NS-address and other recursive dependency cases.
We examine the operational consequences of these design choices under malformed and potentially malicious CNAME-loop patterns: upstream-query amplification, repeated client-triggered work, cache behavior, and observability of the actual failure cause. The goal is not to suggest that common resolvers fail to stop loops—they do—but to distinguish bounded failure from an early, explainable, and efficiently suppressed failure.
We present measurements of the upstream-work reductions achieved through exact cycle signatures and cycle detection spanning CNAME, delegation, and NS-address dependency paths. Finally, we evaluate short-lived, loop-signature-keyed failure caching and telemetry that distinguish loop-induced SERVFAILs from ordinary upstream failures, extending RFC 9520’s requirement to cache resolution failures.
| Talk duration | 20 Minutes (+5 for Q&A) |
|---|
