Incident Library
Applied filters Root causeDependency failureComponentAuthoritative DNS servers and recordsSymptomService outageClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases2 cases

1 to 2 of 2

  1. 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
  2. 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.

Check your cluster for this

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