Cases11 cases

6 to 10 of 11

1. IL-0269 Octez Connect services went down for hours when its only DNS provider failed and the nodes' records stopped resolving

   Octez Connect2025

   Symptoms

   On 5 February 2025 at 04:34 the monitoring system flagged DNS resolution problems on the first Octez Connect node and raised a Pager Duty alert. Every server that relied on the same DNS provider went down, and users could not reach the services until the provider restored DNS.

   DNS resolution failuresService outage

   Trigger

   An outage at Octez Connect's DNS provider, metanet.ch, stopped the DNS records of its nodes from resolving.

   Root cause

   Dependency failure

   Component

   Authoritative DNS servers and records

   Contributing factor

   Single point of failureLimited debug access

   Detection

   The monitoring system flagged DNS resolution problems on the first node at 04:34 and raised a Pager Duty alert.

   Remediation

   • Escalated the DNS resolution alert through Pager Duty
   • Confirmed the provider's outage by repeatedly calling its hotline and watching its status page
   • Emailed the provider's support, which replied at 08:20 that it was looking into the issue
   • Tested DNS resolution and confirmed that DNS had been restarted
   • Posted a public update on Slack and Twitter announcing the recovery

   Action items

   • Configure a second DNS provider alongside the first
   • Build a public status page for real-time outage information
   • Review and improve internal escalation procedures for third-party outages

   Lessons

   Relying on a single DNS provider made it a single point of failure that brought down every connected service, and the provider's outage also slowed communication with it, which lengthened the downtime. Octez Connect concluded that it needs redundant DNS providers.

   View case
2. IL-0531 Azure Database for MySQL Single Server and MariaDB in West US rejected every new connection for a batch of servers

   Microsoft Azure2024

   Symptoms

   From 04:26 UTC on 19 April 2024, every new connection to a subset of Azure Database for MySQL - Single Server and Azure Database for MariaDB servers in West US failed, and retries did not help. The first report came at 04:46 UTC from Azure Databricks, which told the MySQL team that multiple databases were unreachable.

   Service outageIntermittent timeouts

   Trigger

   At 04:26 UTC, during planned maintenance in West US, the DNS update that moves new incoming connections for a batch of MySQL and MariaDB servers to a new gateway ring was made, and a procedural error pointed it at a newly built gateway ring whose configuration was incomplete.

   Root cause

   Operator error

   Component

   DatabaseAuthoritative DNS servers and records

   Contributing factor

   Monitoring blind spot

   Detection

   Service telemetry did not detect the failure because the new gateway ring had no telemetry or monitoring configured yet. At 04:46 UTC Azure Databricks reported to the MySQL team that multiple databases were unreachable.

   Remediation

   • Rolled back the DNS change and moved all connections back to the previous working gateway ring after validation

   Action items

   • Add checks, testing and sign-off procedures before switching production gateway rings
   • Add Azure Databricks alerts that detect multiple databases becoming unavailable within a short time

   View case
3. IL-0254 Square's internal DNS servers failed and Square products, services and payments were unavailable for about 15 hours

   Square2023

   Symptoms

   From 1:54 PM ET on 7 September 2023, Square products and services were unavailable, and at 2:02 PM ET engineers were notified of infrastructure issues and began investigating DNS. Square Online websites stayed up, but their customers could not make payments.

   DNS resolution failuresService outage

   Trigger

   At 11:04 AM ET a host-based firewall rule change was deployed to enable region communication, which increased the size of the firewall rules on nodes. Combined with a DNS service upgrade, it put unexpected load on the internal DNS servers. The timeline also lists a DNS zone change at 1:56 PM ET.

   Root cause

   Configuration change

   Component

   Authoritative DNS servers and recordsNode iptables rules

   Contributing factor

   No staged rolloutCache-masked failureCircular dependency

   Detection

   Engineers were notified of infrastructure issues at 2:02 PM ET, eight minutes after services became unavailable.

   Remediation

   • Shed network traffic to the DNS servers and started bringing up new DNS servers by hand
   • Deployed networking changes by hand to re-enable the authorization and access services
   • Deployed the networking changes by hand to all data centers
   • Rebuilt the DNS servers
   • Built a new configuration from the reverted firewall ruleset and pushed it to the DNS hosts

   Action items

   • Move the DNS infrastructure onto isolated infrastructure
   • Add monitoring and optimizations for critical networking infrastructure
   • Optimize dependencies between the deploy and platform infrastructure where feasible
   • Expand support for Offline Mode and improve communication about when it is available

   View case
4. IL-0221 A backbone maintenance command disconnected all Facebook data centers, and its DNS servers withdrew their BGP routes

   Meta2021

   Symptoms

   On 4 October 2021 Facebook's platforms went down worldwide: every connection in Facebook's global backbone network was lost, and the data centers were cut off from each other and from the internet. The rest of the internet could no longer find Facebook's servers, because Facebook's authoritative DNS servers had become unreachable.

   Service outageDNS resolution failuresNetwork unreachable

   Trigger

   During routine maintenance of the backbone, a command was issued to assess the availability of global backbone capacity, and it unintentionally took down all connections in the backbone network.

   Root cause

   Operator error

   Component

   Backbone network (WAN)BGP routingAuthoritative DNS servers and records

   Contributing factor

   Automation amplificationCircular dependencyLimited debug access

   Remediation

   • Sent engineers onsite to the data centers to debug the issue and restart systems
   • Brought the backbone network back online across the data center regions
   • Brought services back gradually, managing the rising load to avoid crashes from a traffic surge

   Action items

   • Find ways to simulate the global backbone being taken offline in storm drills
   • Strengthen testing, drills and overall resilience

   Lessons

   The hardening that protects Facebook's data centers against unauthorized access slowed recovery from an outage caused by Facebook's own error, and the author judges that tradeoff worth keeping. Storm drills prepared the teams to bring load back safely, although no drill had yet simulated the global backbone going offline.

   View case
5. IL-0229 bunny.net's DNS servers crashed in a loop on a corrupted routing database file and could not fetch a fix from its CDN

   bunny.net2021

   Symptoms

   On 22 June 2021, within minutes of an update released at 8:25 AM UTC, bunny.net's global fleet of close to 100 DNS servers kept crashing and restarting, more than 60% of traffic was lost, hundreds of Gbits of throughput disappeared, and over 750,000 websites were affected. After 10 minutes the team realised that the DNS servers were restarting and dying and that nothing could bring them back up in that state.

   Container crash loopDNS resolution failuresService outageMisrouted requestsLoad imbalance

   Trigger

   At 8:25 AM UTC bunny.net released an update meant to reduce the download size of the SmartEdge optimization database, and it uploaded a corrupted file to Edge Storage.

   Root cause

   Faulty deployment

   Component

   Authoritative DNS servers and recordsCDN and edge networkObject storage

   Contributing factor

   Circular dependencySingle point of failureAutomation amplificationIneffective rollbackHarmful manual action

   Detection

   About 10 minutes after the release, the team realised that the DNS servers were restarting and dying.

   Remediation

   • Deployed by hand an update that disabled the SmartEdge system on the DNS nodes
   • Routed all requests through Frankfurt instead of Madrid on a couple of DNS servers
   • Migrated the deployment systems and files to a third-party cloud storage service
   • Rewired the deployment system and DNS software to the new storage and deployed
   • Synced the databases and deployed the newest file sets through the third-party service

   Action items

   • Phase out the BinaryPack library as a hot-fix
   • Test third-party libraries more extensively
   • Migrate the internal APIs to an independent third-party service
   • Find how to stop non-critical software from becoming a single point of failure across clusters
   • Make the DNS system keep a local copy of all backup data with automatic failure detection

   Lessons

   bunny.net had built its systems to rely on each other, including the critical parts of its internal infrastructure, so one corrupted file brought down several layers of redundancy with no way back. A part of the infrastructure treated as non-critical turned out to be a single point of failure for several clusters at once, which canary deployments did not catch. Building infrastructure inside its own ecosystem lets one failure cascade through all of it. In the rush to fix the outage the team made typos and mistakes, and the final deployment came after it calmed down and double-checked everything.

   View case

By root cause5