Incident Library

IL-0260 Zoom · 2025-04-16networking

zoom.us stopped resolving for about two hours after GoDaddy Registry placed a server block on the domain

Zoom reported the issue at 11:25 AM PDT on 16 April 2025. Zoom's domain name servers were replying properly, but the zoom.us domain was unavailable at the registry: a communication error between Zoom's registrar Markmonitor and GoDaddy Registry had led GoDaddy Registry to put a server block on zoom.us and shut the domain down by mistake. Every action that needed a DNS lookup of zoom.us, such as starting, joining or scheduling a meeting, failed for customers in the US and International regions, while meetings and Zoom Phone calls already in progress continued.

Zoom, Markmonitor and GoDaddy identified and removed the server block, which restored the domain. Cached DNS entries with their TTL delayed full recovery by a few minutes, and the status page told users to flush their DNS cache. The issue was resolved at 1:12 PM PDT. As prevention, GoDaddy Registry and Markmonitor put a registry lock on zoom.us that restricts server block commands, along with other technical and process changes.

Severity
–
Scope
Zoom services that need a DNS lookup of zoom.us: starting, joining and scheduling meetings, the Zoom Meetings, Zoom Phone and Zoom CX web portals and the Zoom Website; meetings and calls already in progress kept working
Users affected
Zoom customers in the US and International regions
Region
US and International regions
Time to detect
–
Time to resolve
1h 47m

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.

The status page first reported the problem at 12:17 PDT as domain name resolution issues on the zoom.us domain affecting multiple services. The incident listed Zoom Meetings, the Zoom Phone - Global web portal, the Zoom CX - Global web portal and the Zoom Website as affected.

When Zoom investigated, its own domain name servers were answering requests correctly. Only when Zoom looked further together with its registrar Markmonitor and with GoDaddy Registry did it find that zoom.us was unavailable because GoDaddy Registry had placed a server block on the domain. Zoom states that there was no product, security or network failure and no DDoS attack on its side during the outage.

Services were back by 13:55 PDT, but because DNS entries are cached at several levels and carry a TTL, the reactivated domain took a few more minutes to propagate across the Internet. The status page asked users who still had connection problems to flush their DNS cache, with "ipconfig /flushdns" on Windows and "sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder" on Mac, and reconnect.

Symptom DNS resolution failuresService outage

Root cause

Root cause Dependency failure

Component Authoritative DNS servers and records
Contributing factor No safeguard on destructive change
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.

Detection

–

Remediation

Action items

Lessons

–

Sources

Related cases

Check your cluster for this

kubegap audits a Kubernetes cluster for conditions like the ones in this case, Authoritative DNS servers and records among them, read-only, from Claude Code or Codex. Its checks cite public reports like this one.

Open kubegap

For AI tools and scripts

The API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.