One char to rule them all — the DNS silence that revived a dead attack.

Fasheng Miao (Tsinghua University) asked a question nobody had systematically answered in DNS's 40-year history: what actually happens when you put a character in a domain name that isn't a letter, digit, or hyphen? The answer traces to a genuine, decades-old contradiction: RFC 1035 says a domain label may only contain letters, digits, and hyphens; RFC 2181 says implementations must impose no restriction on label content at all. Faced with that contradiction, many real DNS components pick a third, undocumented option: they silently drop the query and send no response at all, rather than either accepting the character or returning a clean error. Miao calls this a silent vulnerability, and built the SHAR (Special Characters) attack around it: force a nameserver into silence with one crafted character, and that silence opens a timing window an off-path attacker can exploit. The impact, measured empirically rather than claimed: all 31 tested mainstream DNS software stacks are vulnerable, all 21 tested Wi-Fi routers and all 6 router OSes, all 43 tested public DNS services, over 531,000 open resolvers, 522 top-level domains, and 12.5 million individual domain names. One of the four attack variants revives brute-force DNS cache-poisoning, a technique considered dead since 2008.

Post 16 of my Black Hat Asia 2026 series. This is disclosed, measurement-driven academic security research; I cover the mechanism and findings in depth, at the level of published papers rather than a working exploit recipe.

1. A 40-year-old contradiction nobody measured

Domain names are built from labels (the parts between dots), and labels are built from characters. Two foundational DNS RFCs disagree, in plain language, about what a valid character even is:

Document	What it says about label characters
RFC 1035 (1987)	A domain label "may only contain letters, digits, and hyphens"
RFC 2181 (1997)	Implementations "must not place any restrictions on label content"

These are not subtly different positions, they are opposites. One says "restrict"; the other says "don't restrict, at all." Every DNS implementation ever written has had to pick a side, or invent its own middle ground, without a single authoritative answer to defer to. Compounding this, DNS is not one program, it's an ecosystem of independently-implemented roles, stub resolvers (on end-user devices), forwarders (routers, local caching proxies), recursive resolvers (ISP and public DNS), and authoritative nameservers (serving the actual zone data), each potentially handling this ambiguity differently. Despite characters being the most fundamental unit of a domain name, no one had systematically measured, across the real DNS ecosystem, what actually happens when an unusual character shows up.

2. Measuring the entire ASCII space, empirically

Miao's team built a methodology to answer this directly rather than by inference: source-code review and GDB debugging for open-source DNS software, empirical black-box testing for closed-source systems, and a controlled measurement setup, send queries of the form {char}.{nonce}.attacker.com to a nameserver they controlled, for every character in the queried label, and capture every DNS packet that resulted (or didn't). They swept the entire ASCII range (0x00–0x7F), treating anything outside a–z, A–Z, 0–9 as a "special character" to be tested.

The result: character support varies significantly and inconsistently across implementations. Some components reject a special character cleanly (a formatted error response). Some accept it and pass it through. And critically, a meaningful subset do neither, they drop the query on the floor and never respond, the "silent vulnerability" that gives the attack its name.

3. The core insight: silence is a timing primitive

Why does silence matter more than an error response? Because DNS cache poisoning is fundamentally a race: an off-path attacker tries to inject a forged, malicious DNS response before the legitimate nameserver's real response arrives back at the querying resolver. The attacker's forged packet must guess a 16-bit transaction ID and, with source-port randomization, a 16-bit source port, together a 32-bit space, and must land within the narrow window (typically 80–100ms) before the real answer shows up. That narrow window is exactly why brute-forcing the 32-bit space was considered practically infeasible since 2008 (the Kaminsky-attack era): you simply don't get enough forged guesses in before the legitimate response closes the window.

SHAR's insight: make the legitimate nameserver never answer at all. If a crafted query containing the right special character causes the authoritative nameserver, or an intermediate resolver, to silently drop it instead of responding, the resolver falls back to its own retry/timeout logic, often several seconds, rather than the usual sub-100ms round trip. That timeout, not the normal response latency, becomes the attacker's real window. A window measured in seconds instead of milliseconds is a fundamentally different brute-force problem.

4. Four attack variants, one root cause

The team turned this single mechanism into four distinct attack variants, targeting different DNS roles:

Variant	Effect	Target role(s)
VEN — Enhance	Strengthens 10 of 13 classic off-path DNS cache-poisoning attacks by forcing the legitimate nameserver silent during the race, giving the attacker's forged packets more time to land	Stub resolver, forwarder, recursive resolver
VBF — Brute-Force	Revives direct 32-bit TxID/port brute-force cache poisoning, thought infeasible since 2008, by widening the spoofing window from ~100ms to several seconds. All 20 test trials succeeded	Stub resolver, forwarder, recursive resolver
VLB — Load-Balancing disruption	Recursive resolvers deprioritize nameservers that don't respond; silencing one nameserver in a pool concentrates all traffic onto the remaining ones, causing overload and reduced resilience	Recursive resolver, nameserver
VSF — Servfail / persistent DoS	Silencing all nameservers for a zone makes the resolver mark every one as faulty, so it returns SERVFAIL directly to clients, domain resolution fully breaks for that zone	Recursive resolver, nameserver

The V_LB/V_SF pairing is a clean illustration of one root cause, an intermediate resolver's own load-balancing logic, producing two distinct severities from the same trigger: silence some nameservers to overload the rest (V_LB), or silence all of them to break resolution entirely (V_SF). Both bypass conventional DoS defenses, because the "attack traffic" is a small number of specially-crafted queries, not a volumetric flood, there's nothing for rate-limiting or traffic-shaping to catch.

5. Real-world scale: this isn't a lab curiosity

What separates SHAR from a typical protocol-ambiguity finding is the scale of empirical validation, this wasn't tested against a handful of toy setups:

Category	Vulnerable
Mainstream DNS software	31 / 31 tested
Wi-Fi routers	21 / 21 tested
Router operating systems	6 / 6 tested
Public DNS services	43 / 43 tested (affected by at least one variant)
Open DNS resolvers (internet-wide scan)	531,100 (60.1% of scanned resolvers)
Top-level domains	522 (36.1% of all TLDs)
Individual domain names	12.5 million (5.6% of the tested set)

The 100% hit rate across every tested software stack, router, router OS, and public DNS service is the number that should concern anyone running DNS infrastructure. This isn't one vendor's bug, it's the predictable outcome of an entire industry independently improvising an answer to a question the RFCs themselves never resolved.

6. What this actually enables

Stitching the variants together, an attacker with the SHAR primitive can achieve, depending on target and variant:

• Domain takeover and full TLD hijacking via revived brute-force or enhanced classic cache poisoning, an attacker who wins the race gets to inject an arbitrary IP address for a victim domain into a resolver's cache, redirecting anyone who queries through that resolver.
• Persistent denial of service against a zone via V_SF, resolvers stop being able to resolve that domain at all until the condition clears.
• Reduced resilience and overload via V_LB, concentrating traffic onto a shrinking pool of "responsive" nameservers, an attacker-induced version of exactly the kind of cascading failure that ordinary infrastructure overload causes.

And because V_EN specifically enhances existing, well-known attacks rather than replacing them, SHAR isn't a niche new technique sitting alongside the old ones, it's a force-multiplier for an entire established attack literature, making previously-marginal cache-poisoning attempts more reliable.

7. Root cause and mitigations

The team is explicit that the root cause is squarely the specification conflict: RFC 1035 and RFC 2181 disagree on allowed characters, and in the absence of a resolved standard, real-world implementations, including major TLD operators, second-level domain operators, and major cloud DNS services, have converged on silently dropping unsupported characters as their de facto (undocumented) answer. That silent-drop behavior is precisely what turns a specification ambiguity into an exploitable timing primitive.

The broader lesson the researchers draw: special character handling is critical to DNS security, and a specification-level inconsistency that has existed since the late 1980s and 1990s was never systematically tested against real-world software at scale until now, despite 40 years of DNS operating as core internet infrastructure.

Is this a new protocol flaw or an implementation bug?

Both, layered. The root cause is a genuine specification-level contradiction (RFC 1035 vs. RFC 2181) that has existed for decades. On top of that, individual implementations chose "silently drop the query" as their undocumented resolution to the ambiguity, which is the specific implementation choice that creates the exploitable timing window. Fixing either layer (a clarified spec, or non-silent error handling) closes the vulnerability.

Does DNSSEC already prevent this?

DNSSEC prevents an attacker from injecting a cryptographically-unsigned forged response into a validating resolver's cache for a signed zone, so it mitigates the cache-poisoning impact (V_EN/V_BF) where deployed and validated end-to-end. It does not address the load-balancing disruption or persistent-DoS variants (V_LB/V_SF), which don't depend on forging a response at all, they only need the ability to make a nameserver go silent.

Why does brute-forcing 32 bits of TxID+port suddenly work again?

The 32-bit space itself hasn't changed; what changed is the time available to try guesses. A normal response arrives in roughly 80-100ms, leaving too small a window for a brute-force attempt to succeed reliably. SHAR extends that window to the resolver's full retry/timeout period (often several seconds) by making the legitimate nameserver silently fail to respond, giving an attacker 10-100x longer to land a forged guess.

What should a DNS operator check first?

Test how your own resolvers and nameservers handle queries containing non-alphanumeric ASCII characters: do they return a clean, immediate error, or do they silently drop the query with no response? Any silent-drop behavior is the precondition for every SHAR variant, and per this research, the majority of real-world software and services currently exhibit it.

Takeaways

• RFC 1035 and RFC 2181 directly contradict each other on which characters a domain label may contain, an unresolved specification conflict since the 1980s/1990s.
• Many real DNS implementations respond to the ambiguity by silently dropping unsupported-character queries instead of erroring cleanly, this is the "silent vulnerability."
• Silence converts a sub-100ms race window into a multi-second timeout window, which is what revives 32-bit TxID/port brute-force cache poisoning, thought dead since 2008.
• Four attack variants (V_EN, V_BF, V_LB, V_SF) span enhanced classic cache poisoning, direct brute-force poisoning, load-balancing disruption, and persistent DoS, from one root cause.
• 100% of tested DNS software, routers, router OSes, and public DNS services were vulnerable, plus 531K+ open resolvers, 522 TLDs, and 12.5M domains at internet scale.
• Fixes require both a clarified specification and non-silent, explicit error handling for invalid characters, alongside standard defenses (0x20 encoding, DNSSEC, anomaly detection, periodic nameserver re-probing).

References & further reading

• Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
• Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
• RFC 1035 — Domain Names, Implementation and Specification · RFC 2181 — Clarifications to the DNS Specification — the two contradictory documents at the root of the vulnerability.
• Fasheng Miao — homepage — the researcher's publications, including prior IEEE S&P/ACM CCS/ACM IMC DNS work.
• RFC 4033 — DNS Security Introduction and Requirements (DNSSEC) — the standard mitigation for cache-poisoning impact.