Cases2 cases
1 to 2 of 2
IL-0533Names in chinacloudapp.cn and chinacloudsites.cn stopped resolving as DNS caches expired, breaking Azure China servicesMicrosoft 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.
- 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
- Component
- Contributing factor
- 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
IL-0549Media, attachments, Git LFS and build artifacts failed for Atlassian in us-west-1 when an old network stack was removedAtlassian2023- 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.
- 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
- Component
- Contributing factor
- 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.
These 2 cases involve Authoritative DNS servers and records. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause1
Configuration change2 cases
- Contributing factor
- Organisation