Cases3 cases

1 to 3 of 3

1. IL-0502 The JupyterHub at temple.2i2c.cloud stopped resolving in DNS after a wildcard record was added for a new cluster

   2i2c2025

   Symptoms

   On 20 August 2025 at 10:02 AM Pacific time, an automated uptime check on temple.2i2c.cloud started failing and paged 2i2c: the JupyterHub at temple.2i2c.cloud could not be reached, shortly before the community that uses it was to give a demo.

   DNS resolution failuresService outage

   Trigger

   At 9:21 AM, while setting up a new cluster for Temple, a wildcard DNS record *.temple.2i2c.cloud was added pointing to the new cluster's Ingress IP.

   Root cause

   Configuration change

   Component

   Authoritative DNS servers and records

   Contributing factor

   Unverified assumptionCache-masked failureUnreviewed defaults

   Detection

   Automated uptime alerts caught the failure at 10:02 AM, before the community reported it in a support ticket at 10:09 AM.

   Remediation

   • Added an explicit A record for temple.2i2c.cloud in Namecheap
   • Lowered the DNS TTL from the 30-minute default to 5 minutes
   • Offered the community member running the demo an /etc/hosts entry as a workaround

   Action items

   • Give everyone on the team access to Namecheap, or move to another DNS provider
   • Use a 5-minute TTL instead of 30 minutes for all new DNS entries
   • Document that adding a *.X.2i2c.cloud DNS entry requires adding an X.2i2c.cloud entry as well

   Lessons

   Adding a wildcard record for a subdomain stopped a broader wildcard from answering for that subdomain's own name, so a *.X.2i2c.cloud record needs an X.2i2c.cloud record alongside it. The 30-minute default TTL at Namecheap meant any DNS fix could take that long to propagate, and the engineer creating the original record had no access to the DNS provider.

   View case
2. IL-0533 Names in chinacloudapp.cn and chinacloudsites.cn stopped resolving as DNS caches expired, breaking Azure China services

   Microsoft Azure2024

   Symptoms

   From 03:45 CST on 23 April 2024, FQDNs in two system domains of Azure in China, chinacloudapp.cn and chinacloudsites.cn, gradually stopped resolving, and customers in the Azure China regions had trouble connecting to many Azure services and managing resources. Internal monitors alerted engineers to the degradation at 04:37 CST.

   DNS resolution failuresHigh error rateMonitoring outage

   Trigger

   At 03:45 CST a configuration change made through a domain registrar, as a step of a domain decommissioning workflow, updated the nameservers of chinacloudapp.cn and chinacloudsites.cn to a set of inactive servers.

   Root cause

   Configuration change

   Component

   Authoritative DNS servers and records

   Contributing factor

   Unverified assumptionCache-masked failure

   Detection

   Internal monitors alerted engineers to the degradation in the Azure China Cloud at 04:37 CST and created an incident, which the engineering team acknowledged at 04:39 CST.

   Remediation

   • Reverted the two domains to their previous working nameservers

   Action items

   • Suspended further runs of the domain lifecycle process until the management tool covers Azure in China
   • Make the validation process of domain lifecycle management include signals from all cloud regions
   • Add validations that get nameserver information by resolving the zone directly over the Internet

   View case
3. IL-0549 Media, attachments, Git LFS and build artifacts failed for Atlassian in us-west-1 when an old network stack was removed

   Atlassian2023

   Symptoms

   From 02:36 UTC on 15 May 2023, Atlassian products with services hosted in the us-west-1 region could not store or retrieve data assets such as media, attachments and build artifacts. Automated monitoring detected it within three minutes, and the status page reported intermittent errors.

   High error rateStale endpoint routing

   Trigger

   An internal service was migrated to a new network segment as part of an initiative to harden the partitions between network segments, and the old network stack was then removed.

   Root cause

   Configuration change

   Component

   Authoritative DNS servers and records

   Contributing factor

   Unverified assumptionUnrepresentative staging

   Detection

   Automated monitoring detected the incident within three minutes.

   Remediation

   • Rolled back the network migration change, returning Atlassian systems to a known good state

   Action items

   • Review the systems that decommission service stacks and check that customer traffic is no longer served before a stack is decommissioned
   • Add steps to the service network migration process that identify associated DNS records needing attention

   Lessons

   Atlassian said the migration used blue/green deployment to limit this kind of risk, but adequate verification was not run before the old stack was decommissioned, and moving services between network segments is rare and hard to replicate in test.

   View case

By root cause1