{"id":"IL-0260","org":"Zoom","date":"2025-04-16","docs":[],"title":{"en":"zoom.us stopped resolving for about two hours after GoDaddy Registry placed a server block on the domain","ko":"zoom.us 도메인이 레지스트리에서 차단되어 DNS 조회가 실패하고 Zoom 서비스에 접속할 수 없었다"},"domain":["networking"],"impact":{"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":"Zoom customers in the US and International regions","region":"US and International regions"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.zoom.us/incidents/pw9r9vnq5rvk","kind":"official-status","archived":"https://web.archive.org/web/20250809063112/https://status.zoom.us/incidents/pw9r9vnq5rvk"}],"summary":{"en":"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.\n\nZoom, 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.","ko":"2025년 4월 16일 오전 11시 25분 PDT 에 장애가 보고됐다. Zoom 은 zoom.us 도메인의 이름 해석 실패를 조사했는데, Zoom 의 네임 서버는 요청에 정상으로 응답하고 있었다. 등록기관 Markmonitor 와 GoDaddy Registry 를 함께 조사하자 GoDaddy Registry 가 건 server block 때문에 zoom.us 를 쓸 수 없는 상태임이 드러났다. 원인은 Markmonitor 와 GoDaddy Registry 사이의 소통 오류였고, 그 때문에 GoDaddy Registry 가 도메인을 실수로 내렸다. Zoom 은 장애 동안 Zoom 쪽에 제품, 보안, 네트워크 장애나 DDoS 공격은 없었다고 밝혔다.\n\n미국과 국제 리전의 고객이 Zoom 서비스에 접속하지 못했다. 회의 시작, 참가, 예약은 DNS 조회가 필요해서 실패했고, 이미 진행 중이던 회의와 통화는 이어졌다. Zoom, Markmonitor, GoDaddy 가 server block 을 찾아 풀자 도메인이 되살아났다. DNS 캐시와 TTL 때문에 복구가 인터넷 전체에 퍼지기까지 몇 분이 더 걸렸다. 보고서는 오후 1시 12분 PDT 를 해결 시각으로 적었다. 이후 GoDaddy Registry 와 Markmonitor 는 zoom.us 에 server block 명령을 걸지 못하게 하는 registry lock 을 걸었다."},"trigger":{"en":"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.","ko":"도메인 등록기관 Markmonitor 와 GoDaddy Registry 사이에 소통 오류가 생겼고, 그 결과 GoDaddy Registry 가 zoom.us 도메인에 server block 을 걸어 도메인을 잘못 내렸다."},"severity":"unknown","symptoms":["dns-resolution-failures","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"1h 47m"},"date_kind":"incident","detection":null,"components":["dns-server"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"Identified and removed the server block on zoom.us together with Markmonitor and GoDaddy","ko":"Zoom, Markmonitor, GoDaddy 가 함께 server block 을 찾아 풀었고, zoom.us 도메인 서비스가 되살아났다."}},{"text":{"en":"Asked users who still had connection problems to flush their DNS cache and reconnect","ko":"복구 뒤에도 접속 문제가 남은 사용자에게 DNS 캐시를 비우고 다시 접속하라고 안내했다. Windows 에서는 명령 프롬프트에서 \"ipconfig /flushdns\" 를, Mac 에서는 터미널에서 \"sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder\" 를 실행하게 했다."}}],"action_items":[{"text":{"en":"Put a registry lock on zoom.us that restricts server block commands on the domain","ko":"GoDaddy Registry 와 Markmonitor 는 zoom.us 도메인에 server block 명령을 걸지 못하게 막는 registry lock 을 걸었다."}},{"text":{"en":"Implement additional technical changes and processes with GoDaddy Registry and Markmonitor so the issue does not recur","ko":"Zoom 은 GoDaddy Registry, Markmonitor 와 함께 같은 일이 다시 나지 않도록 기술 변경과 절차를 추가로 도입했다."}}],"contributing":["no-safeguard-on-destructive-change"],"recurrence_of":null,"symptoms_text":{"en":"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.\n\nThe 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.\n\nWhen 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.\n\nServices 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.","ko":"미국과 국제 리전의 고객이 Zoom 서비스에 접속하지 못했다. Zoom 은 zoom.us 도메인의 이름 해석이 실패하는 문제를 조사하기 시작했다.\n\n회의 시작, 회의 참가, 회의 예약은 DNS 조회가 필요해서 모두 실패했다. 이미 회의나 Zoom Phone 통화에 들어가 있던 사용자는 영향을 받지 않았다. 상태 페이지는 영향받은 서비스로 Zoom Meetings, Zoom Phone - Global 의 웹 포털, Zoom CX - Global 의 웹 포털, Zoom 웹사이트를 적었다.\n\n처음 조사해 보니 Zoom 의 네임 서버는 요청에 정상으로 응답하고 있었다. 등록기관 Markmonitor, 레지스트리 GoDaddy Registry 와 함께 더 조사한 뒤에야 GoDaddy Registry 가 zoom.us 에 server block 을 걸어 도메인을 쓸 수 없게 된 것을 확인했다.\n\n도메인이 되살아난 뒤에도 DNS 레코드가 여러 단계에 캐시되어 있고 TTL 이 남아 있어서, 복구가 인터넷 전체에 퍼지기까지 몇 분이 더 걸렸다. 그동안 접속이 안 되는 사용자는 DNS 캐시를 비우고 다시 접속해야 했다."},"updated_at":"2026-11-14T12:33:51.052249Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0260","org_slug":"zoom"}