Cloudflare/dns

12 posts

cloudflare

Cloudflare DDoS Threat Report H1 2026: 1 Tbps attacks soar as DNS floods and geopolitical tensions drive a new wave (opens in new tab)

Cloudflare’s H1 2026 DDoS report shows a sharp rise in extreme attacks alongside a shift toward reflection and amplification techniques. Although most attacks remained brief and relatively small, 935 network-layer attacks exceeded 1 Tbps, making automated, always-on protection essential. Geopolitical events also strongly influenced which industries and countries were targeted. ## DDoS Activity Reached Record Levels - Cloudflare mitigated: - 23.2 million network-layer DDoS attacks - 29.64 trillion HTTP DDoS requests - This equals roughly 5,343 network-layer attacks per hour, or 128,000 per day. - April was the peak month, with 6.46 trillion requests and 165 petabytes of traffic. - Activity declined afterward, possibly following Operation PowerOFF, which targeted: - More than 75,000 DDoS-for-hire users - 53 domains - 25 search warrants - Four arrests across 21 countries ## Hyper-Volumetric Attacks Surge - Cloudflare mitigated 935 network-layer attacks exceeding 1 Tbps during H1. - Q2 alone accounted for 805 such attacks, more than six times Q1’s total. - Hyper-volumetric attacks are defined as exceeding: - 1 Tbps - 1 billion packets per second - 1 million requests per second ## Most Attacks Remained Short and Small - Despite record-breaking incidents: - 96.62% of network-layer attacks stayed below 500 Mbps. - 90.60% lasted less than 10 minutes. - Even “small” attacks can be damaging: - 100 Mbps can overwhelm an individual server or website. - 100 Gbps can disable most unprotected data centers. - Attacks above 1 Tbps can stress major infrastructure. - Attackers may combine high packet rates with lower bandwidth, or the reverse, to target different network weaknesses. - Some extreme attacks lasted only 35 seconds, leaving no realistic opportunity for manual intervention. - Short attacks can still cause prolonged routing instability, retransmissions, timeouts, and downstream outages. ## Media and Government Organizations Were Major Targets - Media, Production & Publishing was the most targeted industry in both quarters. - It represented 14.2% of mitigated HTTP DDoS requests. - Coverage of conflicts in Iran and Ukraine, along with the World Cup, contributed to sustained targeting. - Following Operation Epic Fury against Iran, government organizations experienced a major spike: - Researchers recorded 149 hacktivist DDoS claims against 110 organizations in 16 countries. - Nearly 47.8% of targeted organizations were in the government sector. - Government moved from 29th place in Q1 to 9th in Q2. ## China and Turkey Rose Among Targeted Locations - China was the most attacked location in Q2, receiving 22.4% of global HTTP DDoS requests. - The United States ranked second with 18.8%. - Turkey more than doubled its share of attack traffic and reached third place. - The increase coincided with security activity surrounding the 2026 Ankara NATO Summit. ## Brazil Became the Leading Attack Source - Brazil overtook the United States as the leading source country: - Brazil: 14.9% during H1, rising to 21.4% in Q2 - United States: 13.4% - Indonesia remained the third-largest source country. ## DNS and CLDAP Attacks Gained Ground - DNS-based attacks accounted for 34.3% of network-layer activity. - DNS Floods rose from 25.7% to 40.0% of network-layer attacks between Q1 and Q2. - DNS Floods directly overwhelm authoritative DNS servers with query volume. - DNS Amplification abuses open resolvers and spoofed source addresses to send larger responses to victims. - CLDAP Floods increased 580% quarter-over-quarter and became the third-most common vector in Q2. - These attacks exploit exposed LDAP-over-UDP endpoints, particularly those associated with Active Directory. - Overall, the attack landscape shifted from conventional botnet floods toward reflection and amplification methods. Cloudflare’s findings reinforce that DDoS defenses must be automated, distributed, and continuously active. Short attack durations and rapidly increasing traffic volumes make manual or on-demand mitigation too slow to protect services reliably.

cloudflare

How the 2026 World Cup affected Internet traffic (opens in new tab)

The 2026 World Cup demonstrated how a rare shared global event can reshape Internet behavior across countries. Cloudflare used traffic data from its global network to show that match timing, teams, and major storylines significantly affected online activity. Overnight matches often doubled traffic, while games during normal active hours could reduce browsing as people focused on watching. ## Measuring “Normal” Internet Activity - Cloudflare established a baseline using the median traffic from the previous four weeks. - Traffic changes were expressed as a log₂ ratio: - `0` means normal activity. - `+1` means traffic doubled. - `−1` means traffic fell to half its normal level. - This approach made traffic changes comparable between high-volume and low-volume countries. ## Kickoff Time Shaped Online Behavior - The largest traffic changes occurred during matches played between midnight and 8 a.m. local time. - Fans staying awake or waking early caused traffic to rise well above normal, sometimes by more than 2x. - Daytime matches had little effect because viewers were likely already online. - Evening matches produced a smaller increase on weekdays, but could also cause traffic to fall when people stopped browsing to watch. - In Bosnia and Herzegovina: - A 2 a.m. match caused traffic to more than double. - An evening match reduced traffic to roughly 70% of normal. - Brazil and Japan showed opposite patterns during the same match: - Japan’s overnight viewing produced traffic around twice its usual level. - Brazil’s daytime match coincided with traffic about 40% below normal. ## Matches With the Greatest Global Impact - Cloudflare measured traffic during the two hours after kickoff. - For each match, it calculated the absolute deviation from normal across countries and then used the median result. - Simultaneous matches were excluded because their effects could not be reliably separated. - The most impactful match was Argentina vs. Switzerland, with traffic changing by a factor of about 1.26. - France vs. Spain followed at 1.21. - The highest-impact games included quarterfinals, knockout matches, and some round-of-32 games—not only the final or semifinals. ## Argentina Led the Teams Drawing Global Attention - Argentina produced the largest average worldwide traffic impact, at 1.17x normal activity. - France, Brazil, Portugal, Morocco, Spain, and Norway also ranked highly. - Argentina’s appeal was linked to its status as defending champion and the possibility that the tournament could be Lionel Messi’s final World Cup. - Haiti and Iraq appeared as outliers because matches involving major teams caused especially large changes relative to their usual traffic levels. ## More Traffic to Sports Betting Websites - Requests to gambling-related websites increased after the tournament began compared with the preceding month. - Before the World Cup, betting traffic followed a regular weekly cycle. - Once matches began nearly every day, that weekly pattern flattened into a more consistent level of activity. Overall, the data shows that the World Cup affected Internet use in two distinct ways: inconvenient kickoff times brought previously offline fans online, while matches during normal usage hours often diverted people away from their usual browsing. For analyzing global events, normalized, country-by-country traffic measurements provide a clearer picture than raw request volumes alone.

cloudflare

Cloudflare Internal DNS is now generally available (opens in new tab)

Cloudflare Internal DNS is now generally available as a unified platform for public and private DNS. It combines recursive resolution, authoritative private zones, DNS policy enforcement, and Zero Trust controls on Cloudflare’s global network. The goal is to eliminate fragmented DNS systems and simplify split-horizon management without duplicated configurations or synchronization drift. ## Problems with Traditional Internal DNS - Organizations often manage public DNS, internal DNS, and cloud-provider DNS separately. - Separate control planes create inconsistent policies, limited visibility, and operational overhead. - Split-horizon DNS typically requires parallel environments that can drift and cause outages. - Legacy appliances introduce hardware refresh cycles and scaling constraints. ## Unified DNS and Zero Trust - Public and private DNS share one platform, API, audit trail, and policy layer. - Internal DNS is included for Enterprise customers using Cloudflare Gateway. - Gateway policies determine which users and devices can resolve specific DNS views. - Private name resolution becomes part of the broader Zero Trust architecture. ## Internal DNS Architecture Cloudflare Internal DNS has two main components: - **Gateway Resolver** - Performs recursive resolution and evaluates DNS policies. - Can filter queries or redirect them to different upstream sources. - Provides centralized logging, auditing, and policy management. - **Internal Authoritative DNS** - Serves records for private zones using Cloudflare’s authoritative DNS infrastructure. - Stores resources such as internal applications, databases, and service endpoints. The main configuration objects are: - **Internal Zones:** Authoritative records for private resources. - **DNS Views:** Resolution contexts containing one or more zones. - **Resolver Policies:** Gateway rules that route matching queries to a specific view. - **Zone references:** Allow one shared zone to be reused across multiple views without duplicating records. ## Query Resolution and Change Propagation - Queries first reach the Gateway Resolver for policy evaluation. - Matching policies route queries to an internal DNS view. - Blocked queries are dropped. - Unmatched queries use public resolution through 1.1.1.1. - Views can fall back to public DNS when a name is not found internally. - Changes from the dashboard, API, or Terraform use the same DNS Records API. - Records are validated, persisted, replicated globally, and propagated within seconds as caches are invalidated. ## Getting Started - Enterprise customers using Gateway can access Internal DNS from **Networking → Internal DNS**. - Initial setup generally requires: - Creating an internal zone and records. - Creating a DNS view and associating the zone. - Creating a Gateway resolver policy that routes users or devices to the view. - Terraform is supported and follows the same API ingestion and propagation path. ## Connectivity Cloud Integration - Internal DNS works with Cloudflare One Client, DoH, DoT, standard DNS, PAC files, and Cloudflare WAN. - Cloudflare WAN enables devices across branches, data centers, cloud environments, and remote networks to resolve internal names without installing the client on every device. - The service extends Cloudflare’s existing Connectivity Cloud rather than operating as an isolated DNS product. Cloudflare’s recommendation is to consolidate public DNS, private DNS, and DNS security policies on one control plane, particularly for organizations already using Cloudflare Gateway or WAN.

cloudflare

A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed (opens in new tab)

A failed DNSSEC key rollover at Albania’s `.AL` registry caused validating resolvers to return errors for every `.AL` domain. Cloudflare temporarily installed a Negative Trust Anchor (NTA) to restore access, suspending DNSSEC validation while the registry fixed the issue. To make this bypass visible, 1.1.1.1 began returning a new Extended DNS Error (EDE) code alongside affected responses. ## What Happened to `.AL` - Around 14:15 UTC on July 3, the registry published a new DNSKEY and stopped serving the old key. - The root zone’s DS record still referenced the old key (`id=26319`), breaking the DNSSEC chain of trust. - Around 17:00 UTC, the new DNSKEY was also removed, leaving `.AL` with no DNSKEY records. - At approximately 19:15 UTC, the DS record was removed from the root zone, restoring normal resolution but leaving the entire TLD unsigned. - The outage affected government services, banks, media, and any other `.AL` domain accessed through DNSSEC-validating resolvers. ## Why Negative Trust Anchors Were Used - An NTA, defined by RFC 7646, tells recursive resolvers to treat a zone as unsigned and skip DNSSEC validation. - Cloudflare applied an NTA to `.AL` at 17:15 UTC, restoring resolution for 1.1.1.1 users. - The measure was considered acceptable because the failure was public, confirmed, and affected validating resolvers broadly. - Communication with the registry was difficult because its contact addresses were themselves hosted under `.AL`. - The NTA was removed the following day after the DS record had been removed from the root zone. ## The Security Tradeoff - NTAs prevent widespread `SERVFAIL` responses but remove cryptographic protection against DNS spoofing. - Previously, clients could not distinguish an NTA-served response from a fully DNSSEC-validated response. - Public status pages provide disclosure, but applications, monitoring systems, and users cannot reliably discover the bypass from DNS responses alone. ## EDE-Based Transparency - Extended DNS Errors, defined in RFC 8914, let resolvers attach explanatory information to DNS responses. - Cloudflare implemented a proposed EDE code, “Negative Trust Anchor,” developed with Quad9 contributors. - During the incident, `.AL` responses included: - EDE 9: `DNSKEY Missing`, explaining the broken DNSSEC chain. - EDE 33: `Negative Trust Anchor`, explicitly stating that validation had been bypassed. - A query such as `google.al` could therefore return a successful answer while clearly indicating that it was not DNSSEC-validated. Resolvers and applications should use EDE information where possible, while DNS operators should disclose NTAs and remove them promptly once the underlying DNSSEC problem is resolved.

cloudflare

Cloudflare DMARC Management is now generally available (opens in new tab)

Cloudflare DMARC Management is now generally available as a free service for Cloudflare customers. Its redesigned dashboard helps organizations understand email authentication, investigate sending sources, and safely move from monitoring to full DMARC enforcement. The goal is to reduce spoofing and improve deliverability without requiring consultants or manual XML report analysis. ## Why Email Authentication Matters - **SPF** identifies the servers and services authorized to send mail for a domain. - **DKIM** adds a cryptographic signature so recipients can verify message integrity. - **DMARC** combines SPF and DKIM results and determines whether failed messages should be delivered, quarantined, or rejected. - **BIMI** can display a brand logo in supported inboxes when a domain has a sufficiently strong DMARC policy. - Correctly configured records help block spoofed messages and improve legitimate email delivery. ## DMARC Has Become Essential - Google, Microsoft, and Yahoo have introduced stricter authentication requirements. - Domains with missing or incorrect SPF, DKIM, or DMARC records increasingly face spam placement or outright rejection. - Poor email authentication can lead to brand impersonation, missed communications, and lost revenue. ## The Risks of Reaching Enforcement - DMARC policies typically progress from: - `p=none`: monitor activity without blocking messages - `p=quarantine`: send suspicious messages to spam - `p=reject`: block unauthenticated messages - Tightening the policy too quickly can disrupt legitimate mail from forgotten third-party services. - Moving too slowly leaves the domain vulnerable to spoofing and deliverability problems. - Organizations must analyze aggregate XML reports and identify every legitimate sending source before enforcing stricter policies. ## Deeper Report Visibility and Source Investigation - Reports now show: - Source IP addresses - Sending service names - DMARC, SPF, and DKIM alignment results - Users can open an IP address in Cloudflare’s Investigate tab to view: - Reputation data - Geolocation - ASN information - Known malicious associations - This turns DMARC reports into an investigation tool for distinguishing legitimate infrastructure from unauthorized senders. ## Unified Authentication Record Status - A single view reports the status of DMARC, DKIM, SPF, and BIMI records. - Each record receives a pass, warning, or fail result based on automated analysis. - The dashboard identifies issues such as: - Multiple SPF records - SPF lookup-limit problems - Permissive `+all` settings - Missing SPF mechanisms - Malformed DKIM keys - Missing BIMI records when the domain qualifies for one - Recommendations are presented in plain language with actionable remediation steps. Cloudflare’s recommendation is effectively to use DMARC Management to identify all sending sources, correct authentication records, and gradually move toward `p=reject` with greater confidence and less risk of interrupting legitimate email.

cloudflare

Iran's Internet is partially restored, Cloudflare Radar data shows (opens in new tab)

Cloudflare Radar data indicates that Iran’s Internet access began a partial restoration on May 26, after nearly three months of near-total shutdown following the February 28 military strikes. Traffic and DNS activity increased significantly, but remained far below normal levels, and the recovery could still be temporary. IPv6 connectivity remains effectively absent. ## Iran’s Two Internet Shutdowns - The first nationwide shutdown began on January 8, with traffic falling nearly to zero. - Limited connectivity briefly returned on January 21 and January 25 before recovering more substantially on January 27. - A second shutdown began on February 28 as military strikes escalated. - Traffic dropped to less than 1% of previous levels and stayed there for nearly three months. ## Signs of Partial Restoration - Around 11:00 UTC on May 26, Cloudflare observed sharp increases in traffic and DNS queries. - Transferred data briefly spiked at 11:45 UTC and then rose steadily from 12:00 UTC. - Traffic reached roughly 15 times the levels recorded during the previous week. - Activity followed expected daily patterns, declining around 21:00 UTC before rising again the following morning. - Increased DNS queries suggested that more users were successfully attempting to access websites and online services. ## Tehran and Major Providers Lead the Recovery - Tehran accounted for 91.6% of HTTP requests during the increase. - Other regions experienced only modest gains. - Traffic increased across several major providers, including: - TCI - IranCell - RighTel - MCCI ## Connectivity Remains Well Below Normal - Peak traffic on May 26 reached only about 40% of the maximum activity recorded in 2026 before the disruptions. - Future measurements will determine whether connectivity returns to pre-shutdown levels. - The January shutdown demonstrated that temporary restorations can quickly disappear. ## IPv6 Is Still Unavailable - Announced IPv6 address space from Iran remains effectively at zero. - IPv4 announcements have stayed relatively stable throughout both shutdowns. - This contrast suggests the disruptions were likely implemented through mechanisms such as application filtering or whitelisting rather than by withdrawing IPv4 routes from global networks. The data supports cautious optimism: Iranian users are regaining some Internet access, particularly in Tehran and through major providers, but service remains incomplete and potentially unstable. Continued monitoring is necessary to determine whether this is a lasting restoration.

cloudflare

When DNSSEC goes wrong: how we responded to the .de TLD outage (opens in new tab)

On May 5, 2026, DENIC published invalid DNSSEC signatures for the `.de` zone, causing validating resolvers to return `SERVFAIL` for affected domains. Cloudflare’s 1.1.1.1 mitigated much of the impact by serving expired cached records and temporarily bypassing DNSSEC validation for `.de`. The incident demonstrates both the value of DNSSEC and the operational risks of a failure at a top-level domain. ## How DNSSEC Protects DNS - DNSSEC adds cryptographic authentication to DNS records through `RRSIG` signatures. - It protects integrity and authenticity, but does not encrypt DNS traffic. - DNSSEC creates a chain of trust from the root zone to child domains: - The root delegates trust to `.de`. - `.de` delegates trust to domains such as `example.de`. - A failure anywhere in the chain causes validation to fail below that point. - Zones generally use: - A Zone Signing Key (ZSK) for signing records. - A Key Signing Key (KSK) for signing the ZSK. - Errors during key rotation can produce signatures that resolvers cannot validate, forcing them to return `SERVFAIL`. ## Impact of the `.de` Outage - Around 19:30 UTC, DENIC began publishing invalid DNSSEC signatures for `.de`. - Any DNSSEC-validating resolver, including Cloudflare’s 1.1.1.1, had to reject the responses. - The failure spread across domains under `.de`, potentially affecting millions of German websites and services. - `SERVFAIL` responses increased gradually as cached records expired and resolvers requested fresh, invalidly signed data. - Query volume also rose because clients commonly retry failed DNS queries multiple times. ## How “Serve Stale” Reduced the Damage - Recursive resolvers normally serve cached records only until their TTL expires. - Cloudflare’s 1.1.1.1 implements RFC 8767, allowing it to serve expired records when authoritative resolution fails. - Cached `.de` records from before the incident continued resolving successfully after their TTLs expired. - This kept the overall `NOERROR` rate relatively stable, even though fresh lookups increasingly failed. - Without stale serving, successful responses would have declined steadily from the start of the outage. ## Temporarily Bypassing DNSSEC with an NTA - RFC 7646 defines Negative Trust Anchors (NTAs), which allow resolvers to treat a broken signed zone as temporarily unsigned. - NTAs are intended for situations such as a TLD operator publishing invalid signatures. - Bypassing validation can restore availability because the failure originates in the parent zone, not necessarily in individual domains. - The tradeoff is reduced security: while the exception is active, `.de` domains are exposed to DNS spoofing or other attacks that DNSSEC would normally prevent. ## Cloudflare’s Mitigation - Cloudflare’s Big Pineapple resolver did not yet have a native NTA implementation. - Instead, Cloudflare used an existing override mechanism to mark `.de` as an insecure zone. - This caused `.de` queries to be resolved without DNSSEC validation, functionally providing the same result as an NTA. - Combined with stale serving, this reduced the outage’s effect while DENIC worked to correct the zone. Cloudflare’s response illustrates a practical incident strategy: preserve cached answers where possible, then use a narrowly scoped DNSSEC exception when a parent zone is demonstrably broken. Such overrides should be temporary and carefully monitored because they restore availability at the cost of DNSSEC protection.

cloudflare

Our ongoing commitment to privacy for the 1.1.1.1 public DNS resolver (opens in new tab)

Cloudflare reports that an independent Big Four accounting firm has confirmed its 1.1.1.1 public DNS resolver continues to meet its privacy commitments. The review was conducted because Cloudflare’s DNS infrastructure has expanded and become more complex since the previous examination in 2020. Cloudflare says it aims to make privacy the default and encourages other public DNS providers to undergo similar independent reviews. ## Renewed Independent Privacy Examination - Cloudflare launched 1.1.1.1 in 2018 as a fast, privacy-focused DNS resolver. - A first independent review took place in 2020. - After major changes to its technology stack and DNS platform, Cloudflare commissioned the same accounting firm to conduct another examination. - The latest review examined evidence collected after the 2024 calendar year and took several months to complete. - The resulting report is available through Cloudflare’s compliance resources. ## Confirmed Privacy Commitments The examination confirmed that: - Cloudflare does not sell or share public resolver users’ personal data with third parties. - Resolver data is not used to target users with advertisements. - Cloudflare retains or uses the requested DNS information, rather than information identifying the person making the request. - Source IP addresses are anonymized and deleted within 25 hours. - DNS query information is not combined with other Cloudflare or third-party data in a way that could identify individual users. ## Limited Network Troubleshooting Data - Cloudflare may use randomly sampled network packets for troubleshooting and attack mitigation. - These samples represent no more than 0.05% of total traffic. - The samples can include the querying IP address, but are used solely for operational security and network reliability purposes. ## Scope of the Latest Review - Unlike the broader 2020 examination, the latest review focused exclusively on privacy commitments. - The earlier review also covered how Cloudflare handled anonymized transaction and debug logs, known as “Public Resolver Logs.” - Cloudflare says the use of those logs has evolved, including supporting services such as Cloudflare Radar. - The company maintains that these changes do not affect personal information or user privacy. Cloudflare’s practical position is that 1.1.1.1 users should not have to trust privacy promises alone: independent examinations should verify them. It recommends reviewing the published accountant’s report and continues to present 1.1.1.1 as a privacy-first DNS option.

cloudflare

Cloudflare outage on February 20, 2026 (opens in new tab)

Cloudflare suffered a 6-hour, 7-minute outage on February 20, 2026, after a software change unintentionally withdrew Internet routes for some Bring Your Own IP (BYOIP) customers. The incident was not related to a cyberattack; a buggy automated cleanup task altered customer prefix and service configurations. Cloudflare reverted the change, restored affected prefixes, and is revising its Addressing API workflows to reduce production risk. ## Customer Impact - Approximately 1,100 of Cloudflare’s 6,500 advertised prefixes were withdrawn between 17:56 and 18:46 UTC. - This affected about 25% of the 4,306 BYOIP prefixes advertised globally. - Impacted applications became unreachable from the Internet and experienced connection failures and timeouts. - Customers initially encountered BGP Path Hunting, where networks repeatedly searched for a route until connections timed out. - The `one.one.one.one` website returned HTTP 403 errors and an “Edge IP Restricted” message. - DNS resolution through the 1.1.1.1 resolver, including DNS over HTTPS, was not affected. - The incident did not affect every BYOIP customer because the configuration change was applied incrementally and was reverted before reaching everyone. ## Recovery Efforts - Engineers detected the issue through failures involving `one.one.one.one` and reverted the change. - Cloudflare published dashboard guidance at 19:19 UTC, allowing many customers to re-advertise their prefixes themselves. - Around 800 prefixes were restored by approximately 20:20 UTC. - About 300 prefixes could not be restored through the dashboard because their service configurations had been removed from edge servers. - Engineers manually restored those remaining prefixes at 23:03 UTC. - Some customers continued to experience latency and failures while addressing configuration state propagated back to the edge. ## The Addressing API - Cloudflare’s Addressing API is the authoritative dataset for IP addresses present on its network. - Changes to the API drive workflows that propagate address and routing updates across Cloudflare’s edge. - The normal process is: - Customers request advertisement or withdrawal through the Addressing API or BGP Control. - The API instructs machines to change prefix advertisements. - Routers update BGP after enough machines receive the change. - Customers bind Cloudflare products to their BYOIP ranges. - Because the API is closely connected to production systems, manual changes are risky. - Cloudflare’s “Code Orange: Fail Small” initiative aims to replace manual Addressing API operations with safer, automated, health-checked workflows. ## Root Cause: Faulty BYOIP Cleanup Automation - The failed change automated the removal of prefixes from BYOIP, a task that had previously been performed manually. - A recurring cleanup sub-task searched for BYOIP prefixes marked for deletion and removed them. - The cleanup task issued the API request: ```go /v1/prefixes?pending_delete ``` - The request contained a bug in how the API query was interpreted. - As a result, the cleanup process unintentionally withdrew customer prefixes and removed related service configurations from some edge servers. - The incident lasted much longer than the initial withdrawal because restoring both advertisements and edge configuration state required extensive automated and manual recovery. Cloudflare’s main corrective direction is to make Addressing API changes safer through incremental, health-mediated deployment, stronger safeguards around automated deletion, and elimination of risky manual production workflows.

cloudflare

Cable cuts, storms, and DNS: a look at Internet disruptions in Q4 2025 (opens in new tab)

In Q4 2025, Internet disruptions were driven primarily by submarine cable cuts, power failures, extreme events, technical problems, and one government-directed shutdown. Tanzania experienced a prolonged election-related blackout, while damaged international cables disrupted connectivity in Haiti, Pakistan, Cameroon, and the Dominican Republic. Cloudflare’s analysis uses major deviations in network traffic and routing announcements to identify these incidents, though it is not exhaustive. ## Government-Directed Shutdown ### Tanzania - Internet traffic fell by more than 90% on October 29 during violent protests surrounding the presidential election. - The initial shutdown lasted about 26 hours, but a second near-total outage began shortly after service briefly returned. - Connectivity did not substantially recover until November 3. - Announced IPv4 and IPv6 address space declined slightly but never disappeared entirely, indicating that Tanzania was not completely disconnected from the global Internet. - Internet and social media restrictions had also occurred ahead of Tanzania’s 2020 elections. ## Submarine and Fiber Cable Cuts ### Digicel Haiti - Digicel Haiti suffered two international fiber cuts during the quarter. - On October 16, traffic fell to nearly zero; the provider reported two cuts and restored the first fiber within several hours. - On November 25, another cut along National Road 1 caused a complete outage lasting roughly six hours. - Service was restored after repairs to the international optical fiber infrastructure. ### Cybernet/StormFiber in Pakistan - Traffic dropped to about half its expected level on October 20, while announced IPv4 address space fell by more than one-third. - The cause was a cut to the PEACE submarine cable in the Red Sea near Sudan. - Pakistan has multiple international cable routes, including IMEWE and SEA-ME-WE-4, which helped enable rapid recovery. - Traffic and address announcements returned close to normal by October 21, ahead of the provider’s October 27 restoration target. ### Cameroon and the WACS Cable - Camtel, MTN Cameroon, and Orange Cameroun experienced major disruptions on October 23 because of an incident involving the West Africa Cable System (WACS). - Traffic initially fell around 05:00 local time and recovered by approximately 22:00, although it fluctuated dramatically and sometimes dropped by 90–99%. - MTN and Orange also saw reductions in announced IP address space, while Camtel’s announcements remained stable. - The volatility may have reflected attempts to reroute traffic over other submarine cables. - Connectivity in the Central African Republic and Republic of Congo was reportedly affected as well. ### Claro Dominicana - Claro Dominicana experienced two sharp traffic declines on December 9. - Traffic eventually fell 77% below the comparable level from the previous week. - The provider attributed the disruption to two severed fiber-optic cables, which caused intermittent service and slow speeds. - Technicians restored nationwide service after repairing the cables. ## Power-Related Disruption ### Dominican Republic - A transmission-line outage on November 11 caused a major national power interruption. - Internet traffic fell by nearly 50% compared with the previous week and remained depressed until December 12. - The electrical operator later reported that 96% of national demand had been restored. - A technical report traced the blackout to a manually disconnected live line at the 138 kV San Pedro de Macorís I substation. - The resulting short circuit triggered protection systems and disconnected nearby lines, separating 575 MW of generation. ## Overall Pattern - More than 180 Internet disruptions were observed globally during 2025. - Q4 included only one government-directed shutdown, but several international cable failures caused severe regional outages. - Traffic measurements and BGP address announcements helped distinguish partial connectivity loss from complete national disconnection. - The incidents demonstrate how dependent national networks remain on a limited number of submarine cables, fiber routes, and reliable electrical infrastructure. Cloudflare’s findings suggest that network operators should diversify international cable routes, improve redundancy, and prepare for power and infrastructure failures. The Cloudflare Radar Outage Center provides a broader list of verified anomalies and confirmed outages.

cloudflare

What came first- the CNAME or the A record (opens in new tab)

A memory-optimization change in Cloudflare’s 1.1.1.1 resolver accidentally reordered DNS records, placing CNAMEs after A/AAAA records. Although DNS record order is generally considered irrelevant, some clients—including glibc’s `getaddrinfo`—process answers sequentially and require CNAMEs to appear first. The resulting failures affected users globally until Cloudflare reverted the release. ## Incident Timeline - **December 2, 2025:** The record-reordering change was added. - **December 10:** It reached the testing environment. - **January 7, 2026:** Global deployment began. - **January 8, 17:40 UTC:** The change reached 90% of servers. - **18:19:** The incident was declared. - **18:27:** The release was reverted. - **19:55:** The revert completed and the impact ended. ## How CNAME Chains Are Resolved - A hostname may point through multiple aliases before reaching an A or AAAA record: - `www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1` - Each record has its own TTL and may expire independently. - If only part of a chain expires, 1.1.1.1 can reuse the cached portion and resolve only the missing records. - The resolver then combines the cached CNAME records with newly resolved address records. ## The Memory Optimization That Changed Ordering - Previously, the resolver created a new list: - Insert the existing CNAME chain first. - Append the newly resolved A/AAAA records afterward. - The optimization avoided allocations and copies by appending new CNAME records directly to the existing answer list. - This caused some responses to place address records before CNAME records. ## Why Some DNS Clients Failed - Many clients treat answer-section ordering as irrelevant, but some parse records sequentially. - These clients: - Start by looking for records matching the original queried name. - Update the expected name when they encounter a CNAME. - Accept the corresponding A or AAAA record only after that update. - With the expected order, the client sees the CNAME first and then accepts the address record. - With the address record first, it ignores the address because it does not yet match the expected name. After encountering the CNAME, there are no records left to process, so it reports an empty response. - The affected implementation included glibc’s `getaddrinfo`, widely used for DNS resolution on Linux. The incident demonstrates that even seemingly insignificant DNS response ordering can matter in practice. Resolver implementations should preserve CNAME-before-address ordering, and DNS clients should avoid assuming that record order is meaningful unless the protocol explicitly requires it.

cloudflare

What we know about Iran’s Internet shutdown (opens in new tab)

Iran’s government effectively disconnected the country from the global Internet on January 8, 2026, amid escalating nationwide protests. Cloudflare observed a near-total loss of traffic after major Iranian networks withdrew most announced IPv6 address space and then lost connectivity almost entirely. Brief access windows on January 9 quickly ended, and the shutdown remained in place through January 10. ## Background and Earlier Shutdowns - Iran has previously restricted Internet access during protests: - More than five days of disruption followed fuel-price protests in November 2019. - Connectivity was disrupted across multiple providers during protests after Mahsa/Zhina Amini’s death in September 2022. - Internet traffic had already been below normal at the beginning of 2026, suggesting connectivity problems preceded the complete shutdown. ## Connectivity Collapsed on January 8 - At 11:50 UTC, Iranian networks reduced announced IPv6 address space by 98.5%, from over 48 million `/48` blocks to roughly 737,000. - This caused IPv6’s share of human-generated traffic to fall from about 12% to 2%, before IPv6 traffic nearly disappeared later that afternoon. - Between 16:30 and 17:00 UTC, overall traffic dropped by nearly 90%. - Major providers affected included: - MCCI (AS197207) - IranCell (AS44244) - TCI (AS58224) - By approximately 18:45 UTC, traffic from Iran had fallen effectively to zero, indicating a nationwide disconnection from the global Internet. ## Brief Connectivity on January 9 - Internal traffic remained below 0.01% of pre-shutdown peaks. - Access to Cloudflare’s `1.1.1.1` DNS resolver briefly returned around 10:00 UTC, producing a short-lived spike in requests. - Several universities also regained connectivity temporarily, including the University of Tehran, Sharif University of Technology, Tehran University of Medical Science, and Tarbiat Modares University. - Traffic from these networks disappeared again by roughly 15:00 UTC. ## Filtering Changes Before the Shutdown - HTTP/3 and QUIC usage declined sharply before the full outage. - On IranCell, HTTP/3 usage fell from as high as 40% to 5% by December 31 and continued declining. - On TCI, HTTP/3 dropped below 5% around January 3. - These changes may indicate increasingly severe filtering and upgraded whitelisting, according to MahsaNet. ## Ongoing Disconnection - Since January 10, Iran’s Internet traffic has shown no significant recovery. - Traffic remains at only a fraction of one percent of previous levels. - Cloudflare continues monitoring the situation through Radar’s traffic and routing data. The available measurements strongly indicate a deliberate, nationwide Internet shutdown rather than an ordinary network failure. Cloudflare Radar’s traffic and routing pages provide the most practical way to follow any restoration or further changes.