Strengthening DNS Query Aggregation against ECS-based Attacks
draft-li-dnsop-ecs-aggregation-fix-02

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
   <qname, qtype> to <qname, qtype, subnet>.  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
       <qname, qtype> 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 <qname,
       qtype>.

   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 <qname, qtype>, 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 <qname, qtype>.  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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://www.rfc-editor.org/info/rfc7871>.

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,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [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,
              <https://www.rfc-editor.org/info/rfc4033>.

   [SACRAMENTO]
              Sacramento, V., "Vulnerability in Requests Control of BIND
              Versions 4 and 8 Allows DNS Spoofing", November 2002,
              <https://lists.isc.org/pipermail/bind-
              users/2002-November/043141.html>.

   [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]