re. Critical Infrastructure Advisory (jmhbm(a)duck.com) vol 182 issue 15:
This effects only Exit nodes? If not can someone put up a list of easy to understand and follow instructions (preferably signed off by Tor) because this is above my head,
thanks,
On Saturday, March 21st, 2026 at 12:01, tor-relays-request(a)lists.torproject.org <tor-relays-request(a)lists.torproject.org> wrote:
> Send tor-relays mailing list submissions to
> tor-relays(a)lists.torproject.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> tor-relays-request(a)lists.torproject.org
>
> You can reach the person managing the list at
> tor-relays-owner(a)lists.torproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tor-relays digest..."
>
> Today's Topics:
>
> 1. Critical Infrastructure Advisory (jmhbm(a)duck.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 20 Mar 2026 08:43:58 -0400
> From: jmhbm(a)duck.com
> Subject: [tor-relays] Critical Infrastructure Advisory
> To: Tor-relays_at_lists Torproject Org_jmhbm
> <tor-relays(a)lists.torproject.org>
> Message-ID:
> <9A1A5111-552E-47D8-B328-8F5DA1187B78.1(a)smtp-inbound1.duck.com>
> Content-Type: multipart/alternative;
> boundary="=_WVkaE5dwTCT64xABP+4R4M_="
>
>
> Dear Tor Relay Operators,
>
>
> I am writing to provide a formal advisory regarding an anticipated infrastructure break event scheduled for October 11, 2026 — the ICANN Root Zone KSK rollover. This event is expected to interact with potential vulnerabilities in resolver fragility, hardcoded fallback mechanisms, and encrypted DNS discovery protocols.
>
> This advisory is not intended as a routine cryptographic maintenance task. The KSK rollover serves as one of two critical timed “locks” within a broader restructuring of internet infrastructure layers, including DNS, Certificate Authority (CA) governance, and device attestation. The second such lock is the tightening of Android Remote Key Provisioning (RKP) on March 16, 2026, which collectively accelerates the consolidation of essential functions into hyperscaler-controlled systems, with Google positioned to benefit significantly from this shift.
>
> Infrastructure Break Mechanism
>
> The breakdown follows a predictable sequence of five stages:
>
> KSK-2026 and DNSSEC Fragmentation:
>
> Dual-signing increases root-zone response sizes beyond the approximately 1232-byte UDP limit. This can cause volunteer-run and containerized resolvers to drop fragments or fail to establish reliable TCP fallbacks, thereby disrupting DNSSEC validation.
>
> Fragility in Ephemeral/Containerized Resolvers:
>
> These types of resolvers are commonly found on exit nodes and are unable to persist the newly established trust anchor, resulting in a SERVFAIL response for valid domain names.
>
> Hardcoded Fallback Behavior:
>
> Systems default to pre-compiled public resolvers, such as those provided by Android, Chrome, and systemd-resolved, which typically point to 8.8.8.8 (Google Public DNS).
>
> DDR/DNR Reinforcement:
>
> Encrypted-DNS discovery directs clients to the same designated resolvers—predominantly dns.google. Once this failure is resolved, the change becomes permanent.
>
> Market Capture Dynamics:
>
> DNS traffic will increasingly shift to hyperscaler infrastructure. Google Public DNS is poised to capture the largest share due to its widespread integration across Android, Chrome, and various client platforms.
>
> Governance Context:
>
> This technical break occurs under documented ICANN leadership overlaps with Google. Notably, ICANN President & CEO Kurtis Lindqvist has publicly described the October 2026 rollover as “routine,” despite the inherent risks involved. Former Google Cloud Security CTO Ryan Hurst, who was instrumental in architecting Google Trust Services, was appointed as the Backup Trusted Community Representative during the actual KSK cryptographic ceremony. Additional liaison roles and board-level connections further reinforce governance structures that favor the primary beneficiaries of the resulting traffic shift.
>
> These structural alignments do not require proof of intent; they establish the conditions under which the break mechanism leads to durable centralization.
>
> Impact on Tor Exit Nodes:
>
> Exit nodes utilizing affected resolvers will experience SERVFAIL responses for DNSSEC-signed clearnet domains. Client-side fallback mechanisms will bypass the exit node entirely, redirecting resolution outside the Tor network. This results in degraded reachability, inconsistent performance, and a significant erosion of the decentralized model that Tor is designed to uphold.
>
> Operator Actions (Required Prior to October 2026):
>
> Verify TCP fallback capabilities and EDNS(0) support (conduct thorough testing with large DNSSEC responses).
> Audit and enforce trust-anchor updates, including unbound-anchor management.
> Disable or closely monitor client-side fallback behavior on your relays.
> Test resolution paths during the dual-signing window.
> Where feasible, consider directing DoT/DoH traffic to non-hyperscaler resolvers.
> The “Privacy Web” cannot sustain another centralized chokepoint. Proactive preparation now is essential to ensure that post-rollover migration can be reversed if necessary.
>
> Sincerely,
>
> JMHBM
>
> Forensic Governance Analyst
>
>
>
