The Harder You Try, The Harder You Fail:

The KeyTrap Denial-of-Service Algorithmic Complexity Attacks

on DNSSEC
Elias Heftrig Haya Schulmann Niklas Vogel Michael Waidner
Fraunhofer SIT Goethe Uni Frankfurt Goethe Uni Frankfurt TU Darmstadt
ATHENE ATHENE ATHENE Fraunhofer SIT
Darmstadt, Germany Frankfurt, Germany Frankfurt, Germany ATHENE
Darmstadt, Germany

Abstract ACM Reference Format:

Availability is a major concern in the design of DNSSEC. To ensure Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner. 2024.
The Harder You Try, The Harder You Fail: The KeyTrap Denial-of-Service
availability, DNSSEC follows Postel’s Law [RFC1123]: "Be liberal in
Algorithmic Complexity Attacks on DNSSEC. In Proceedings of the 2024
what you accept, and conservative in what you send." Hence, name- ACM SIGSAC Conference on Computer and Communications Security (CCS
servers should send not just one matching key for a record set, ’24), October 14–18, 2024, Salt Lake City, UT, USA. ACM, New York, NY, USA,
but all the relevant cryptographic material, e.g., all the keys for 14 pages. https://doi.org/10.1145/3658644.3670389
all the ciphers that they support and all the corresponding signa-
tures. This ensures that validation succeeds, and hence availability,
even if some of the DNSSEC keys are misconfigured, incorrect or 1 Introduction
correspond to unsupported ciphers. The impact of the cryptographic requirements on the availability
We show that this design of DNSSEC is flawed. Exploiting vul- of DNS was a major concern in the design of DNSSEC [RFC4033-
nerable recommendations in the DNSSEC standards, we develop RFC4035]. Strict DNSSEC validation rules could impact DNS avail-
a new class of DNSSEC-based algorithmic complexity attacks on ability, hence, DNSSEC standard opted to limit strict requirements
DNS, we dub KeyTrap attacks. All popular DNS implementations to the necessary minimum that suffices to ensure cryptographic
and services are vulnerable. With just a single DNS packet, the security while maintaining availability of DNS, aiming at a trade-off
KeyTrap attacks lead to a 2.000.000x spike in CPU instruction count between security, performance, and backward-compatibility. The
in vulnerable DNS resolvers, stalling some for as long as 16 hours. standard requirements for DNSSEC were designed so that the DNS
This devastating effect prompted major DNS vendors to refer to resolvers do not fail on the first cryptographic error. As long as
KeyTrap as “the worst attack on DNS ever discovered”. Exploiting a resolver can verify the provided information with any available
KeyTrap, an attacker could effectively disable Internet access in any DNSSEC material, the validation will succeed.
system utilizing a DNSSEC-validating resolver. "Be liberal in what you accept, and conservative in what
We disclosed KeyTrap to vendors and operators on November 2, you send" [RFC1123]. The core DNSSEC specification mandates
2023, confidentially reporting the vulnerabilities to a closed group of validating DNS resolvers to try all possible keys when validating a
DNS experts, operators and developers from the industry. Since then resource record set (RRset) [RFC4035], and also strongly endorses to
we have been working with all major vendors to mitigate KeyTrap, try all possible signatures covering it [RFC6840]. These DNSSEC re-
repeatedly discovering and assisting in closing weaknesses in pro- quirements follow Postel’s Law [RFC1123]: the nameservers should
posed patches. Following our disclosure, the industry-wide um- send all the available cryptographic material, and the resolvers should
brella CVE-2023-50387 has been assigned, covering the DNSSEC use any of the cryptographic material they receive until the vali-
protocol vulnerabilities we present in this work. dation is successful. This ensures availability even if some of the
DNSSEC material cannot be used to validate authenticity of the
CCS Concepts DNS records, e.g., if the keys are misconfigured, incorrect or out-
dated. We perform experimental evaluations and code analysis and
• Networks → Network protocols; • Security and privacy →
find that these protocol requirements are supported by all major
Network security.
DNS resolver implementations.
DNSSEC algorithmic-complexity attacks. In this work, we
Keywords discover that the design philosophy of DNSSEC is flawed. We exploit
DNS, DNSSEC, Denial-of-Service Attack the flaws in the DNSSEC standard and develop the first DNSSEC-
based algorithmic complexity attacks against DNS. We demonstrate
experimentally that our attacks are detrimental to availability of the
This work is licensed under a Creative Commons Attribution affected DNS resolvers, leading to Denial of Service (DoS) on basic
International 4.0 License. DNS functionalities, such as providing cached responses, or pro-
cessing inbound or pending DNS packets. We show experimentally
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA that an adversary using a single DNSSEC signed DNS response can
© 2024 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-0636-3/24/10 DoS resolvers leading to a spike of 2.000.000x in CPU instruction
https://doi.org/10.1145/3658644.3670389 count. The stalling period of the victim resolver depends on the

497
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner

resolver implementation, and can be up to 16 hours, see Table 4. For 1 for(i=0; i<num; i++) {
2
comparison, a recently proposed NRDelegation attack [2] which 3 /* see if key matches keytag and algo */
exploited vulnerabilities in DNS to create multiple referral requests, 4 if(algo != dnskey_get_algo(dnskey, i) ||
would require 1569 DNS packets to cause a comparable increase 5 tag != dnskey_calc_keytag(dnskey, i))
6 continue;
in CPU instruction count, which our attacks achieve with a single 7

packet. We find that all DNSSEC validating DNS software, DNS 8 numchecked ++;
9
libraries and public DNS services on our dataset are vulnerable to 10 /* see if key verifies */
our attacks; see list in Table 1. 11 sec = dnskey_verify_rrset_sig(env, ve, rrset, dnskey,
↩→ i, sig_idx);
Flaws in DNSSEC. We find that the flaws in DNSSEC specifica- 12

tion are rooted in the interaction of a number of recommendations 13 if(sec == sec_status_secure)

14 return sec;
that in combination can be exploited as a powerful attack vector: 15 }
Key tag collisions: First, DNSSEC allows for multiple keys in Listing 1: Loop over all Keys in Unbound.
a given DNS zone, for example during key rollover or for multi-
algorithm support [RFC6781]. Consequently, when validating DNS- 1 for(i=0; i<num; i++) {
SEC, DNS resolvers are required to identify a suitable cryptographic 2
3 sec = dnskeyset_verify_rrset_sig(env, ve, rrset,
key to use for signature verification. DNSSEC uses key tag values ↩→ dnskey, i);
to differentiate between the keys, even if they are of the same zone 4
5 if(sec == sec_status_secure)
and use the same cryptographic algorithm. The triple of (zone name, 6 return sec;
algorithm, key tag) is added to each respective signature to ensure 7 }
efficiency in key-signature matching. When validating a signature, Listing 2: Loop over all Signatures in Unbound.
resolvers check the signature header and select the key with the
matching triple for validation. However, the triple is not necessarily
unique: multiple different DNS keys can have an identical triple. grows linearly with the amount of colliding keys. For example,
This can be explained by the calculation of the values in the triple. if a signature has ten colliding keys, all with identical algorithm
The algorithm identifier results directly from the cipher used to identifier, key tag and all invalid, the resolver must conduct ten
create the signature and is identical for all keys generated with a signature validations before concluding the signature is invalid.
given algorithm. DNSSEC mandates all keys used for validating sig- While colliding keys are rare in real-world operation, we show that
natures in a zone to be identified by the zone name. Consequently, records with multiple colliding keys can be efficiently crafted by
all DNSSEC keys that may be considered for validation trivially an adversary, imposing heavy computation on a victim resolver.
share the same name. Since the collisions in algorithm id and key Multiple signatures: A philosophy, of trying all the cryptographic
name pairs are common, the key tag is calculated with a pseudo- material available to ensure that the validation succeeds, also ap-
random arithmetic function over the key bits to provide a means to plies to the validation of signatures. Creating multiple signatures
distinguish same-algorithm, same-name keys. Using an arithmetic for a given DNS record can happen, e.g., during a key rollover. The
function instead of a manually chosen identifier eases distributed DNS server adds a signature with the new key, while retaining the
key management for multiple parties in the same DNS zone; in- old signature to ensure the signature remains valid for all resolvers
stead of coordinating key tags to ensure uniqueness, the key tag until the new key has propagated. Thus, parallel to the case of col-
is automatically calculated. However, the space of potential tags is liding keys, the RFCs specify that in the case of multiple signatures
limited by the 16 bits in the key tag field. Key tag collisions, while on the same record, a resolver must try all the signatures it received
unlikely, can thus naturally occur in DNSSEC. This is explicitly until it finds a valid signature or until all signatures have been tried.
stated in [RFC4034]1 , emphasizing that key tags are not unique “The worst vulnerability ever found in DNS”: We combine these
identifiers. As we show, colliding key tags can be exploited to cause requirements for the eager validation of signatures and of keys,
a resolver not to be able to identify a suitable key efficiently but to along with the colliding key tags to develop powerful DNSSEC-
have to perform validations with all the available keys, inflicting based algorithmic complexity attacks on validating DNS resolvers.
computational effort during signature validation. Our attacks allow a low-resource adversary to fully DoS a DNS
Multiple keys: Second, the DNSSEC specification mandates that resolver for up to 16h with a single DNS request. The task force with
a resolver must try all colliding keys until it finds a key that suc- 31 participants from the major operators, vendors and developers
cessfully validates the signature or all keys have been tried. This of DNS/DNSSEC, to which we disclosed our research, dubbed our
requirement is meant to ensure availability. Even if colliding keys attack: the most devastating vulnerability ever found in DNSSEC.
occur, such that some keys may result in failed validation, the re- Complex vulnerabilities are challenging to find. Surpris-
solver has to try validating with all the keys until a key is found ingly the flaws are not recent. The requirement2 to try all keys
that results in a successful validation, ensuring the signed record was present already in the obsoleted [RFC2535] from 1999. This
remains valid and the corresponding resource therefore available. requirement, to try all the keys, was carried over to the current spec-
However, this "eager validation" can lead to heavy computational ification [RFC4035]. In 2013 the issue was further exacerbated by
effort for the validating resolver, since the number of validations [RFC6840] recommending validators to also try all the signatures.

1 https://datatracker.ietf.org/doc/html/rfc4035#section-5.3.
1,https://datatracker.ietf.org/doc/html/rfc4034#appendix-B 2 https://datatracker.ietf.org/doc/html/rfc2535#page-46

498
The Harder You Try, The Harder You Fail:
The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNSSEC CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA

The vulnerabilities have been in the wild since at least August Kaminsky’s demonstration, despite the concerns, the vendors did
2000 in Bind9 DNS resolver3 and were introduced into the code4 of not consider this a practical threat. Following Kaminsky’s attack,
Unbound DNS resolver in August 2007. Using Unbound as an exam- all the vendors quickly patched their DNS resolvers to send DNS
ple, the vulnerable code performs loops over keys and signatures, requests from unpredictable ports. This and other examples show
as shown by Listings 1 and 2. that to improve security a deep understanding of the problem at
Although the vulnerabilities have existed in the standard for hand is required, in order to find a way to weaponize it, so that it
about 25 years and in the wild for 24 years, they have not been then becomes an attack. This was also the case with key trap, after
noticed by the community. This is not surprising since the complex- we found a way to demonstrate for the first time that key trap was
ity of the DNSSEC validation requirements made it challenging to a practical threat, all the vendors immediately issued patches.
identify the flaws. The exploit requires a combination of a number Contributions. We make the following contributions:
of requirements, which made it not trivial even for DNS experts • Conceptually, we find that the aim to ensure validation at any
to notice. The security community made similar experiences with cost in DNSSEC standard exposes the DNS resolvers to attacks.
much simpler vulnerabilities, such as Heartbleed or Log4j [5, 7] We analyze the DNSSEC standards in §4, and identify flaws in the
which were there but no one could see them, and they took years DNSSEC standards which enable complexity attacks.
to notice and fix. Unfortunately, in contrast to these vulnerabilities, • We combine the flaws in the RFCs to develop the first algo-
the vulnerabilities we find in this work are not simple to resolve, rithmic complexity attacks that exploit vulnerabilities in DNSSEC.
since they are fundamentally rooted in the design philosophy of We find experimentally that all standard-compliant DNS imple-
DNSSEC, and are not just mere software implementation bugs. mentations support the flawed recommendations and hence are
Flaws are challenging to mitigate. The flaws in DNSSEC val- vulnerable to our attacks.
idation are not simple to solve. There are legitimate situations in • We analyze the code of popular DNS implementations to iden-
which nameservers may return multiple keys, e.g., to account for tify the effects of the stalling on, e.g., caching, pending DNS requests
potential failures. For instance, some domains may be experiment- or inbound/pending DNS packets. We use our observations to pro-
ing with new ciphers, not yet supported by all the resolvers and vide recommendations for adapting the architecture of the resolvers
there are keys-rollover. To avoid failures the nameservers should to improve the robustness to failures and attacks.
return all the cryptographic material. Similarly, to ensure successful • We performed ethical disclosure of our vulnerabilities to the
validation, the resolvers should not fail on the first unsuccessful major DNS vendors, DNS/CDN/cloud operators and standardizers
validation, but should try all the material until validation succeeds. on November 2, 2023. Since then, we have been intensively working
Indeed, the experience we made since we have started working with this group on developing patches and regularly communicating
on the patches with the developers shows that these flaws can be with the developers within a closed chat group. We provided to the
substantially mitigated, but cannot be completely solved. Attacks developers our attack vectors encoded in DNS zonefiles and set up a
against the final patch still result in heavy CPU load caused by high test environment for evaluation of vulnerabilities in DNSSEC, which
attacker traffic, but at least DNS packet loss is prevented. Solving alleviates the need for manual setup and enables quick evaluation of
these issues fundamentally requires to reconsider the basics of the the attacks against the proposed patches. We provide a timeline for
design philosophy of the Internet. disclosure and of the patches development process. Our discovered
The importance of understanding and weaponizing vul- vulnerabilities were assigned an umbrella CVE in December 2023.
nerabilities. While there were concerns in the community that Organization. We compare our research to related work in §2.
key tag collisions could introduce a weakness5 and even a bach- We provide an overview of DNS and DNSSEC in §3. We analyze
elor project attempted to find an attack6 , no compelling method the recommendations in the DNS standard specification in §4. We
to weaponize the key tag and demonstrate an attack was found. construct the attacks in §5 and evaluate them against major DNS
Therefore, the collisions were not regarded as a practical threat implementations and services in §6. Disclosure and the process of
and vendors did not issue patches. Understanding how to exploit developing mitigations are in §7. We discuss ethical considerations
and weaponize a vulnerability and the ability to demonstrate it to in §8 and conclude in §9.
the community is critical. There are numerous examples where the
ability to understand and realize a threat led to improvements in
the security landscape. One such example in DNS is that of port 2 Related Work
randomization. Initially the DNS resolvers were using predictable In Distributed Denial of Service (DDoS) attacks adversaries flood a
or fixed source ports for their requests, until a security expert victim resource, e.g., a network bandwidth or a buffer, with a large
Kaminsky found a way to weaponize and demonstrated a practical volume of packets loading the target victim beyond its available ca-
DNS cache poisoning attack [10]. Although predictable DNS source pacity and causing packet loss [12]. DNS is often a victim of DDoS,
ports were seen by many experts in the community as a threat, this either as a target or as a reflector to flood other victims. Since DNS
was not fixed until a practical attack was demonstrated7 . Prior to responses are larger than DNS requests, reflected DNS responses
3 https://github.com/isc-projects/bind9/commit/ amplify the load generated by the attacker’s requests. The amplifi-
6f17d90364f01c3e81073a9ffb40b0093878c8e2 cation factor is exacerbated with DNSSEC, whose signatures and
4 https://github.com/NLnetLabs/unbound/commit/
keys further increase the sizes of DNS responses [16]. An amplifi-
8f58908f45d69178f8a30125d8ebcedf3c6f6761 cation effect can also be achieved by exploiting vulnerabilities in
5 https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf
6 https://essay.utwente.nl/78777/1/Research_paper.pdf protocol implementations or vulnerabilities in the processing of
7 https://makezine.com/article/technology/djbdns-dns-exploits-bernstein/ DNS records [4, 14]. NXNSAttack [1] exploited a vulnerability that

499
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner

generated a flood of queries between the recursive resolver and hours (depending on the resolver software) with a single DNS re-
the authoritative server creating a load on them both. Recently, [2] sponse packet. All the resolvers we tested were found vulnerable
demonstrated a complexity attack on DNS which causes a victim to our attacks. We evaluate how DNS implementations react to the
resolver to issue multiple queries, following delegation responses load created by the attack and find that certain design choices can
by a malicious authoritative server. The victim resolver issues the enable faster recovery from our DoS attacks.
queries to nameservers which do not respond, eventually exhaust- Our work is also related to downgrade attacks against DNSSEC,
ing its resources. DNSSEC [9]. The DNSSEC-downgrade attacks however focus on
The NRDelegation attack in [2] is shown to achieve a 5600x in- disabling DNSSEC validation, but do not have adverse effects on
crease in CPU instructions between the attack requests and benign the availability of the victim resolvers.
DNS requests. In contrast, our KeyTrap attack in this work achieves
a 2000000x increase in CPU instruction count. 3 Overview of DNSSEC
To compare the impact between both attacks on the CPU instruc-
DNSSEC [RFC4033-4035] ensures origin authenticity and data in-
tion count, we set up a benign and a malicious signed domains. We
tegrity in DNS. To gain security benefits the domain owners should
set up an Unbound resolver in an isolated environment and run
digitally sign the records in their domains, and should upgrade the
Linux perf to measure CPU instruction count. We first measure the
nameservers to serve DNSSEC-signed DNS responses. The DNS
CPU instruction count of a request to a benign DNSSEC signed
resolvers should validate the received DNS records against the dig-
domain. To ensure reliability we average out the instruction count
ital signatures. To validate the public keys the resolvers should
over five measurements. Further, we set up the attack domain on
construct a validation path from the root zone to the target domain.
the same DNS server. The measurements are conducted on Ubuntu
If validation fails, the resolver must not deliver the bogus records
22.04 LTS with Unbound 1.19.0 DNS software. In our test setup, we
to the client and instead signal an error by sending a SERVFAIL
find that a benign request on a signed DNSSEC domain requires
response. If DNSSEC validation is successful, the resolver should
approx. 811.500 CPU instructions on Unbound. In contrast, we
return the requested records to the client and cache them.
find a significantly higher instruction count for the resolution of
DNSSEC signatures are conveyed in RRSIG-type DNS records.
the KeyTrap attack domain. To resolve and validate the domain,
An RRSIG record is associated with the set of records (RRset) it
Unbound takes approximately 1.725.000.000.000 CPU instruc-
covers by name, class, and the record type indicated by an RRSIG-
tions. Comparing to the benign request, the attack thus leads to
specific record field. The public keys used to validate the signatures
a 2.000.000x increase in CPU instruction count, compared to the
are sent in DNSKEY-type records.
5600x increase in NR delegation. Directly comparing the CPU in-
There are two types of keys: Zone-Signing-Key (ZSK) and Key-
structions count of [2], we find that NR delegation attack requires
Signing-Key (KSK). The ZSKs are used to sign records in the zone
1569 queries to result in the same increase in CPU instruction count
and are authenticated with a KSK. DNSKEY records contain multiple
as a single request with our KeyTrap attack. Hence, a KeyTrap
fields, including usage-indicating flags, the protocol and algorithm
request leads to the same load as approx. 2 million benign requests.
specifiers, and the key bytes. From these record data the key tag
Van Rijswijk-Deij et al. [15] explored the performance of ECC
can be calculated. The KSKs and all ZSKs of a zone are included
vs RSA on Bind9 and Unbound. They evaluated the load on the
into a DNSKEY set which is signed by at least one KSK. Signature
Bind9 and Unbound resolvers when sending multiple signatures and
records covering the DNSKEY set need to reference the key tag of a
found that the ECC algorithms do not impose too much additional
KSK. Only after the DNSKEY set is validated can the ZSK be used to
CPU load on the two resolvers in contrast to RSA. To create load the
validate signatures covering other records (RRs). To support simple
authors made the resolver request a large number of non-existent
DNSSEC setups, KSK and ZSK can be identical.
records (NSEC3), causing many DNS responses, each carrying up to
DS records from a parent zone are used to authenticate individual
three NSEC3 records plus one SOA, with one signature validation
KSK type DNSKEY records in a child zone. This is done to delegate
per record. In effect, the victim resolver was validating four RRSIG
trust from a parent zone public key to a child zone public key.
records per response. While the responses sent by [15] caused
DS records use the same triple (zone name, algorithm, key tag) as
the resolver to perform 4 validations, equivalent to the number
RRSIGs to identify a subset of candidate DNSKEYs.
of signatures their nameserver returned (an order of O (𝑛)), our
DNS records contain mappings from DNS names to resources.
specially crafted records trigger more than 500K validations per
In this work, we use the DNS A record in the evaluations of our
DNS response (an order of O (𝑛 2 )). Our attack scales quadratically
attacks. The A record contains the mapping of a domain name in
with the number of keys returned to the resolver.
the zone to an IPv4 address. The A record includes a TTL value,
In contrast to previous work our KeyTrap attacks do not require
which specifies the validity period for caching. The A-type record is
multiple packets, instead we exploit algorithmic complexity vulner-
queried by a resolver when resolving a domain name. For instance,
abilities in the DNSSEC validation in DNS resolvers as a building
an A record may map the domain www-x.attack.er to the IP address
block to develop CPU based DoS attacks. Our complexity attacks
6.6.6.6. We explain the functionality of DNS and DNSSEC with
are triggered by feeding the DNS resolvers with specially crafted
concrete examples in §5.
DNSSEC records, which are constructed in a way that exploits vali-
dation vulnerabilities in cryptographic validation logic. When the
DNS resolvers attempt to validate the DNSSEC records they receive 4 Analysis of DNSSEC Specification
from our nameserver, they get stalled. Our attacks are extremely In the following, we illustrate the validation recommendations in
stealthy, being able to stall resolvers between 170 seconds and 16 the DNSSEC standard relevant to the KeyTrap attacks.

500
The Harder You Try, The Harder You Fail:
The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNSSEC CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA

Associating keys with signatures. A domain can use multiple records. For examples, see the the validation routines in Unbound8 .
different keys, see [RFC6840, §6.2]. This is required for instance In this work we show that these requirements are vulnerable. We
to support new stronger cryptographic ciphers but also to offer develop KeyTrap algorithmic complexity attacks that exploit the
weaker ciphers for other non-supporting resolvers, or to support specification weaknesses in the association process described above
stronger and weaker keys of same cipher, or during key rollover. to forge a DNSKEY set of cardinality 𝑘, conforming to a single key
In such a situation the DNS records are signed with all those tag 𝑡𝑘 , and to create a large number 𝑠 of invalid RRSIG records,
keys and the resolver receives the keys and signatures in a DNS which all reference these DNSKEYs. In consequence, the resolver
response. needs to check all 𝑠 signatures against all 𝑘 keys – a procedure with
To authenticate an RRset the RRSIG covering it needs to be asso- asymptotic complexity in O (𝑛 2 ).
ciated with the DNSKEY record carrying the corresponding public
key. This is done by matching the Signer’s Name in the RRSIG 5 Resource Exhaustion Attacks
record data field with the name of the DNSKEY record and the Our attacks consist of a module for sending queries to the target
algorithm fields. Additionally, the value of the Key Tag field in the resolver, malicious nameservers and the zonefiles that encode the
RRSIG must match the key tag value of the DNSKEY. Note that KeyTrap attack vectors. We exploit algorithmic complexity vulner-
the DNSKEY record data format does not specify a Key Tag field. abilities in standard requirements to develop different variants of
Instead, the key tag value is calculated by resolvers as an unsigned KeyTrap resource exhaustion attacks: KeySigTrap, SigJam, Lock-
16-bit integer sum over all two-octet words in the DNSKEY record Cram, and HashTrap. To initiate the attacks our adversary causes
data (ignoring carry and allowing overflow). As highlighted by the victim resolver to look up a record in its malicious domain. The
[RFC4034, §B], the key tag is not a unique identifier, but a mecha- attacker’s nameserver responds to the DNS queries with malicious
nism to efficiently identify a subset of DNSKEYs possibly matching record sets (RRsets), according to the specific attack vector and
the RRSIG to be validated. In consequence, to successfully authen- zone configuration.
ticate an RRset covered by an RRSIG, the resolver MUST try all
DNSKEYs in this subset until it succeeds to validate the signature 5.1 Threat Model
using one of the candidate public keys or runs out of keys to try
In our work we consider a low-resource attacker who is capable
[RFC4035, §5.3.1].
of hosting a DNSSEC-signed domain with a secure delegation and
Moreover, the DNSSEC key tag is not a crytographic fingerprint
who can attract a victim to resolve a name in this domain. Hosting
of the public key. Representing an unsigned integer sum over the
a signed domain with a secure delegation is a straightforward, field-
record data the key tag does not provide a cryptographic collision
proven administrative process: It can be achieved simply by renting
resistance. In §5 we develop an attack LockCram which exploits the
the domain, setting up the delegation as well as an open-source
requirement to associate keys with signatures.
authoritative DNS server, and configuring it with the zone files
Resolvers are endorsed to try all signatures. To support a
following the outline in this section. To attract the victim resolver
variety of domain-side key and algorithm roll-over schemes, as
the attacker can take various approaches, e.g., by embedding image
well as to increase robustness against cache-induced inconsisten-
URLs in HTML documents and distributing them via e-mail or ad
cies in the Internet-wide DNS state, resolvers must be tolerant in
network, or by sending bogus e-mail to an SMTP server configured
case individual signatures do not validate. Besides ignoring any
to deliver bounce messages [RFC5321]. The specific approach taken
RRSIGs, which do not match any authenticated DNSKEY, resolvers
is out of scope of this document. The resources required by the
are endorsed by specification (SHOULD) to try all RRSIGs covering
attacker are generally low. Specifically, the attacker does not require
an RRset until a valid one is found. Only if all signatures fail to
any potent hardware, since the attacks utilize only a limited number
authenticate the RRset should the resolver mark it invalid. When
of network transactions (the most potent one requiring only a single
multiple RRSIGs cover a given RRset, [RFC6840, §5.4] suggests that
attack packet). Fruthermore, the cryptographic material, which
a resolver SHOULD accept any valid RRSIG as sufficient, and only
the victim resolver will be busy validating, is invalid by design,
determine that an RRset is bogus if all RRSIGs fail validation.
rendering it computationally trivial to generate.
The explanation is that if a resolver adopts a more restrictive
policy, there is a danger that properly signed data might unnec-
5.2 DNSSEC Setup
essarily fail validation. . Furthermore, certain zone management
techniques, like the Double Signature Zone Signing Key Rollover The attack vectors are encoded in a zonefile in the domain controlled
method described in [RFC6781, §4.1.1], will not work reliably. by the adversary. For the attack to be effective, the adversary needs
Resolvers try to authenticate all DNSKEYs with all DS to register a domain under a signed parent.
hashes. The DNSSEC standard is not clear on the requirement of Zonefile. The attack vectors are encoded in the zonefiles in
DS hashes authentication. This vagueness left it for developers to Figure 1. In addition to the DNSSEC records, the zones also feature
decide how to implement the DS validation. We experimentally DNS records.
find that all the resolvers in our dataset validate all the DS hashes. Chain of trust. Although there is no explicit requirement in the
RFC-compliant resolvers are vulnerable. We find experimen- DNSSEC standard how validation of signed DNS records should
tally that all the resolvers in our dataset adhere to RFC specifications, proceed, the standard specification suggests that it should be done
validating all signatures with all DNSSEC keys they received from top down. The validator should construct the chain of trust top
the attack server and validate all DS hashes against all the DNSKEY 8 https://github.com/NLnetLabs/unbound/blob/master/validator/val_sigcrypt.c
lines 641 and 704.

501
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner

5.4 LockCram (Many Keys x One Signature)

Following the design of SigJam, we develop an attack vector, we
dub LockCram, that exploits the fact that resolvers are mandated to
try all keys [RFC4035] available for a signature until one validates
or all have been tried. The LockCram attack is thus constructed by
leading a resolver to validate one signature over a DNS record using
many ZSK DNSSEC keys. The zonefile for the LockCram attack is
illustrated in Figure 1b. Since the zone has multiple similarities to
the SigJam zone, in the following we highlight the differences.
The zonefile contains multiple ZSK keys in a key resource set
1 , an A record and an (invalid) signature over an A record 2 . The
(a) Zonefile for SigJam attack. (b) Zonefile for LockCram attack.
keys can be validated by a single KSK of the zone (key tag 56012).
The attacker needs to ensure that all the ZSKs match in signer name,
algorithm and key tag. While matching signer name and algorithm
is trivial, matching the key tag is not straightforward, as the key
tag is not explicitly stated in a key field, but instead calculated over
the record data of the key. Further, the attacker cannot simply add
the exact same key multiple times, allowing identical key tags, as
resolvers de-duplicate identical entries. However, the attacker can
brute-force the creation of colliding keys, i.e., keys with identical
key tags and differing key bits: The adversary continuously creates
new DNSSEC keys with the desired algorithm, calculates the key
tag and only stores keys with the desired tag until the target number
(c) Zonefile for KeySigTrap attack. (d) Zonefile for HashTrap attack. of colliding keys has been collected. In the example the attacker
Figure 1: Zonefiles of the KeyTrap algorithmic complexity attacks. needs to create many DNSSEC keys with algorithm 14 and the key
tag 5353. All of these keys are added to the zone.
A resolver that queries the A record attempts to validate the
signature. To do that the resolver identifies all the DNSSEC keys
for validating the signature, which in this example are all the ZSKs,
down [RFC4033, §3.1], and is required to authenticate the DNSKEY as all have a matching triple of signer name (attack.er), algorithm
before using it to validate signatures, see [RFC4035, §5.3.1]. (14), and key tag (5353). An RFC-compliant resolver must try all
the keys on the invalid signature until concluding the signature is
invalid, leading to multiple validations in the resolver.
5.3 SigJam (One Key x Many Signatures)
The RFC advises that a resolver should try all signatures until
a signature is found that can be validated with the DNSKEY(s). 5.5 KeySigTrap (Many Keys x Many Signatures)
To exploit this recommendation we construct an adversarial zone The KeySigTrap attack combines the many signatures of SigJam
illustrated in Figure 1a. The parent zonefile contains a signed DS with the many colliding DNSKEYs of LockCram, creating an attack
record 1 that authenticates the KSK (key tag 56012) of the child 2 . that leads to quadratic complexity of validations, while the other
The zonefile of the child contains a ZSK (key tag 5353) 3 signed two attacks scale linearly with the number of abused records. Figure
with the KSK (key tag 56012) 4 . Finally the ZSK is used to sign the 1c illustrates how the KeySigTrap attack zonefile can be constructed.
A record 5 with multiple (invalid) signatures all of which refer to We highlight the differences to the previous zones.
the same ZSK DNSKEY record 6 . The construction of the DNSKEY set in the KeySigTrap attack
The RFC-compliant resolver should try all the signatures with is identical to the set in the LockCram attack. The attacker creates
the key until one validates or no signature is left to try. Mapping a set of ZSKs in step 1 , all with the same key tag (5353). With
between the key and the signatures is done by matching the triple a large amount of keys, the attacker ensures that each signature
signer name (attack.er), algorithm (14), and key tag (5353). The validation requires as many validations as there are colliding ZSKs
resolver only tries the key(s) where this triple matches. However, in the zone. The attacker additionally uses the idea of SigJam to
since none of the three values needs to be unique, collisions can put many signatures with the same key tag into the zone in step
occur, i.e., where multiple signatures fit the same DNSSEC key. 2 , which need to be validated to authenticate a DNS record, in
As indicated in the example zone by [...], the attacker adds many this example an A record. This ensures that a resolver querying
invalid signatures, all matching the triple of the ZSK. The resolver the A record for www-X.attack.er must validate a large number of
tries all the signatures. Since none validates, the resolver concludes signatures.
that the record cannot be validated and returns a SERVFAIL error The attacker zone therefore contains many signatures over the
to the client, that requested the A record. The SigJam attack is requested hostname, and each of these signatures refers to many
thus constructed by leading the resolver to validate many invalid different ZSKs. Following the RFCs, the resolvers SHOULD try all
signatures on an A record using one ZSK. the signatures. For each signature the resolver tries, it MUST try

502
The Harder You Try, The Harder You Fail:
The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNSSEC CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA

all the matching ZSKs in the zone. In the example zone the resolver Name Vuln. Comment
Akamai CacheServe DoS 186s
thus tries to validate every signature with every ZSK, leading to BIND9 DoS 58632s
an immense amount of signature validations, until the resolver Knot Resolver DoS 51s (Limited DNS key
concludes that the DNS record could not be authenticated. buffer size)
PowerDNS Recursor DoS 177s
Unbound DoS 1014s (Retries increase du-

Server Software
ration)
Windows Server 2022 DoS 131s
Windows Server 2019 DoS 134s
unwind (from OpenBSD7.3) DoS 29s (Limited msg-buffer
5.6 HashTrap (Many Keys x Many Hashes) size)
Technitium DoS 411s
While mitigations may be introduced to limit signature validations, dnsmasq 2.80 DoS 2s (Limited msg-buffer
it is important to note that complexity attacks can also be achieved size)
stubby 0.4.3 DoS 184s
through hash computations. The concept of the attack, we dub Hash- Cloudflare Confirmed by Developers

Service
Trap, is illustrated in the example zone in Figure 1d. In DNSSEC, Google Confirmed by Developers
DS records from a parent zone are used to authenticate individual OpenDNS Confirmed by Developers
Quad9 Confirmed by Developers
DNSKEY records in a child zone. This is done to delegate trust from dig 9.16.1 # No DNSSEC validation
a parent zone public key to a child zone public key. DS records kdig 2.7.8 # No DNSSEC validation
delv 9.16.1 Validation logic from Bind9
use the same triple (owner name, algorithm, key tag) as RRSIGs

Tool
DNSViz 0.9.4 (latest) Crashes with exception after
do to identify a subset of candidate DNSKEYs. Only by validating attack
that the hash in the DS record matches the digest of the DNSKEY ldns-verify-zone uses vulnerable ldns library
kzonechek shipped with Knot DNS au-
can the resolver determine that a pair of DS and DNSKEY records thoritative server
actually belong together, which is an operation with worst-case named-checkzone # does not validate signatures
quadratic increase in validation complexity, similar to the algorithm dnspython -
Libs getdns used by stubby
exploited in 5.5. We construct a CPU resource consumption attack, ldns -
which abuses this DNSSEC protocol inefficiency. The attacker cre- libunbound used by Unbound
ates additional child zones of the attacker zone, represented as Table 1: Vulnerable DNS implementations.
sub-x.attack.er in Figure 1d. For each of these sub-zones, in step 1
the attacker provides numerous DS records referring to the same 6 Evaluation of the Attacks
key tag (5353), algorithm and signer name of the DNSKEYs in the
Through experimental evaluations we found all the major DNS
child. Our attacker utilizes unique digest values to ensure the DS
implementations on our dataset to be vulnerable to KeyTrap at-
records in the record set are not de-duplicated at the resolver. Since
tacks. The stalling interval caused by the attacks depends on the
these hashes are purposefully invalid, the attacker can select arbi-
specific resolver implementation. Our list of DNS software includes
trary values. The record set containing all the hashes is signed with
recursive DNS resolvers, public resolvers9 , DNS tooling, and DNS
a single signature by a ZSK of the attack.er zone.
libraries; see details in Table 1. We consider a resolver vulnerable
The resolver needs to authenticate the DNSKEY records before
if we achieve full DoS with traffic <10 req/s. All evaluations were
using the keys to validate the signatures [RFC4035]. Before authen-
conducted on an Intel Core i7-8650U quad-core processor with up
ticating the signature over the DNSKEY set the resolver first needs
to 4.2 GHz single core frequency. We describe the setup, our test
to find the DNSKEY that matches a DS record from attack.er. This is
methodology, and the cryptographic ciphers we use in our research
exploited in the attack. The attacker creates many unique DNSKEYs
zonefiles. We then evaluate the effectiveness and the impact of the
2 , all with the identical name, algorithm, and key tag (5353). To
attacks. An overview over the different DNS resolver components
find the correct key to validate with a given DS hash in the parent
relevant to the attack is given in Table 5. Note that Knot, unwind,
zone, the resolver has to iterate over all colliding keys, calculate the
and dnsmasq have tight response buffer size limitations, uninten-
hash and compare it to the hash in the DS record. This is repeated
tionally reducing the impact of the attack. In fact, this side effect
with all DS hashes in the parent zone and all DNSKEYs in the child
was recognized as a bug in Knot and fixed in the patched version
zone, which is an operation with worst-case asymptotic complexity
of the resolver 10 .
in O (𝑛 2 ), leading to a substantial amount of hash calculations that
mount severe computational load on the resolver. The resolver can 6.1 Setup
only conclude that none of the DNSKEYs can be used to authen-
ticate the signature 3 after all the hashes were calculated. Our Unless mentioned otherwise, all evaluations are run on a single
experimental evaluations show that, by means of exploiting of this CPU core. This allows us to compare between different resolvers
attack vector, hash computation is sufficiently resource intensive with various multi-threading standard configurations. We set up a
to inflict excessive load on a resolver. test environment with a number of components.
The HashTrap attack is thus constructed by leading the resolver Components. We set up resolvers and DNS servers in an iso-
to calculate many hashes for validating many colliding DNSKEYs lated environment. This ensures that attack requests are not prop-
against many DS hash records. Notice that attack variants, similar to agated to validating upstream DNS resolvers. We develop scripts
SigJam and LockCram, can also be constructed with the DS hashes 9 Tested against an instance set up by the operator for this purpose
10 https://github.com/CZ-NIC/knot-resolver/commit/
instead of signatures. However, hashes are less effective, reducing
adversary’s motivation to do that. 0b8012c2d68b7d59a55a0dca1d3f0c3042016ae9

503
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner

Keys Signatures Validations different algorithm suites11 : RSA based and Elliptic Curve Cryp-
Cipher
tography (ECC) based cryptographic algorithms. We evaluate both
ED448 907 454 411 778
ED25519 1 391 696 968 136 suites and find that the ECC based cryptographic algorithms exhibit
ECDSAP384SHA384 589 519 305 691 a significantly higher load than RSA based algorithms and surpass
ECDSAP256SHA256 828 696 576 288
RSA-512 788 696 548 448 RSA by over an order of magnitude, even when considering RSA
RSA-1024 444 413 183 372 keys with the most inefficient selection of exponents allowed by the
RSA-2048 237 228 54 036
RSA-4096 122 119 14 518 DNSSEC specification. This is consistent with previous work [15].
Table 2: Max. DNSKEYs, RRSIGs, and validations per response. ECC-based algorithms are thus better suited to maximize the im-
pact of our attacks on resolvers. We therefore focus on ECC-based
for automated dynamic generation of zonefiles and records upon algorithms in the following evaluations of the attacks.
each query, and scripts for automated construction of the DNSSEC Comparison of computation load of ECC algorithms. We
chain of trust. Generating the zonefiles dynamically enables us to evaluate if validation of different ECC algorithms results in different
use a virtually infinite number of zones and records required for processing times on different DNS resolvers. For the evaluation,
testing the attacks, which would have otherwise quickly cluttered we set up all major DNS resolvers (see Table 3) on an identical
the zone files and hampered investigations. The nameservers host hardware machine. We evaluated all resolvers by running a full
the domains used for testing the resolvers and exchanges DNS resolution with 2500 validations. Times were average over 10 at-
messages with them according to protocol specifications and spe- tempts to ensure consistency. Measuring the validation time of the
cific test semantics. Each test is hosted in a separate subdomain message instead of only measuring the validation procedure allows
consisting of one or multiple zones. This prevents cache-induced a more accurate view of the behavior of the resolvers for different
interference between consecutive executions of tests and reduces algorithms, as overall processing times might also be influenced by
implementation complexity of the investigations. Test configura- components outside the validation procedure. The measurements
tions are pre-generated from configuration templates, which we illustrate different processing times between resolvers, indicating
define using a small domain-specific language. This allows efficient differing efficiencies of the implementation. Some efficiency diver-
variations over the signature algorithms or the specific number gence is expected, as a large amount of signature validations on a
of RRSIGs and DNSKEYs in responses, which are provisioned for single RRset is not an expected use-case for resolvers and thus, it
attacking validation routines. We conduct tests by sending queries is expected that resolvers are not optimized for it. This is clearly
to the resolvers, causing them to interact with our nameservers visible in the validation times of Bind9, which supersede the other
according to the test configurations. When a nameserver receives a resolvers due to an inefficient implementation of key selection in
query it parses it, matches it against a pre-defined set of rules and the case of colliding keys.
generates a response. The rule set is loaded from a configuration The table illustrates that all resolvers take the longest validation
file upon startup, and determines which tests can be conducted, as time for signature created with algorithm 14, which is ECDSA Curve
well as the specific test semantics. A "test" specifies, e.g., a set of P-384/SHA-384. Thus, algorithm 14 is the most suited for the attacks
domains with specific DNSSEC algorithms, numbers of DNSKEYs on all resolvers, achieving maximum impact with the available
and signatures over records to validate against these DNSKEYs. maximum buffer size. Using the 384bit key size of algorithm 14, and
Transport protocol. DNS responses are typically delivered over constructing the theoretical minimal size DNS message transporting
UDP. When DNS responses are too large, e.g., exceeding the EDNS the keys, an attacker could fit up to 589 colliding DNS keys into a
size in EDNS(0) OPT header, the nameservers fall back to TCP to single DNS message. Similarly, using minimal DNS overhead, an
avoid fragmentation. Our attacks can be implemented either over attacker could fit up to a maximum of 519 signatures into a single
UDP or TCP. We implement TCP as the transport protocol between DNS message. Thus, with one resolution request with algorithm 14,
the resolvers and our nameservers. The maximum size of a DNS an attacker could theoretically trigger 589*519 = 305691 signature
message sent over TCP is dictated by [RFC1035], stating that a validations in the DNS resolver, leading to significant processing
DNS message over TCP must have a length value prefixed to the effort on the resolver. Table 2 shows the theoretical maximum
message with 2-octets size. Resulting from the size limitation of values for all commonly supported DNSSEC algorithm. Theoretical
this field, DNS payload sent in a response from the nameserver maxima are calculated by choosing the minimal possible size for all
to the resolver can have a maximum size of 216 − 1 = 65535 bytes. fields in the DNS message. In practice, the exact value of signatures
Depending on the Maximal Transmission Unit (MTU), this payload and keys that can fit into a single message is limited by the attacker
will be sent in one or more TCP segments. Therefore, the attack setup. DNSSEC messages contain additional information besides
payload (i.e., DNS/DNSSEC records) in a DNS response is limited the raw bytes of the signature or key, like the signer name, leading
to 65K bytes. to the lower number of entries in real-world attack setup. In our
evaluation setup, we make a conservative approximation on the
6.2 Identifying the Optimal Cipher for Attacks practical size of the fields in the messages, using 582 DNSKEYs per
Different DNSSEC algorithms vary in the mathematical computa- message and 340 signatures per message.
tion logic and the complexity of mathematical operations. Therefore,
the computation of DNSSEC validation for different algorithms dif-
fers in the amount of computation time. This means that the load
created by our attacks is determined also by the cryptographic ci- 11 https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-
phers the adversarial domain uses. DNSSEC generally supports two alg-numbers.xhtml

504
The Harder You Try, The Harder You Fail:
The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNSSEC CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA

Name Alg 13 Alg 14 Alg 15 Alg 16

Unbound 172 996 880 364
Bind9 888 2448 460 628
Knot 232 496 164 456
Akamai 219 976 209 392
PowerDNS 153 924 840 628
Table 3: Validation time per signature in 𝜇s.
Figure 3: SigJam attack with 10 req/s.
6.3 Effectiveness of the Attacks
To evaluate the attacks, we setup all the resolvers to query a ma- observation, we identified an inefficiency in the code, triggered by
licious domain signed with algorithm 14. During the evaluations, a large amount of colliding DNSSEC keys. The routine responsible
we use a benign DNS client that requests ten unique DNS entries for identifying the next DNSSEC key to try on a signature does not
per second from the investigated resolver and logs received replies. implement an efficient algorithm to select the next key from the
We choose a 5s timeout for benign requests, i.e., benign requests to remaining keys. Instead, it parses all keys again until it finds a key
the resolver that are not answered after 5s are considered to have that has not been tried yet. The algorithm does not lead to ineffi-
no value to the benign user and are therefore considered lost. This ciencies in normal operation with a small amount of colliding keys.
timeout is consistent with DNS tooling like dig (5s) 12 , Windows But when many keys collide, the resolver spends a large amount
DNS tools (1s-4s), and glibc (5s) 13 . of time parsing the keys and selecting the next key, extending the
KeySigTrap. Evaluating KeySigTrap, we set up a zonefile with duration of the DoS to 16h.
582 colliding DNSSEC keys and 340 signatures. We illustrate the Knot is slightly less affected by the attack than the other re-
impact of the attack on Unbound in Figure 2. As can be seen in the solvers. Evaluating the attack on Knot shows that the resolver has
plot, once the attacker triggers a single DNS request, the KeySigTrap a limited buffer size for DNSSEC keys, limiting the number of keys
attack payload in the DNS response causes the CPU usage on the per request to 126 keys. This results in a shorter DoS duration on
resolver to increase to 100% due to a large load in validating the Knot. However, the impact of the attack on Knot is still substantial
signatures. While busy validating signatures, the resolver does not with a 56s DoS from a single attack request.
answer any benign requests, leading to 100% lost benign requests In the following, we will show the impact of SigJam, LockCram,
until the resolver finishes the validation, which takes about 1014s. and HashTrap on the resolvers, illustrating how to similarly achieve
Thus, a single attacker request causes a 1014 seconds long complete maximum DoS of the resolver.
DoS of the resolver. We measured all investigated DNS resolvers SigJam. Achieving full DoS with any attack other than KeySig-
on an identical setup. The results in Table 4 show that all resolvers Trap requires more than a single attacker request. To evaluate
are heavily affected by a single request and stalled for a substantial SigJam, we send 1 attack response per second to the resolver, con-
amount of time. However, the stalling duration differs significantly taining the (maximum number of) 340 signatures in one DNS re-
between resolvers. Akamai, PowerDNS and Stubby all take about sponse. Using 340 signatures per request, we steadily increase the
3 minutes to validate the signatures. The reason is that they use amount of attacker’s requests until we observe no increase in lost
similar cryptographic implementations, validating through all key- benign queries. As illustrated in Figure 3, 10 req/s cause a severe
signature pairs until they return a SERVFAIL to the client. We load on the resolver, leading to 75% lost benign traffic. The reason
find that on average, a KeySigTrap request causes 2.000.000x load for intermediate responses to benign queries is I/O when the re-
compared to benign requests, reducing resolver throughput to 0 in solvers wait for new signatures. We find that on average, a SigJam
any tested resolver. However, we observed three notable outliers in request is able to displace 773 benign requests, i.e. a SigJam request
the DoS duration of the attack. causes 773x load compared to begin traffic. For a resolver capable
Unbound is DoSed approximately six times longer than the other of handling 1000 requests in real-time, the throughput is reduced to
resolvers. The reason is the default re-query behavior of Unbound. 227 req/s with a single SigJam request per second. This also explains
In a default configuration, Unbound attempts to re-query the name- why we do not see improvement in effectiveness of the attack with
server five times after failed validation of all signatures. Therefore, more malicious requests. The resolver still needs to conduct I/O
Unbound validates all attacker signatures six times before returning operations, hence intermediate requests get processed.
SERVFAIL to the client. This explains the extended DoS of Unbound LockCram. We evaluate the LockCram attack using 582 keys of
compared to the other resolvers. Disabling default re-queries, we algorithm 14 on Unbound. The attack starts with 1 attacker request
find Unbound is DoSed for 176s on a single KeyTrap request. per second. We increase the rate of attack until we see no increase
Bind9 is the second major outlier. The resolver is stalled for over in lost benign requests. At 10 attack req/s, we achieve full DoS
16h with a single attacker request. Investigating the cause for this of the resolver, with > 99% loss of benign requests, see Figure 5.
12 https://linux.die.net/man/1/dig The figure illustrates that the validation of the signature against
13 https://linux.die.net/man/5/resolv.conf all colliding keys results in 100% utilization of the CPU. In contrast

Figure 2: KeySigTrap attack on Unbound with single request. Figure 4: HashTrap attack with two requests per second.

505
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner

Resolver OS Buffer Discard Reply Retries Processing Multithreading

Fills old packets to cached Order
Unbound Y N N 5 Mesh Internal (L/I)
Bind9 Y N N 0 Mesh Internal (L/I)
PowerDNS Y Y N 0 Mesh Internal (L/I)
Knot Y N N 0 Seq. OS (L/I)
Stubby Y N N 0 Mesh OS (L/I)
Akamai N N Y 0 Mesh Internal (L/D)
Figure 5: LockCram attack with 10 req/s. Table 5: Components in resolvers.
L/I: Load-Independent, L/D: Load-Dependent

to SigJam, we do not see intermediate replies while the attack is requests. The requests are stored in the OS buffer, which eventually
running. The reason is that LockCram attack requires much lower fills, resulting in loss of subsequent inbound packets.
I/O effort than SigJam. In the first attack request of the evaluation, Note that packets may also get lost even if the buffer is not full.
the resolver needs to download and validate the RRSet containing all We find that PowerDNS discards old packets by default. When
colliding keys. In subsequent requests, the resolver already has the depleting the OS UDP buffer after the attack is over, PowerDNS
keys cached and only needs to download one signature. Thus, the discards any packets older than 2s. This means that during the
resolver spends much less time idling during the attack, preventing KeyTrap attack, any benign request arriving at PowerDNS earlier
it from answering benign requests while waiting for attack I/O. than 2s before the end of the attack does not get answered. If the
On average, a LockCram request is able to displace 815 benign OS buffer fills up more than 2s before the attack is over, the OS
requests, i.e. a LockCram request causes 815x load compared to drops the packets that PowerDNS would still answer to, resulting
benign requests. in PowerDNS not sending out any replies to benign requests after
HashTrap. We evaluate the HashTrap attack using digests of the attack is over.
type 2 (SHA256) as it requires the largest amount of time to compute
on a 64-bit system. Since the calculation time of the hashes does 6.5 Effect on Clients
not depend on the key size, we chose the smallest possible DNSSEC We also monitor the responses sent by the resolver to a benign DNS
keys, fitting as many keys as possible in one DNS message and client during the attack. The client continuously requests unique un-
thereby maximizing the number of hash calculations. The smallest cached records from the tested resolver and logs when it receives
key size of common DNSSEC algorithms is given by algorithm an answer. With this setup, we can evaluate if the resolver still
15, using 256-bit keys. Using 256-bit keys allows us to fit 1357 DS answers to benign requests while busy validating the signatures
records, and 1357 DNSKEYs in one attack request, resulting in 1357 from the attack request.
* 1357 = 1.841.449 hash calculations per request. The impact is illustrated in Figure 7. In Unbound as well as in
We start the evaluation with 1 attack request per second and all other resolvers we investigated, the resolver does not answer to
increase the rate until we observe no further increase in lost benign client requests while busy validating the signatures of the attacker
requests at 2 attack requests per second. As can be seen in Figure request. This can be seen in the graph, showing the amount of
4 the attack leads to 98% lost benign request. The 2% queries still answers the client receives over time. Once the attack request is
answered are again caused by I/O operations of the resolver, allow- sent at two seconds, the resolver stops answering to any benign
ing it to answer some benign queries. We find a greater impact on requests. Only after it finishes processing the attacker request, the
maximum throughput, with one HashTrap request displacing 1254 resolver again answers to benign queries at around 25s. The graph
benign requests. illustrates that the impact of the attack is severe, as it results in a
full DoS of the resolver while the attack is running.
6.4 Effect on Inbound/Pending DNS Packets
When resolvers are stalled from our attacks, they can neither pro- 6.6 Multi-Threading
cess pending requests nor respond to clients queries, even for Multi-threading is supported by all major DNS resolvers and in-
records that could otherwise be responded from the cache. We fluences how KeyTrap attacks affects their response behavior. To
find that a query that arrives during the time that a resolver is investigate the influence of multi-threading, we set up all resolvers
stalled is generally not discarded but is placed in a buffer for later with multi-threading enabled. Figure 6 illustrates the influence
processing. In normal operation, the resolver continuously reads of multi-threading on the attack. When using additional threads,
requests from the buffer and processes them, either by replying the resolver is still able to answer to some benign requests, even
from cache or with a recursive DNS resolution. During a KeyTrap while busy validating the signatures. Code review shows that the
attack, resolvers are stalled in validation and do not process new resolvers do not consider the load on a thread for scheduling, which
explains why approximately half of the requests are still scheduled
Name DoS Duration on a thread that is busy validating signatures. These requests are
Unbound 1014s lost. Answering benign requests while validating signatures ex-
Bind9 58632s
Knot 51s* tends the duration that the resolver takes to complete validation by
Akamai 186s a short amount, in the case of Unbound by about 20s. Note that due
PowerDNS 170s
Stubby 184s to inherent pseudo-randomness in the scheduling of requests to the
Table 4: DoS duration with single attack request.
threads, and the scheduling of different threads to run by the OS, a
*Knot has a limited buffer for DNSSEC keys (126 keys), allowing for a smaller attack small fluctuation of the percentage of lost requests can be observed
payload. in the graph. We observe similar fluctuations in all resolvers. We

506
The Harder You Try, The Harder You Fail:
The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNSSEC CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA

Figure 6: KeyTrap attack on Unbound with 1 request and 2 threads. Figure 8: KeyTrap attack on Unbound with 5 requests and 5 threads.

find one resolver, Cacheserve by Akamai, that does not lose parts 6.7 Cached Entries
of its traffic when multi-threading is deployed. The reason is that it DNS resolvers implement a cache to answer recently requested en-
considers thread load in the allocation of new requests to worker tries without recursive resolution. This greatly improves efficiency
threads, leading to no lost benign requests while Cacheserve has of the resolver, as certain domains are requested more frequently,
open threads not busy validating attack signatures. like domains of commonly used websites. However, since all the
The attacker can circumvent the supposed protection from multi- resolvers, except CacheServe, handle replies to cached entries on
threading by sending multiple requests to the resolver. In the case of the same thread as recursive resolution and validation, caching does
Akamai, the scheduling algorithm that considers the load of threads not mitigate the attack. In contrast, since CacheServe implements
still allows the attacker to fill all threads with the attack. Since every a separate thread for answering cached entries, the effect of the
new attacker request will be scheduled to a free thread, the attacker attack is partially mitigated.
only needs to send as many attacker requests as there are threads
in Cacheserve. No request will be scheduled to an already busy 6.8 Continuous KeySigTrap Attack
thread. In contrast, for all other resolvers, the success of the attack Using the insights gained from the previous sections, we construct
is influenced by the pseudo-random scheduling algorithm. Since a continuous attack on resolvers. In the initial phase of the attack,
allocation of requests to threads is not known to the attacker, the the attacker sends multiple KeySigTrap requests simultaneously.
attacker needs to send more requests than there are threads in Sending multiple requests ensures that the resolver gets stalled for
victim resolver to ensure all threads are hit, even if the scheduling a substantial amount of time and, in the case of multi-threading, all
algorithm, by chance, schedules multiple attack requests to the same threads get hit with an attack and are busy validating signatures.
thread. In the case of fully random scheduling, the average amount The DNS implementations we tested in this work use 2-6 resolution
of attack requests needed to fill all victim threads can be calculated threads, depending on the resolver and the size of the deployment.
by 𝐸 = 𝑛 × 𝑛𝑖=1 1𝑖 where n is the number of threads in the resolver.
Í
Creating a real-world scenario, we thus evaluate our continuous
Since schedulers are usually optimized to distribute systematically attack on an Unbound instance running with 4 resolution threads.
to the threads, the real world average number of requests required The requests should be timed in such a way that new requests
to hit all threads will generally be lower than the random value. The are always already in the buffer once a request from the previous
effect of sending multiple queries can be seen in Figure 8. The graph batch finishes. Using the validation time of a single attack request
shows a scenario where the attacker sends five attacker requests to in Unbound, not considering re-tries, we find a single request ap-
an instance of Unbound running with five worker threads on five proximately stalls a thread for about 176s (see Table 4). We choose
CPU cores. As seen in the graph, the five requests do not suffice an interval half of this duration. We further send 12, three requests
to saturate the threads, as one threads remains active in replying per thread of the resolver, to ensure all validation threads are hit
to benign queries, leading to approximately 80% lost requests. The with the attack. The attack uses the following steps:
fact that two attacker requests were scheduled to the same thread
can be observed in the second half of the plot. While the validation 1. Send a batch of 12 initial attack requests
finishes in three threads, reducing the rate of lost requests by 60%, 2. Wait 1s to ensure the batch has been read
one thread continues validating signatures for almost twice as long, 3. Send batch of 12 follow-up request + buffer filler
4. Wait 90s
indicating that two requests were scheduled to a single thread.
5. Go back to 3.
These observations show that multi-threading is no sufficient
protection against the attack, as the attacker, when sending a suffi- The result of this attack is plotted in Figure 9. The attack achieves
cient amount of attack requests, can hit all threads of the resolver, a complete DoS of the resolver for the entire 2h measurement
leading to a comprehensive DoS of the resolver. It also illustrates duration, with 99.999% of benign requests lost. All 4 processor
that one attack request is not sufficient for a complete DoS of the cores continuously run on 100% CPU utilization, validating the
resolver when multi-threading is used. signatures. The attacker only requires traffic of 13 request per 90s,
i.e., on average one request every 6.9s. This attack rate is low enough
to prevent any rate-limiting mechanisms from blocking follow up
attacker requests in a real-world setting.
This evaluation demonstrates that KeySigTrap is a practical at-
tack, achieving a continuous DoS even on a multi-threaded resolver.
Even a small-scale attacker can exploit KeySigTrap to fully stall
DNS resolution in the resolver for other clients for an indefinite
Figure 7: Impact on benign requests in Unbound under attack. amount of time.

507
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner

7 The Path to Mitigations

The detrimental impact of KeyTrap attacks if exploited in the wild
on vulnerable resolvers necessitated patches before the flaws and
our attack methodologies become public. We have thus been closely
working with the developers of DNS resolvers since November 2,
2023 on developing mitigations against our attacks. We initiated the
disclosure process on November 2. 2023, following which a group
was formed of 31 participants, consisting of vendors of DNS soft-
ware, operators of DNS/Cloud/CDN, and IETF experts. The group
communicates over a closed DNS OARC channel established for
disclosure and mitigations of our attacks. We describe the timeline
of disclosure and mitigations in Figure 10. Figure 10: Disclosure and patch/break/fix timeline.
The immediate short-term recommendations to mitigate an on-
going attack are to disable DNSSEC or to serve stale data. Serving were subsequently fixed, following with new patches. We illustrate
stale data to improve DNS resiliency was proposed in [RFC8767]. the timeline of the disclosure and the patch-break-fix iterations
Vendors that decide to implement this should make sure to return with the vendors in Figure 10. We next explain the patches and our
stale data from a separate thread, not the one that also does the attacks against them.
DNSSEC validation, otherwise the resolvers remain stalled. Dis- Limiting failures. The initial “immediate” mitigation was to
abling DNSSEC validation in resolvers would help remediate an limit the maximum amount of validation failures per resolution. It
ongoing attack. However, this would also expose clients and re- was first implemented by Akamai, with a limit of 32 on the number
solvers to threats from DNS cache poisoning. Worse, an adversary of failed validations, then Bind9, which limited the failures to 0
could abuse this fallback to insecure mode as means to downgrade and Unbound, with a limit of 16 failures. We found the limitation
the DNSSEC protection. not to be an effective mitigation against our attacks. If each query
We worked with the DNS developers to integrate systematic is limited in the number of failures it is allowed to result in, the
mitigations into their software. In the following, we describe the failures can be spread across multiple queries. To demonstrate
succession of proposed patches, showing how we evaluated and cir- this, we extended the KeyTrap attack (presented in §5.5) so that
cumvented their protection against KeyTrap. The process illustrates the signature validations are distributed across multiple queries,
the challenges in mitigating such powerful attacks as KeyTrap at- such that each query causes the resolver to perform 32 signature
tacks and variants of it. We also present the first working solution validations. Thus instead of creating multiple validations with a
that will be published, in variations, as patches for all major DNS single query we sent multiple queries. In a setup with Akamai DNS
resolvers. The operators of the open DNS resolvers have already resolver instance, 150 requests per second cause the CPU to get
deployed patches. The releases of patches for DNS software have stalled. This showed that the limit of 32 was not strict enough.
been scheduled by the different vendors to be deployed between Zero failures. The strictest patch on the cryptographic failures
end of January and beginning of February. It is important to note was implemented by Bind9, returning SERVFAIL after a single cryp-
that these patches all disobey the Internet standard in certain as- tographic failure, hence removing the need to check for collisions
pects, including the number of validations they are willing to do, at all. Although allowing 0 failed validations prevents the KeyTrap
to protected against the flaws within the standard. attack, it does not mitigate hash collision attack with HashTrap
(§5.6). HashTrap causes the resolver to perform a very large amount
7.1 Patch-Break-Fix DNSSEC of hash calculations. Experimentally, using 10 requests per second,
we showed that HashTrap inflicts DoS on the patched instance of
Agreeing on which patches to deploy required a number of itera-
Bind9 resolver. The evaluation is plotted in Figure 11: As can be
tions. The developers did not want to make substantial changes,
seen, during the attack against the patched Bind9 instance more
and rather aimed at patches that would mitigate the attacks with
than 72% of benign requests are lost. We observe that most benign
minimal changes. This is understandable, since complex patches
requests get dropped. This variant of the attack shows that merely
required more extensive testing over longer time periods to confirm
limiting the amount of signature validation failures is not a resilient
that they do not introduce new flaws, are interoperable with other
mitigation against our DoS attacks.
mechanisms, and do not incur failures in the wild. Nevertheless,
Limiting key collisions. A patch by Akamai, in addition to
developing quick patches turned into a lengthy iterative process,
limiting the signature validation failures, also limited the key tag
during which the vendors developed patches that we broke, which
collisions in DNS responses to contain at most 4 keys with colliding

Figure 9: Continuous KeyTrap attack on 4-threaded Unbound. Figure 11: HashTrap attack on patched Bind9 with 10req/s.

508
The Harder You Try, The Harder You Fail:
The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNSSEC CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA

Figure 12: ANY-type derivation of SigJam on Akamai. Figure 13: ANY type attack with 10req/s on patched Akamai.

tags. We find that limiting key tag collisions to 4 will not impact load. Notice however that we are still closely working with the
normal operation of the resolver. Using data from the Tranco Top1M developers on testing the patches and their performance during
domains, we find experimentally that only two zones have colliding attack and during normal operation.
DNSKEYS, with no zone using more than two colliding keys.
Limiting key tag collisions proved successful in protecting against
7.2 Improving Resilience of Architecture
HashTrap. The combination of both patches was nevertheless still
vulnerable to a variant of the SigJam attack (§5.3). The attack works To understand the impact of the attacks on various DNS function-
with a single DNSSEC key and many signatures, but requires no ality, including caching, pending DNS requests or inbound DNS
signature validation failures, thereby circumventing the protection packets from the clients as well as from the nameservers, we per-
offered by the patch. We use ANY type responses, which contain form code analysis and evaluations. Our observations from the
many different record sets, each signed with a different signature. analyses can be used to enhance the robustness to failures and
We can create arbitrary numbers of different record sets, so that on attacks of implementations:
the one hand the number of signatures is maximized, and on the Multi-threading. Using code analysis and experimental eval-
other hand, the response still fits into one DNS packet. We vary uation of the multi-threading architecture of the DNS implemen-
over the type number field on an A-type record to create a large tations, we find that load of processes is generally not considered
number of small, unallocated-type record sets, each covered by an in scheduling new DNS requests, leading to substantial loss of re-
individual, valid signature. In our tests with standard DNS software, quests even if not all threads of a resolver are busy. Further, we
we created DNS responses with 313 different record sets. Following find resolvers do not consider the computational effort of a given
[RFC6840, §4.2] the resolver MUST validate the signatures on all request, leading to loss of benign requests, if a single request creates
the record sets. Since all signatures are valid, the resolver does a large load on the resolver. We contribute the architectural recom-
not fail from the imposed limit on validation failures and instead mendation that resolvers should de-prioritize DNS requests that
continues the validation until all signatures on the unallocated-type cause substantial computational load, allowing the resolver to still
records have been checked. We found this attack to be effective answer benign clients even under attacks. This de-prioritization
against all patches that limit cryptographic failures. The success of is in line with previous work recommendations on mitigations of
the attack on a patched Akamai is illustrated in Figure 12. In the complexity attacks, like presented by Atre et al. [3].
evaluation, the attacker sends 4 ANY type requests per second, a OS buffers. We find that the resolvers generally only deplete
rate at which the attacker is able to completely DoS the resolver the OS UDP buffer after a batch of tasks has been finished. This
after a few seconds. Running the attack for 60s, we were able to causes the buffer to fill up when the resolver is busy, leading to
achieve over 90% lost benign queries. The attack can thus DoS the lost benign requests. We recommend to adapt the architecture of
resolver, circumventing the patch. The attack that exploits ANY resolvers to allocate a separate thread for reading from the OS buffer
type records illustrates that limiting only the cryptographic failures and placing pending requests in a dynamic internal buffer.
is not a sufficient mitigation against the complexity attacks. Thread for cached records. Further, since many benign queries
Limiting all validations. The first working patch capable of by users can be answered from cache, additionally allocating a
protecting against all variants of our attack was implemented by separate thread for answering to cached entries can reduce the
Akamai. Additionally to limiting key collisions to 4, and limiting impact of stalling of resolution threads.
cryptographic failures to 16, the patch also limits total validations
in ANY requests to 8. Evaluating the efficacy of the patch, we find 7.3 Implementation Challenges
the patched resolver does not lose any benign request even under The experience we made working with the developers on designing
attack with > 10 requests per second. Illustrated in Figure 13, the and evaluating the patches showed that the vulnerabilities we found
load on the resolver does not increase to problematic levels under were challenging to patch. We not only showed that patches could
the ANY type attack with 10 req/s, and the resolver does not lose any be circumvented with different variants of our attack, but also dis-
benign traffic. It thus appears that the patch successfully protects covered problems in the implementations themselves. We provide
against all variations of KeyTrap attacks. Nevertheless, although here examples from two major implementations: Knot and Bind9.
these patches prevent packet loss, they still do not fully mitigate During the evaluations we found that a patch for Knot, that was
the increase in CPU instruction load during the attack. The reason supposed to limit requests to 32 failed validations per resolution,
that the mitigations do not fully prevent the effects of the KeyTrap was not working as intended. While the patch reduced the number
attacks is rooted in the design philosophy of DNSSEC. For example, of validations resulting from a single attacker request, it did not
we find that in a patched Unbound, an attacker request can still sufficiently protect against an attacker sending multiple requests
displace the processing equivalent of 8 benign requests under full in a short time frame. With 10 attacker requests per second, the

509
CCS ’24, October 14–18, 2024, Salt Lake City, UT, USA Elias Heftrig, Haya Schulmann, Niklas Vogel, and Michael Waidner

Acknowledgements
This work has been co-funded by the German Federal Ministry of
Education and Research and the Hessen State Ministry for Higher
Education, Research and Arts within their joint support of the
National Research Center for Applied Cybersecurity ATHENE and
Figure 14: KeyTrap against patched Knot. by the Deutsche Forschungsgemeinschaft (DFG, German Research
Foundation) SFB 1119.

patched Knot implementation dropped over 60% of benign queries, References

as shown in Figure 14. We traced the bug to be a broken binding, [1] Yehuda Afek, Anat Bremler-Barr, and Lior Shafir. { NXNSAttack } : Recursive
which the developers fixed in the subsequent iterations of patches. { DNS } inefficiencies and vulnerabilities. In 29th USENIX Security Symposium
(USENIX Security 20), pages 631–648, 2020.
The second example is a problematic patch in Bind9. While [2] Yehuda Afek, Anat Bremler-Barr, and Shani Stajnrod. { NRDelegationAttack } :
evaluating the patch with 10 requests per second to the patched Complexity { DDoS } attack on { DNS } recursive resolvers. In 32nd USENIX
resolver, we found that after about 70s the resolver would consis- Security Symposium (USENIX Security 23), pages 3187–3204, 2023.
[3] Nirav Atre, Hugo Sadok, Erica Chiang, Weina Wang, and Justine Sherry. Surge-
tently crash, causing 100% loss of benign queries. This bug was also protector: Mitigating temporal algorithmic complexity attacks using adversarial
communicated to developers and fixed in later patches. scheduling. In Proceedings of the ACM SIGCOMM 2022 Conference, pages 723–738,
2022.
[4] Jonas Bushart and Christian Rossow. Dns unchained: amplified application-
8 Ethical Considerations layer dos attacks against dns authoritatives. In Research in Attacks, Intrusions,
Due to the potentially severe impact of KeyTrap, we limited all and Defenses: 21st International Symposium, RAID 2018, Heraklion, Crete, Greece,
September 10-12, 2018, Proceedings 21, pages 139–160. Springer, 2018.
our evaluations to a local test setup without testing the KeyTrap [5] Marco Carvalho, Jared DeMott, Richard Ford, and David A Wheeler. Heartbleed
attack on any open, publicly accessible resolver. We disclosed the 101. IEEE security & privacy, 12(4):63–67, 2014.
[6] Taejoong Chung, Emile Aben, Tim Bruijnzeels, Balakrishnan Chandrasekaran,
vulnerabilities we found to a closed group of experts over 3 months David Choffnes, Dave Levin, Bruce M Maggs, Alan Mislove, Roland van Rijswijk-
before they were made public through open-source patches and ac- Deij, John Rula, et al. Rpki is coming of age: A longitudinal study of rpki
companying posts by the developers. Operators were notified about deployment and invalid route origins. In Proceedings of the Internet Measurement
Conference, pages 406–419, 2019.
the imminent important patches with sufficient preparation time [7] Douglas Everson, Long Cheng, and Zhenkai Zhang. Log4shell: Redefining the
and patches were delivered to large operators ahead of time, before web attack surface. In Workshop on Measurements, Attacks, and Defenses for the
the vulnerability became public. We ensured quality of developed Web (MADWeb) 2022, 2022.
[8] Joseph Gersch and Dan Massey. Rover: Route origin verification using dns. In
patches by continuously working with the developers, improving 2013 22nd International Conference on Computer Communication and Networks
their patches and closing discovered flaws. From the practical per- (ICCCN), pages 1–9. IEEE, 2013.
[9] Elias Heftrig, Haya Shulman, and Michael Waidner. Downgrading DNSSEC: How
spective, current patches sufficiently protect against the impact of to Exploit Crypto Agility for Hijacking Signed Zones. In 32nd USENIX Security
the attacks. Symposium (USENIX Security 23), pages 7429–7444, 2023.
[10] Dan Kaminsky. It’s the End of the Cache As We Know It. In Black Hat confer-
ence, August 2008. http://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-
9 Conclusions Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf.
Our work revealed a fundamental design problem with DNS and [11] Asif Karim, Sami Azam, Bharanidharan Shanmugam, Krishnan Kannoorpatti, and
Mamoun Alazab. A comprehensive survey for intelligent spam email detection.
DNSSEC: Strictly applying Postel’s Law to the design of DNSSEC in- IEEE Access, 7:168261–168295, 2019.
troduced a major and devastating vulnerability in virtually all DNS [12] Marc Kührer, Thomas Hupperich, Christian Rossow, and Thorsten Holz. Exit
from hell? reducing the impact of { Amplification } { DDoS } attacks. In 23rd
implementations. With just one maliciously crafted DNS packet an USENIX security symposium (USENIX security 14), pages 111–125, 2014.
attacker could stall almost any resolver, e.g., the most popular one, [13] Ueli Maurer. Modelling a public-key infrastructure. In Computer Secu-
Bind9, for as long as 16 hours. rity—ESORICS 96: 4th European Symposium on Research in Computer Security
Rome, Italy, September 25–27, 1996 Proceedings 4, pages 325–350. Springer, 1996.
The impact of KeyTrap is far reaching. DNS evolved into a fun- [14] Giovane C. M. Moura, Sebastian Castro, Wes Hardaker, Maarten Wullink, and
damental system in the Internet that underlies a wide range of Cristian Hesselman. Clouding up the internet: how centralized is DNS traffic
applications and facilitates new and emerging technologies. Mea- becoming? In Internet Measurement Conference, pages 42–49. ACM, 2020.
[15] Roland van Rijswijk-Deij, Kaspar Hageman, Anna Sperotto, and Aiko Pras.
surements by APNIC14 show that in December 2023, 31.47% of the The performance impact of elliptic curve cryptography on dnssec validation.
web clients worldwide used DNSSEC-validating resolvers. There- IEEE/ACM transactions on networking, 25(2):738–750, 2016.
[16] Roland van Rijswijk-Deij, Anna Sperotto, and Aiko Pras. Dnssec and its potential
fore, our KeyTrap attacks have effects not only on DNS but also on for ddos attacks: a comprehensive measurement study. In Proceedings of the 2014
any application using it. An unavailability of DNS may not only Conference on Internet Measurement Conference, pages 449–460, 2014.
prevent access to content but risks also disabling security mecha-
nisms, like anti-spam defenses, Public Key Infrastructure (PKI), or
even inter-domain routing security like RPKI or rover [6, 8, 11, 13].
Since the initial disclosure of the vulnerabilities, we have been
working with all major vendors on mitigating the problems in
their implementations, but it seems that completely preventing the
attacks requires to fundamentally reconsider the underlying design
philosophy of DNSSEC, i.e., to revise the DNSSEC standards.

14 https://stats.labs.apnic.net/dnssec/XA

510