Zoom outage caused by accidental 'shutting down' of the zoom.us domain

Original Article ↗ Hacker News Discussion ↗

What actually happened (as inferred by commenters)

  • Official explanation: a “communication error” between Zoom’s registrar (MarkMonitor) and the .us registry operator (GoDaddy Registry) led to zoom.us being “shut down.”
  • DNS symptom: the domain was in serverHold status, which removes NS records so the domain stops resolving.
  • Several participants say serverHold is usually legal/nexus-related, not a typical “oops,” so the vague “communication error” sounds incomplete.
  • Speculated mechanisms:
    • Mistyped domain in an enforcement/takedown request (e.g., anti‑abuse tooling hitting zoom.us instead of a similar domain).
    • Wrong EPP status code applied (e.g., intending serverUpdateProhibited but setting serverHold).
    • Less likely: renewal/billing, since the renewal date and status codes don’t match normal expiry behavior.
  • ThousandEyes analysis is referenced for timeline and DNS behavior, but it also doesn’t fully explain why the hold was applied.

Responsibility: GoDaddy vs. MarkMonitor vs. Zoom

  • Many argue GoDaddy Registry bears primary blame for applying a registry‑level hold on a globally critical domain with minimal friction.
  • Others stress that “miscommunication” implies MarkMonitor’s side also failed; Zoom pays them precisely so things like this never happen.
  • Some claim (without clear public evidence) that MarkMonitor requested a safer lock and GoDaddy misapplied it.

Registrar, registry, and DNS choices

  • Clarifications:
    • MarkMonitor = registrar and brand‑protection service.
    • GoDaddy Registry = .us TLD operator; unavoidable if you insist on .us.
    • Zoom’s DNS itself runs on AWS Route 53.
  • Multiple people mock the idea of any critical service being at the mercy of GoDaddy, citing long‑standing reputational and UX issues.
  • Others counter that scale and base rates matter; widely used providers will naturally feature in more outage stories.

Risk of ccTLDs and architectural lessons

  • Incident fuels skepticism about relying on ccTLDs (.us, .io, .ps, etc.) for core brands:
    • Political/jurisdictional risk, arbitrary policy or pricing changes, weaker privacy (.us bans WHOIS privacy).
  • Counterexamples: some ccTLD operators (.de, .ca, .ch) are praised as stable and well‑run.
  • Architectural takeaways suggested:
    • Use alternative or backup domains on different TLDs/registrars for clients and status pages.
    • Avoid single‑TLD single‑registrar dependency for mission‑critical services.