DNS Operations X.L. Li Internet-Draft Y.Q. Qiu Intended status: Informational Nankai University Expires: 30 December 2026 June 2026 Strengthening DNS Query Aggregation against ECS-based Attacks draft-li-dnsop-ecs-aggregation-fix-02 Abstract The DNS query aggregation mechanism is a critical defense against DNS cache poisoning attacks that exploit the "Birthday Paradox". However, recent research has revealed that flawed implementations of the EDNS Client Subnet (ECS) option, as specified in RFC 7871, can be exploited to bypass this defense. This allows attackers to force a resolver to issue multiple simultaneous queries for the same domain name by crafting queries with different ECS options. This vulnerability revives the classic DNS Birthday Attack, posing a significant threat to DNS resolvers and the clients they serve. Section 11.2 of RFC 7871 notes the general risk of Birthday Attacks and suggests marking whether responding nameservers send ECS options, but it does not define a concrete mechanism. This document turns that observation into a specified processing model for the ECS option in DNS resolvers. A resolver tracks, per zone, whether the authoritative servers use ECS: a "no-ECS-support" state forces query aggregation for zones that do not use ECS, and an "ECS-support" state lets a resolver treat an unexpected response without an ECS option (or one with a zero scope) as suspect for zones that do, such as content delivery networks. The document also describes how a resolver bounds the residual risk with a limit on simultaneous outstanding queries. It is offered as input that the working group could fold into a future revision of RFC 7871. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Li & Qiu Expires 30 December 2026 [Page 1] Internet-Draft Strengthening DNS Query Aggregation June 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to RFC 7871 . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Bypassing Query Aggregation with ECS . . . . . . . . . . . . 5 3. Updated Resolver Behavior . . . . . . . . . . . . . . . . . . 6 3.1. Principle of ECS Coherence . . . . . . . . . . . . . . . 6 3.2. Handling Responses Containing an ECS Option . . . . . . . 6 3.3. Handling Responses Lacking an ECS Option . . . . . . . . 7 3.4. Updated Query Aggregation Logic . . . . . . . . . . . . . 7 3.5. Scope and Accuracy of the no-ECS-support State . . . . . 8 3.6. Bounding the Learning Window . . . . . . . . . . . . . . 9 3.7. Zones That Do Support ECS . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Li & Qiu Expires 30 December 2026 [Page 2] Internet-Draft Strengthening DNS Query Aggregation June 2026 1. Introduction The Domain Name System (DNS) [RFC1034] [RFC1035] is a fundamental component of the Internet, but its security has been a long-standing concern, with DNS cache poisoning [HITCHHIKER] remaining a persistent threat. Following the discovery of widespread vulnerabilities to off-path attacks [KAM_ATTACK], a number of defenses were developed. One of the earliest and most effective of these is the query aggregation mechanism implemented in DNS resolvers. This mechanism ensures that multiple identical incoming queries (matching in qname and qtype) result in only a single query being sent to an authoritative nameserver. This thwarts attackers seeking to increase their chances of success by forcing many simultaneous outbound queries, a technique known as the DNS Birthday Attack [SACRAMENTO]. The EDNS Client Subnet (ECS) extension [RFC7871] was introduced to provide network location information of the client to authoritative nameservers, enabling them to provide more geographically or topologically relevant answers. While beneficial for performance, the processing logic for ECS has introduced a subtle but critical security flaw. Many resolver implementations expand their query aggregation key from to . An attacker can exploit this behavior by sending a large number of queries for the same qname and qtype but with different, spoofed client subnets. A vulnerable resolver will fail to aggregate these requests and will instead issue a multitude of distinct queries upstream. This bypass, and its prevalence across deployed resolvers, has been demonstrated and measured [REBIRTHDAY]. A crucial aspect of this vulnerability is that [RFC7871] specifies that a response from an authoritative server without an ECS option is still a valid reply to a query that contained one. This allows an attacker to inject a single type of forged response (lacking an ECS option) that has a high probability of matching one of the many outstanding queries, thereby poisoning the resolver's cache. Several widely deployed resolvers have independently added mitigations for this attack. Their behavior differs in detail; for example, on detecting an inconsistent ECS response, some reissue the query without an ECS option while others fall back to TCP. This class of issue has been assigned multiple CVE identifiers [REBIRTHDAY]. Such divergence between independent mitigations is what an interoperable specification is meant to resolve, and it is the motivation for this document. Li & Qiu Expires 30 December 2026 [Page 3] Internet-Draft Strengthening DNS Query Aggregation June 2026 1.1. Relationship to RFC 7871 Section 11.2 of [RFC7871] already identifies the core of this attack. Because a response that lacks an ECS option is treated as a valid reply, an attacker "just needs to flood back responses that have no ECS option at all". Section 11.2 then suggests two ways to detect this, but does not specify either one. The first is "marking whether the responding nameserver had previously been sending ECS options". The second is "taking note of an incoming flood of bogus responses and flagging the relevant query for re-resolution". RFC 7871 also records the limits of these ideas in its own words: "This type of detection is more complex than existing nameserver responses to spoof floods, and it would also need to be sensitive to a nameserver legitimately stopping ECS replies even though it had previously given them." This document develops that first idea into a specified mechanism and applies it in both directions. In the negative direction, a zone whose authoritative servers do not send ECS is marked "no-ECS- support", and queries to it are aggregated regardless of their ECS option. In the positive direction, a zone whose servers consistently do send ECS is marked "ECS-support", and a response that then unexpectedly lacks an ECS option is treated as suspect instead of, as Section 7.3 of [RFC7871] would have it, valid for every client. The positive direction is what protects zones that genuinely use ECS, including CDNs, which are otherwise the highest-value targets (see Section 3.7). This document does not adopt the second idea, the re- resolution flagging, because that approach carries the false positive risk that RFC 7871 itself points out: a nameserver that legitimately stops sending ECS replies would look like an attack. In its place, this document uses a simple limit on the number of simultaneous outstanding queries for one name (see Section 3.6), which bounds the attack without trying to tell an attack flood apart from normal traffic. Compared with the brief discussion in Section 11.2, this document specifies: * when a resolver sets and clears a per-zone "no-ECS-support" state, and how it avoids the false positive that Section 11.2 warns about (see Section 3.5); * how that state forces aggregation of queries that differ only in their ECS option; * that the resolver stops adding ECS options to upstream queries for such a zone; Li & Qiu Expires 30 December 2026 [Page 4] Internet-Draft Strengthening DNS Query Aggregation June 2026 * how a resolver protects a zone that does use ECS, by marking an "ECS-support" state and treating an unexpected response without an ECS option as suspect (see Section 3.7); * that a state change in either direction is driven only by a response the resolver has accepted as an answer, so that a spoofed flood cannot flip the state; * how a resolver bounds the short window before the state is established (see Section 3.6). This document is Informational and is offered as input toward a future revision of [RFC7871]. The BCP 14 keywords used below state the resolver behavior proposed for that revision; they place no new requirement on RFC 7871 as it stands today. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Bypassing Query Aggregation with ECS The vulnerability stems from the interaction of two factors: a flaw in resolver query aggregation logic and a permissiveness in the ECS specification. The attack proceeds as follows: 1. Query Initiation: The attacker sends a high volume of DNS queries for a target domain (e.g., "victim.example.com A") to a vulnerable resolver. Each query is identical in qname and qtype but contains a unique, forged ECS option (e.g., with different subnets). 2. Bypassing Aggregation: The vulnerable resolver treats each query as unique due to the different ECS options. Instead of sending a single query upstream, it forwards a large number of queries to the authoritative nameserver for "example.com", each with a different source port. 3. Race Condition: The attacker simultaneously floods the resolver with forged DNS responses for "victim.example.com". Crucially, these forged responses do not contain an ECS option. The attacker brute-forces the 16-bit Transaction ID (TxID) and attempts to guess one of the many source ports used by the resolver. Li & Qiu Expires 30 December 2026 [Page 5] Internet-Draft Strengthening DNS Query Aggregation June 2026 4. Cache Injection: According to [RFC7871], a response without an ECS option is a valid reply. If the attacker's forged response matches the TxID and source port of any of the outstanding queries, the resolver accepts it. The malicious record is then cached, and subsequent legitimate queries for that domain name will receive the poisoned data. The Birthday Paradox dictates that the probability of a successful collision increases dramatically with the number of outstanding queries, making this attack highly practical against vulnerable implementations. This attack applies only to resolvers that have enabled ECS. A resolver that does not send ECS, which Section 11.3 of [RFC7871] recommends as the default, never expands its aggregation key and is not exposed. Disabling ECS, however, forgoes the performance benefit that leads operators to deploy it in the first place. The mechanisms in this document are for resolvers that choose to keep ECS enabled and need to remain safe while doing so. 3. Updated Resolver Behavior 3.1. Principle of ECS Coherence To mitigate this attack, resolvers MUST handle ECS options coherently. Coherence means that a resolver's caching and query aggregation behavior MUST account for whether an authoritative server for a given zone actually uses the ECS information provided to it. A resolver MUST NOT continue to treat queries as unique based solely on varying ECS options once it holds evidence, in the form of the "no- ECS-support" state defined below, that the authoritative server does not support or utilize ECS for that zone. Coherence applies in both directions: a resolver also benefits from recognizing zones that do consistently use ECS, so that a later response without an ECS option for such a zone can be treated with suspicion (see Section 3.7). 3.2. Handling Responses Containing an ECS Option When a resolver receives a response that contains an ECS option, it MUST validate the fields in the response against the query that was sent, as described in Section 7.3 and Section 11.2 of [RFC7871]. If there is a mismatch in the Family, Address, or Source Prefix-Length, the entire response SHOULD be discarded. This is existing best practice and is reiterated here for completeness. Li & Qiu Expires 30 December 2026 [Page 6] Internet-Draft Strengthening DNS Query Aggregation June 2026 3.3. Handling Responses Lacking an ECS Option This is the critical change to resolver logic. Throughout this document, a response that carries an ECS option with a SCOPE PREFIX-LENGTH of 0 is treated identically to a response that omits the ECS option. Section 7.3 of [RFC7871] makes both applicable to all clients, so both give an attacker a reply that matches every outstanding query regardless of its subnet. When a resolver sends a query containing an ECS option to an authoritative nameserver and receives a valid response that lacks an ECS option, the resolver SHOULD treat this as a sign that the authoritative server for this zone may not support or may not use ECS. A resolver SHOULD record the "no-ECS-support" state for a zone only after this sign is consistent, rather than after a single response. The conditions for setting the state are described in Section 3.5. If the zone is already in the "ECS-support" state, such a response is unexpected, and the resolver first applies the suspect handling of Section 3.7 rather than immediately accepting it as a no-ECS signal. The transition toward "no-ECS-support" then proceeds only as the consistency rules of Section 3.5 are met. The resolver SHOULD cache this "no-ECS-support" state associated with the queried domain name's zone. The lifetime of this cached state MAY be tied to the TTL of the zone's NS records or a locally configured timer. A change to the recorded ECS state of a zone, in either direction (the "no-ECS-support" state here and the "ECS-support" state of Section 3.7), MUST be driven only by a response that the resolver has accepted as the answer to an outstanding query, that is, one that matches a pending query and passes the resolver's existing source- port and Transaction ID checks. A response that fails these checks MUST NOT alter the recorded state. This prevents an attacker from using a flood of spoofed responses to flip a zone's state, for example to push a zone that does use ECS into the "no-ECS-support" state and so suppress its ECS-tailored answers, which would be a lightweight denial of service against the zone's ECS optimization. 3.4. Updated Query Aggregation Logic Resolver query aggregation logic MUST be updated to incorporate the "no-ECS-support" state. Li & Qiu Expires 30 December 2026 [Page 7] Internet-Draft Strengthening DNS Query Aggregation June 2026 1. If a resolver receives multiple client queries for the same that have different ECS options, and there is no active query or existing "no-ECS-support" state for that zone, the resolver MAY forward one of these queries with an ECS option and queue the others. The queued clients may then receive an answer that was generated for a different subnet, which is safe but may be less specific. 2. If the resolver has a cached "no-ECS-support" state for the zone of a given qname, any incoming client query for that qname, regardless of the presence or value of its ECS option, MUST be aggregated with other pending queries for the same . 3. When sending an aggregated query for a zone in the "no-ECS- support" state, the resolver SHOULD NOT include an ECS option in the upstream query. This prevents the authoritative server from potentially providing a subnet-specific answer that would be incorrectly served to clients from other subnets whose queries were aggregated. By implementing this logic, a resolver will quickly learn that a zone does not support ECS and will revert to classic query aggregation based solely on , thus defeating this attack for later queries to that zone. 3.5. Scope and Accuracy of the no-ECS-support State This section addresses the concern that Section 11.2 of [RFC7871] raises about its own detection idea, namely that detection "would also need to be sensitive to a nameserver legitimately stopping ECS replies even though it had previously given them". A naive rule that reacts to a single missing ECS option would read such a legitimate change as an attack. The rules below avoid that. The "no-ECS-support" state is kept per zone, identified by the zone that the resolver used to reach the authoritative servers, that is, the closest enclosing zone for which the resolver holds NS records. ECS is widely deployed by content delivery networks, where different authoritative servers for the same zone, or different names within one zone, can behave differently. For this reason a single response without an ECS option does not prove that a zone never uses ECS. Li & Qiu Expires 30 December 2026 [Page 8] Internet-Draft Strengthening DNS Query Aggregation June 2026 To avoid a wrong decision, a resolver SHOULD set the "no-ECS-support" state only after it has seen responses without an ECS option consistently, for example across more than one response or more than one authoritative server for the zone. A resolver MAY keep the state per authoritative server instead of per zone if it tracks servers separately. If the state is set in error, the only effect is that the resolver stops sending ECS options to that zone and serves one answer to clients in different subnets. This lowers the precision of CDN based answers, but it does not break resolution. The state expires as described in Section 4, after which normal ECS behavior resumes. 3.6. Bounding the Learning Window The mechanism above protects later queries to a zone, but it can only act after the resolver has seen at least one response without an ECS option. On first contact with a zone, before the state is set, a resolver is still exposed for a short window. To bound this window, a resolver SHOULD also limit the number of simultaneous outstanding upstream queries that it will open for a single . For this limit, queries that differ only in their ECS option MUST be counted as the same entry. When the limit is reached, the resolver SHOULD queue further client queries or answer them from the result of the outstanding query, rather than open additional outstanding queries. This limit is a backstop. On its own it already reduces the number of forged responses an attacker can match against during the learning window, and it also helps when a zone's ECS behavior is inconsistent. The per-zone "no-ECS-support" state then removes the exposure for repeat queries to the same zone. The two parts work together: the limit handles first contact, and the state handles the steady state. Section 11.3 of [RFC7871] already advises resolvers to limit the number of networks and answers they keep in the cache for any given query, as a defense against cache pollution and resource exhaustion. The limit specified here is related but distinct: it bounds the number of simultaneous outstanding upstream queries, counting queries that differ only in their ECS option as one entry, and its purpose is to shrink the birthday-attack window rather than to control cache size. The two limits are complementary, and an implementation can enforce both. Li & Qiu Expires 30 December 2026 [Page 9] Internet-Draft Strengthening DNS Query Aggregation June 2026 3.7. Zones That Do Support ECS The "no-ECS-support" state is most effective for zones that do not use ECS, which are the majority. It is set by observing responses that lack an ECS option, so a zone that genuinely uses ECS, typically a content delivery network, returns responses that carry an ECS option, never enters the state, and is never subject to the forced aggregation of Section 3.4. Such zones are in fact more exposed than others: legitimate ECS fan-out already keeps many outstanding queries for a single name in flight, which widens the birthday window that an attacker can exploit. This section specifies how a resolver protects them. A resolver SHOULD maintain the mirror of the "no-ECS-support" state, an "ECS-support" state, set when a zone's authoritative servers consistently return responses that carry an ECS option. The same rules apply as for the "no-ECS-support" state: the state is changed only by responses the resolver has accepted as answers (see Section 3.3), and it is set only after the behavior is consistent (see Section 3.5). Like the "no-ECS-support" state, it has a finite lifetime and is refreshed by continued observation, so a zone that later stops using ECS is not held in the state indefinitely. This is the positive use of the same Section 11.2 signal, "marking whether the responding nameserver had previously been sending ECS options". For a zone in the "ECS-support" state, a response that lacks an ECS option contradicts the zone's established behavior. Section 7.3 of [RFC7871] would otherwise treat such a response as having SCOPE PREFIX-LENGTH 0 and therefore valid for every client, which is precisely the permissiveness the attack relies on. For such a zone, a resolver SHOULD treat a response that unexpectedly lacks an ECS option, or carries one with a SCOPE PREFIX-LENGTH of 0, as suspect: it SHOULD NOT allow a single such response to satisfy an outstanding query, and MAY require corroboration, for example by preferring a matching ECS-bearing response, re-querying, or retrying over TCP, before accepting it. This corroboration step reflects existing implementation practice: deployed resolvers have handled the inconsistent-response case by reissuing the query without an ECS option or by switching to TCP. This handling MUST remain sensitive to the case that Section 11.2 of [RFC7871] warns about, a nameserver that legitimately stops sending ECS replies. A resolver therefore MUST NOT permanently discard responses that lack an ECS option for an "ECS-support" zone. The suspect handling above is a corroboration step, not a hard drop, and the consistency rules of Section 3.5 govern the legitimate transition of a zone from "ECS-support" to "no-ECS-support". Because corroboration adds latency and extra queries for a zone whose ECS Li & Qiu Expires 30 December 2026 [Page 10] Internet-Draft Strengthening DNS Query Aggregation June 2026 behavior is mixed, a resolver SHOULD bound the number of corroboration attempts rather than retry indefinitely, and SHOULD fall back to the consistency-driven transition to "no-ECS-support" once the threshold is met. For an "ECS-support" zone, the limit on simultaneous outstanding queries (Section 3.6) remains the backstop against fan-out. Because answers for such a zone are subnet-specific, when the limit is reached a resolver SHOULD queue further client queries rather than answer them from the result of an outstanding query that was generated for a different subnet. Operators should be aware that a low limit on a popular ECS zone trades away some legitimate ECS fan- out, adding latency, in exchange for a smaller birthday window. This is a deliberate security-versus-performance choice, and the right value depends on the deployment. 4. Security Considerations The procedures outlined in this document are intended to mitigate a specific DNS cache poisoning vulnerability. By enforcing coherent ECS handling and stateful query aggregation, resolvers can prevent attackers from bypassing a fundamental security mechanism. This restores the difficulty of off-path birthday attacks to their pre-ECS levels, which are considered computationally infeasible for a properly configured resolver. A residual risk remains during the learning window described in Section 3.6. Before a resolver has recorded the "no-ECS-support" state for a zone, an attacker can still try to open many outstanding queries on first contact. The limit on simultaneous outstanding queries for a single name bounds this risk, and operators are advised to set such a limit. Zones that genuinely use ECS, such as CDNs, never enter the "no-ECS- support" state and so are not protected by forced aggregation; for these zones the limit on simultaneous outstanding queries (Section 3.6) and the suspect handling of unexpected non-ECS responses (Section 3.7) are the operative defenses. Because these zones carry legitimate ECS fan-out, the limit also constrains that fan-out, which is a deliberate security-versus-performance trade-off that operators must weigh. Because the recorded ECS state is changed only by responses that pass the resolver's source-port and Transaction ID checks (Section 3.3), an off-path attacker cannot use a flood of spoofed responses to flip a zone's state. This closes a lightweight denial-of-service vector in which an attacker would otherwise push an ECS-using zone into the "no-ECS-support" state to suppress its ECS-tailored answers. Li & Qiu Expires 30 December 2026 [Page 11] Internet-Draft Strengthening DNS Query Aggregation June 2026 This document does not address all possible DNS cache poisoning vectors. The use of strong entropy for TxID and source port randomization remains essential. Furthermore, the deployment of DNSSEC [RFC4033] provides cryptographic assurance of data integrity and is the most robust defense against cache poisoning attacks. The mechanisms in this document are complementary to, not a replacement for, DNSSEC. Implementers should be careful about the cache lifetime for the "no- ECS-support" state. A value that is too long could prevent a zone that newly adopts ECS from providing optimized responses. A value that is too short might be cleared by an attacker, re-opening a small window for an attack. Tying the lifetime to the zone's NS record TTL is RECOMMENDED as a reasonable balance. 5. Implementation Status [RFC Editor: please remove this section before publication.] The attack addressed in this document has been reported to and acknowledged by multiple resolver vendors, and mitigations have been deployed in widely used implementations, including BIND, Unbound, and PowerDNS. These implementations reissue the affected query without the ECS option, or switch to TCP, when an inconsistent ECS response is detected. The deployed behaviors are not identical across implementations, which is the divergence that the processing model in this document is intended to make interoperable. See [REBIRTHDAY] for the underlying analysis and disclosure. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Li & Qiu Expires 30 December 2026 [Page 12] Internet-Draft Strengthening DNS Query Aggregation June 2026 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, . 7.2. Informative References [REBIRTHDAY] Li, X., Zhang, M., Xu, Z., Miao, F., Qiu, Y., Liu, B., Zhang, J., Zheng, X., Duan, H., Liu, Z., Zhang, Y., and D. Fan, "RebirthDay Attack: Reviving DNS Cache Poisoning with the Birthday Paradox", In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security (CCS '25) , 13 October 2025. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [SACRAMENTO] Sacramento, V., "Vulnerability in Requests Control of BIND Versions 4 and 8 Allows DNS Spoofing", November 2002, . [KAM_ATTACK] Kaminsky, D., "It's the End of the Cache as We Know It", August 2008. [HITCHHIKER] Son, S. and V. Shmatikov, "The Hitchhiker's Guide to DNS Cache Poisoning", In Proceedings of the 6th International ICST Conference on Security and Privacy in Communication Systems (SecureComm '10) , September 2010. Authors' Addresses Li & Qiu Expires 30 December 2026 [Page 13] Internet-Draft Strengthening DNS Query Aggregation June 2026 Xiang Li Nankai University 38 Tongyan Road Tianjin Tianjin, 300355 China Email: lixiang@nankai.edu.cn Yuqi Qiu Nankai University 38 Tongyan Road Tianjin Tianjin, 300355 China Email: qiuyuqi@mail.nankai.edu.cn Li & Qiu Expires 30 December 2026 [Page 14]