Cases2 cases
1 to 2 of 2
IL-0260zoom.us stopped resolving for about two hours after GoDaddy Registry placed a server block on the domainZoom2025- Symptoms
On 16 April 2025 customers in the US and International regions could not reach Zoom services because lookups of the zoom.us domain failed. Starting, joining or scheduling a meeting needs a DNS lookup, so none of those actions completed; people already in a Zoom meeting or on a Zoom Phone call were not affected.
- Trigger
A communication error between Zoom's domain registrar, Markmonitor, and GoDaddy Registry led GoDaddy Registry to place a server block on zoom.us by mistake, which shut the domain down.
- Root cause
- Component
- Contributing factor
- Remediation
- Identified and removed the server block on zoom.us together with Markmonitor and GoDaddy
- Asked users who still had connection problems to flush their DNS cache and reconnect
- Action items
- Put a registry lock on zoom.us that restricts server block commands on the domain
- Implement additional technical changes and processes with GoDaddy Registry and Markmonitor so the issue does not recur
IL-0269Octez Connect services went down for hours when its only DNS provider failed and the nodes' records stopped resolvingOctez 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.
- Trigger
An outage at Octez Connect's DNS provider, metanet.ch, stopped the DNS records of its nodes from resolving.
- Root cause
- Component
- Contributing factor
- 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.
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
Dependency failure2 cases
- Organisation