Summary

  • KeyTrap exploited the work DNSSEC validators performed while trying possible key-and-signature combinations; it attacked availability, not the cryptographic authenticity of a successful answer.
  • The durable repair was not to abandon DNSSEC, but to let each resolver stop pathological validation, preserve unrelated service and make the resource limit observable.

A signed zone sent the bill elsewhere

DNSSEC was designed so that a relying resolver can test whether DNS data belongs to an authenticated chain. That assurance requires work. A response can contain several DNSKEY records and several RRSIG records because key rollover, algorithm changes and multi-signer operation are legitimate. An RRSIG includes a 16-bit key tag intended to help locate the candidate key, but the tag is not unique.

KeyTrap made that flexibility adversarial. A malicious zone could publish many keys sharing a tag and many signatures that referred to it. Before concluding that none validated, a resolver could attempt a large cross-product of candidates. The publisher paid to send a bounded DNS response; the validator paid in repeated public-key operations.

Nothing in this mechanism forged a signature. The hostile zone did not become authoritative for another name, break the root chain or make bogus data secure. It used a legitimate validation path as a denial-of-service surface. The distinction matters: turning validation off would remove the immediate workload but also discard the protection the validator existed to provide.

ATHENE researchers disclosed the class privately in November 2023 to resolver developers and large operators. The public disclosure arrived on 13 February 2024 with coordinated fixes. Their experiments found extreme stalls across tested implementations, in some configurations ranging from about a minute to hours. Those figures describe laboratory cases, not a promise that every production resolver would fail for the same duration.

Different implementations drew different limits

ISC classified CVE-2023-50387 as remotely exploitable and High severity for assessed BIND 9 branches. Its advisory described CPU exhaustion from crafted answers and recommended patched releases. It also said that ISC knew of no active exploitation at disclosure. That absence must remain in the record: vulnerability is not evidence of an incident.

NLnet Labs fixed Unbound in 1.19.1. Its design did more than count attempts. After a bounded number of validations, work could be suspended so the resolver served other tasks; repeated suspension eventually ended the hostile query. This is scheduling as a security boundary. The answer was allowed to fail before one question monopolised the machine.

Cloudflare reported caps per RRset and per resolution task, an error for queries exceeding the limit, and metrics to reveal the condition. It said 1.1.1.1 was fully patched against KeyTrap by 8 December 2023, before public disclosure, and its internal CDN resolver by 13 February 2024 for KeyTrap and the related NSEC3 issue.

The implementations did not need one identical number to share a principle. A resolver may examine signed assertions; their publisher does not thereby acquire an unlimited claim on its CPU, queues or latency budget.

Standards described correctness, not an infinite budget

RFC 4034 defines the key-tag field and RFC 4035 defines validator behaviour. Their interoperability goal was necessary: validators need predictable rules for locating keys and testing signatures. Yet a correctness procedure becomes unsafe when an attacker chooses the amount of work and the specification leaves the ceiling implicit.

A 2026 Internet-Draft on DNS upper limits records the unresolved design problem, noting the absence of explicit limits for DNSKEY, DS and RRSIG records relevant to validation. It is evidence of continuing work, not an adopted standard. A future answer must preserve ordinary rollover and multi-signer cases while making adversarial complexity finite.

That makes the IETF standards process the durable institutional focus of this case. The question is no longer only which vendor patched first, but which bounds belong in the shared protocol contract and which must remain implementation-local. An individual draft does not establish IETF consensus, so operators cannot treat work in progress as a substitute for deployed limits.

That is the useful reading of Heng Lu’s Minimum Initial Specification principle. The common layer should say enough for interoperability. Future resource decisions should remain local where conditions and implementations differ. Voluntary adoption then lets running systems test a safer rule instead of waiting for an institution to pretend that one scheduler fits every resolver.

What operators can actually prove

An inventory should name implementation, exact package version, downstream distributor, patch provenance and deployment date. “DNSSEC enabled” answers the wrong question. A fleet can validate correctly in normal conditions and still carry an unbounded-work path.

Telemetry should separate signature attempts, validation time, queue delay, cache service and limit-trigger failures. An availability dashboard showing only average query latency may hide a small number of threads trapped in expensive work. Tests should include malicious-zone fixtures in an isolated environment and confirm that unrelated cached and uncached queries continue.

Disabling validation is a materially different act. If an operator uses it during an emergency, the exception needs an owner, narrow affected scope, expiry, monitoring and an evidenced return to validation. Otherwise a temporary availability choice becomes a silent downgrade.

Evidence limits

The reviewed sources do not prove exploitation in the wild, a global outage or a complete number of vulnerable resolvers. Vendor release dates do not prove that every distribution and private fleet patched on the same day. ATHENE’s measurements should not be universalised, and promotional superlatives should not substitute for comparative data.

KeyTrap established a narrower fact. Signed input can impose asymmetric verification cost. The relying party therefore needs authority not only to accept or reject the final claim, but also to decide when the cost of reaching that decision has become hostile.

Sources