Yuqi Qiu and Xiang Li (Nankai University) revived an attack everyone thought was dead. The DNS Birthday Attack, a classic cache-poisoning technique, was effectively neutralised in 2002 by a defence called query aggregation. Their finding, REBIRTHDAY: a widely deployed DNS feature called EDNS Client Subnet (ECS), meant to make responses geographically smarter, quietly reopens the exact aggregation gap that was closed 20+ years ago. Of 22 major DNS software packages tested, 18 were vulnerable. Against three of them the attack succeeded in every one of 20 trials, averaging under six minutes. An internet-wide scan estimated at least 365,000 open resolvers (15% of those scanned) are exploitable. 35 CVEs were assigned; several vendors have patched.
Post 28 of my Black Hat Asia 2026 series. This pairs naturally with the SHAR DNS silent-vulnerability talk earlier in this series, another case of a 2008-era "dead" cache-poisoning class coming back through an unrelated protocol quirk. All findings are disclosed; I explain the mechanism and impact, not exact attack parameters.
1. DNS cache poisoning, briefly
DNS resolvers cache answers so they don't have to ask an authoritative server every time. Cache poisoning means tricking a resolver into caching a forged answer, so every subsequent user of that resolver gets redirected to wherever the attacker wants. Classic DNS runs over UDP with no built-in authentication, so the only things stopping a forged response from being accepted are two largely random values: the 16-bit transaction ID (TXID) and the source UDP port. An attacker who can guess both, and race a legitimate response, wins.
A brute-force guess against one query has long odds (roughly 1 in 65,536 for the TXID alone, more with port randomisation). The Birthday Attack, described in 2002, changes the odds dramatically by exploiting the same statistical effect that makes the "birthday paradox" surprising: the probability of a collision in a set grows much faster than intuition suggests as the set gets larger.
2. The classic Birthday Attack and how it was stopped
Instead of guessing once, the attacker triggers the resolver to send many simultaneous queries for the same domain. Each of those in-flight queries has its own valid TXID that a forged response could match. Now the attacker isn't trying to guess one specific value, they only need any one of their forged responses to collide with any one of the many outstanding queries. As the number of simultaneous queries (Q) grows, the probability of at least one collision rises much faster than linearly, exactly the birthday-paradox effect.
The fix that closed this off in 2002 is called query aggregation: if a resolver is already waiting on an answer for a given domain, it should merge any new, identical request into that same pending query rather than sending a fresh one. "Identical" was defined as sharing the same <query name, query type> pair. With aggregation in place, an attacker cannot inflate the number of outstanding queries no matter how many times they ask; the resolver just reuses the one query already in flight. This defence, alongside better randomisation, was considered a settled matter for two decades.
3. The feature that reopened the door: ECS
EDNS(0) (RFC 6891) is an extension mechanism that lets DNS messages carry extra options beyond the original message format. One popular option built on it is EDNS Client Subnet (RFC 7871): a resolver includes a portion of the requesting client's IP address (their subnet) in the query it forwards upstream, so a CDN's authoritative server can hand back an answer optimised for that client's location. This is genuinely useful, and it's why many resolvers, routers and public DNS services support it.
ECS also changes caching. A response generated for one subnet may not be valid for a client in a different subnet, so ECS-aware resolvers cache responses per subnet rather than per domain alone. That's the correct behaviour for the feature's purpose. But it has a side effect nobody connected back to the 2002 defence: for resolvers that use ECS, the identifier for "is this query identical to one I already have outstanding" quietly becomes a 3-tuple: <domain, type, subnet> instead of the original 2-tuple.
Fig. 1 — Widening the aggregation key from two fields to three reopens the exact gap it closed.
An off-path attacker who spoofs a different (fake) client subnet on each of hundreds of forged queries for the same domain makes every single one look like a distinct, non-duplicate query to an ECS-aware resolver's aggregation logic. Aggregation never triggers, and the resolver happily issues hundreds of simultaneous outstanding queries again, exactly the environment the Birthday Attack needs.
A second, compounding weakness
RFC 7871 also specifies that a response without an ECS option is still considered a valid answer to a query that included one. That means a forged response doesn't need to include (or correctly guess) any ECS-related fields at all, it only needs to match the plain <domain, type> of the pending query. This substantially lowers the complexity of building a working forged packet, on top of already having many more targets to hit.
4. Attack shape
The attacker is assumed to be an ordinary off-path client: they can trigger domain lookups (for example by getting a victim to visit a page, or via any service that causes DNS lookups on their behalf), can learn the target resolver's outbound IP, and can spoof source IP addresses on packets they send. IP spoofing being feasible at all depends on network operators not filtering forged source addresses; the researchers note this remains possible on over 19% of IPv4 autonomous systems, which is a meaningful chunk of the internet's routing infrastructure.
At a high level, two things happen: the attacker triggers many simultaneous queries for one domain, each disguised as coming from a different client subnet, and separately races forged responses that only need to match the query's domain, type and (within a still-limited space) transaction ID and port. Neither step requires anything exotic; the entire trick is that a legitimate feature invalidates a defence that everyone assumed still held.
5. How bad is it, measured
| Test | Result |
|---|---|
| Software surveyed | 22 DNS packages (9 recursive resolvers, 13 forwarders); 18 vulnerable |
| ECS-bypass class | 6 packages, including BIND, Unbound, PowerDNS, Technitium, Dnsmasq, Pi-hole — missing ECS-coherence checks |
| No aggregation at all | 11 packages, including HickoryDNS, CoreDNS, DNSDist, AdGuard, YogaDNS |
| Additional weak randomisation | SmartDNS, DNSDist, Acrylic DNS: predictable ports or TXIDs compound the risk |
| End-to-end poisoning | 100% success (20/20 trials) against Unbound, PowerDNS Recursor and CoreDNS; average time to success 358 seconds (roughly 6 minutes) |
| Wi-Fi routers | 16 of 21 tested vulnerable (ASUS, Cisco, D-Link, Linksys, TP-Link, ZTE and others); 12 lack aggregation entirely |
| Public DNS services | 14 of 45 vulnerable (8 via ECS bypass, 3 via poor aggregation) |
| Internet-wide open-resolver scan | 2.4M open resolvers scanned (232 regions, 25,711 ASes); at least 365,000 (15%) estimated vulnerable to REBIRTHDAY |
Two scan findings are worth flagging separately: about 14.1% of scanned resolvers forward ECS queries upstream (the population directly exposed to the bypass class), and over 80% showed no significant query aggregation at all regardless of ECS, meaning a large share of the open-resolver population never benefited from the 2002 fix in the first place.
6. Mitigation
- Verify ECS consistency: reject a response that omits the ECS option if it came from a server known to be ECS-aware, closing the "valid response without ECS" loophole.
- Aggregate within the same ECS scope, restoring the intent of the original 2002 defence instead of accidentally widening its key.
- Enable 0x20 encoding (randomising letter case in the query name) as an additional, independent layer of response validation.
- Deploy DNSSEC where possible, since cryptographically signed responses make blind spoofing irrelevant regardless of aggregation behaviour.
- Add anomaly detection and rate limiting for abnormal volumes of simultaneous queries for one domain, a defence-in-depth backstop independent of any single protocol fix.
7. Disclosure
35 CVEs were assigned across the affected vendors and public DNS providers. Seven vendors acknowledged the findings, including Unbound, PowerDNS, Technitium, Dnsmasq, YogaDNS, Quad9 and AdGuard. Unbound has already shipped a patched version based on the researchers' suggested fix; discussions with remaining vendors were ongoing at publication time. The underlying research appears in the ACM CCS proceedings.
8. The recurring lesson
This is the same structural story as several other talks in this series: a security property that was carefully proven and defended decades ago quietly stops holding once an unrelated, well-intentioned feature changes what "the same request" means. Query aggregation was correct as specified; ECS was correct as specified; the two together silently broke an invariant neither specification's authors were thinking about when they wrote it. Anywhere a system defines identity or uniqueness ("is this the same request/session/object as one I've already seen") for one purpose, a later feature that changes the definition for a different purpose is worth re-checking against every defence that quietly depended on the old definition.
Is this the same bug as SHAR (talk 16 in this series)?
No, though both revive "dead" cache-poisoning techniques through unrelated protocol side effects. SHAR exploits a character-set contradiction between two DNS-related RFCs that causes resolvers to silently drop certain queries, widening the poisoning race window. REBIRTHDAY exploits ECS's effect on query aggregation to recreate the classic 2002 Birthday Attack's precondition of many simultaneous outstanding queries.
Do I need ECS enabled to be at risk?
The ECS-bypass class specifically needs an ECS-aware resolver. But the scan found the majority of vulnerable open resolvers lack meaningful query aggregation at all, independent of ECS, so plenty of exposure exists without ECS in the picture.
Does DNSSEC fully solve this?
Where deployed and validated end to end, yes, a cryptographically signed response can't be meaningfully forged regardless of TXID or port guessing. DNSSEC deployment and validation are not universal, which is why the other mitigations matter too.
Why does IP spoofing still work in 2026?
Source-address validation (BCP38-style filtering) is not universally deployed. The researchers found spoofing still feasible on over 19% of IPv4 autonomous systems, enough for this and other spoofing-dependent attacks to remain viable at internet scale.
Takeaways
- The 2002 Birthday Attack defence (query aggregation) is quietly bypassed by EDNS Client Subnet (ECS), which widens the aggregation key to include the client subnet.
- A second RFC 7871 rule, that ECS-less responses are still valid, further lowers the forgery bar.
- 18 of 22 tested DNS software packages were vulnerable; three were poisoned in 100% of trials, averaging under 6 minutes.
- At internet scale: 16 of 21 routers, 14 of 45 public DNS services, and an estimated 365,000+ open resolvers (15%) are exploitable.
- Fix: verify ECS consistency, aggregate within ECS scope, add 0x20 encoding, deploy DNSSEC, and rate-limit anomalous query volume. 35 CVEs assigned; patches are rolling out.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Official talk recording on YouTube — Black Hat channel.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- The REBIRTHDAY research paper (ACM CCS) — full methodology and results.
- RFC 7871: EDNS Client Subnet — the extension at the centre of the bypass.
- RFC 6891: EDNS(0) — the base extension mechanism ECS builds on.
- SHAR: DNS Silent Vulnerabilities — another revived cache-poisoning class, earlier in this series.