Zoom.us डोमेन 'निष्क्रिय' होने से Zoom सेवा में बाधा

 (status.zoom.us)
1 पॉइंट द्वारा GN⁺ 2025-04-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 16 अप्रैल 2025 को Zoom की कई सेवाओं में आई बाधा zoom.us डोमेन resolution failure से शुरू हुई, जिससे अमेरिका और अंतरराष्ट्रीय क्षेत्रों के ग्राहक सेवा तक नहीं पहुंच सके
  • बाधा PDT 11:25 पर रिपोर्ट हुई और 13:12 पर हल हुई; Zoom Meetings और Zoom Phone·Zoom CX·Zoom Website के web portals प्रभावित हुए
  • Zoom के अंदर कोई product, security, network outage या DDoS attack नहीं था; वजह Markmonitor और GoDaddy Registry के बीच communication error थी
  • जो users पहले से meetings या Zoom Phone calls में थे, वे प्रभावित नहीं हुए, लेकिन start·join·schedule requests के लिए DNS lookup जरूरी होने से वे fail हो सकती थीं
  • Zoom, Markmonitor और GoDaddy ने server block हटाकर recovery की, और दोबारा ऐसा न हो इसके लिए zoom.us डोमेन पर registry lock लागू किया

बाधा का दायरा और समय

  • बाधा ने zoom.us डोमेन resolution failure के कारण कई Zoom services तक access को प्रभावित किया
  • service issue 16 अप्रैल 2025 को सुबह 11:25 PDT पर report हुआ और दोपहर 1:12 PDT पर resolve हुआ
  • अमेरिका और अंतरराष्ट्रीय क्षेत्रों के ग्राहक Zoom services तक नहीं पहुंच सके
  • प्रभावित services:
    • Zoom Meetings
    • Zoom Phone - Global का Web Portal
    • Zoom CX - Global का Web Portal
    • Zoom Website का Web Portal

कारण और recovery process

  • Zoom के domain nameservers requests का सामान्य रूप से जवाब दे रहे थे
  • असली कारण GoDaddy Registry का server block था, जिससे zoom.us डोमेन unavailable हो गया
    • यह block Zoom के domain registrar Markmonitor और GoDaddy Registry के बीच communication error से हुआ
    • नतीजतन GoDaddy Registry ने गलती से zoom.us डोमेन को terminated state में डाल दिया
  • बाधा के दौरान Zoom के अंदर कोई product outage, security outage, network outage या DDoS attack नहीं था
  • जो end users पहले से Zoom meeting या Zoom Phone call में शामिल थे, वे प्रभावित नहीं हुए
  • meeting शुरू करना, join करना और schedule करने जैसे operations के लिए DNS lookup जरूरी था, इसलिए वे सामान्य रूप से पूरा नहीं हो सके
  • Zoom, Markmonitor और GoDaddy ने server block की पहचान कर उसे हटाया और zoom.us डोमेन service को restore किया
    • DNS entries कई layers में cache होती हैं और उनमें TTL set होता है, इसलिए डोमेन reactivation के बाद पूरे internet infrastructure में propagate होने में कुछ मिनट और लगे

दोबारा होने से रोकथाम और users के लिए कदम

  • GoDaddy Registry और Markmonitor ने दोबारा ऐसा न हो, इसके लिए zoom.us डोमेन पर registry lock लागू किया
    • यह lock zoom.us डोमेन पर server block command लागू होने को restrict करता है
  • जिन users को अभी भी connection problem है, वे DNS cache clear करने के बाद फिर से connect कर सकते हैं
    • Windows: ipconfig /flushdns
    • Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-04-18
Hacker News की राय

  • MarkMonitor की सेवा की वैल्यू काफी गिरती हुई दिखती है। MarkMonitor खुद को “1999 से ICANN-accredited registrar और industry leader” बताकर प्रमोट करता है।
    MarkMonitor को महंगा भुगतान करने की वजह यही होती है कि महत्वपूर्ण domains संभालते समय ऐसी गलतियां न हों, और यहां GoDaddy के दखल की गुंजाइश नहीं होनी चाहिए थी।

    • GoDaddy Registry .us registry चलाती है, इसलिए .us domains GoDaddy की भागीदारी के बिना रखे ही नहीं जा सकते।
      अगर यह पसंद नहीं था, तो Verisign द्वारा चलाए जाने वाले .com को चुनना चाहिए था।
    • मुझे जिज्ञासा हुई कि बड़ी tech companies कौन-से domain registrar इस्तेमाल करती हैं, इसलिए Whois lookup किया। Microsoft, Google, Amazon, Tesla, Netflix, Shopify सभी MarkMonitor इस्तेमाल कर रहे थे।
      वहीं Apple “Nom-iq Ltd. dba COM LAUDE”, Meta की कंपनियां RegistrarSafe, और Nvidia SafeNames इस्तेमाल करती हैं।
    • MarkMonitor को पैसे देने की वजह आखिरकार GoDaddy से संपर्क करके समस्या हल कर पाने की क्षमता भी हो सकती है।
      अगर यही समस्या किसी छोटे startup के साथ हुई होती, तो लगता है GoDaddy शायद बात तक न करता।
    • GoDaddy .us का root DNS चलाता है।
    • MarkMonitor की एक और वैल्यू ऐसे country code top-level domains (ccTLD) तक पहुंच दिलाने में है जिनकी शर्तें सीधे पूरी करना मुश्किल होता है।
      उदाहरण के लिए जब उस देश में वास्तविक पता चाहिए होता है, तो MarkMonitor कई देशों में offices रखकर वह शर्त पूरी कर सकता है और फिर ग्राहकों को ccTLD domains बेच सकता है।
      इस तरह की संरचना की वैधता थोड़ी संदिग्ध लगती है, लेकिन मैं कानूनी विशेषज्ञ नहीं हूं।

  • उस समय अपने employer को Zoom छोड़ने के लिए मनाने के मकसद से मैंने तय किया कि 2–3 घंटे में कितनी security vulnerabilities मिल सकती हैं।
    सिर्फ binwalk और सार्वजनिक स्रोतों की जानकारी से उस समय में 12 confirmed bugs मिल गए, और सबसे गंभीर यह था कि zoom.us के GoDaddy account का password reset email Eric S Yuan CEO के personal Gmail account पर था।
    Gmail password reset आजमाया तो 2-factor authentication नहीं था, सिर्फ hometown और phone number वाले दो reset questions चाहिए थे; सार्वजनिक सामग्री से उनके जवाब मिल गए, reset link मिल सकता था और वहां से zoom.us domain control तक पहुंचा जा सकता था।
    ऐसा कोई security team का व्यक्ति नहीं मिला जो अंग्रेजी में समझा सके, और Zoom को इसे verify करके कुल 800 डॉलर bug bounty देने में 3 महीने लगे।
    कम से कम इसी वजह से मेरे employer ने Zoom छोड़ दिया।

    • जानना चाहूंगा कि यह कब की बात थी। कुछ साल पहले Zoom अमेरिका में security team के लोगों की actively hiring कर रहा था, और dedicated fuzzing team भी बना रहा था।
      लगता है यह उस शुरुआती दौर की बात होगी जब Zoom बस popular होना शुरू हुआ था।
    • क्या आप अभी यह स्वीकार कर रहे हैं कि आपने felony की थी?

  • GoDaddy इतनी अक्षम संस्था है कि उसे किसी भी महत्वपूर्ण चीज का प्रबंधन नहीं सौंपना चाहिए।

    • GoDaddy को दोष देना आसान है, लेकिन communication failure होने के लिए दोनों पक्षों की जरूरत होती है।
      ऐसी चीजें न हों, इसी के लिए MarkMonitor को भारी रकम दी जाती है, और MarkMonitor के पास GoDaddy में dedicated contact और direct communication channel होना चाहिए था।
      भले ही GoDaddy ने request से अलग process किया हो, यह MarkMonitor की तरफ से भी बड़ी गलती है।
    • किसे पता था कि Hooters कर्मचारियों जैसी ड्रेस पहनी महिलाओं वाले ads चलाने वाली कंपनी आखिर में पूरी clown car बन जाएगी।

  • कुछ साल पहले मैंने .us top-level domain इस्तेमाल किया था, लेकिन आखिर में तय किया कि अपने domain को country code पर निर्भर नहीं रहने देना चाहिए।
    .io इस्तेमाल न करने की वजह भी यही है।
    इसका मतलब यह नहीं कि generic top-level domains में ऐसा होना असंभव है, लेकिन अपनी brand को इस तरह किसी सरकार के हाथ में क्यों सौंपना?

    • कोई भी top-level domain किसी न किसी देश के कानून से मुक्त नहीं है। शायद .aq या .su?
      इस शर्त पर .eu बेहतर उम्मीदवार हो सकता है, लेकिन पुराने UK domain owners से पूछ लें कि उनके साथ क्या हुआ।
      generic top-level domains सिर्फ operating company नाम की एक अतिरिक्त अक्षमता की परत जोड़ते हैं, और जिस देश में वह company है, वहां की government अब भी हस्तक्षेप कर सकती है।
      उदाहरण के लिए .nl भी Netherlands government officials नहीं चलाते; मेरी याद में इसे 80s में कुछ लोगों द्वारा शुरू की गई non-profit organization चलाती है।
    • Zoom अमेरिका में incorporated है और उसके अधिकतर कर्मचारी भी अमेरिका में हैं, इसलिए वह पहले से ही अमेरिकी government के प्रभाव क्षेत्र में है।
      .com जैसे “generic” top-level domains भी आखिरकार US jurisdiction में आते हैं।
    • .io से बचना अच्छी किस्मत थी। .io के पूरी तरह बंद हो जाने का जोखिम है।
      अभी फैसला नहीं हुआ है, लेकिन ऐसी uncertainty सिर पर लटकाए रखने की जरूरत नहीं है।
    • मेरी government, Canada, पर मैं आम तौर पर भरोसा करता हूं, और .ca domains में WHOIS जानकारी default रूप से hidden रहती है, यह अच्छा है।
      मैं यहीं रहता हूं और आगे भी रहूंगा, इसलिए मुझे और मेरे काम को represent करने के लिए national top-level domain इस्तेमाल करना ठीक लगता है।
    • सचमुच हर top-level domain किसी न किसी government के control में है।
      .com खुद भी US jurisdiction में है और Verisign इसे चलाता है।

  • इसी संभावना की वजह से Fastmail ने fastmail.com खरीदा और पुराने fastmail.fm domain से migrate किया।
    .fm cool था, लेकिन .fm server outages कई बार झेलने पड़े और service offline हो गई; .com पर आने के बाद ऐसी समस्या नहीं हुई।

  • GoDaddy के साथ deal करते समय इतने service outages होना हैरान करने वाला है।

    • जब Zoom ने zoom.us domain लिया था, तब शायद Neustar .us registry चलाता था।
      GoDaddy ने 2020 में Neustar का registry business acquire किया, जब सबका ध्यान कहीं और था।
    • सोचता हूं कि outages की संख्या को customers की संख्या से divide करने पर भी ऐसा ही दिखता है या नहीं।
      मैं customer नहीं हूं और विदेश से domain खरीदने का इरादा भी नहीं है; GoDaddy के बारे में मेरा कोई पक्का विचार नहीं है, सिवाय इसके कि नाम पसंद नहीं है।
      डरावनी कहानियां बहुत सुनी हैं, लेकिन यह भी सोचता हूं कि कहीं यह immediate reflex reaction तो नहीं।

  • Zoom client जिन endpoints को call करता है, उनके लिए secondary और tertiary domains होने चाहिए, और registrar व hosting infrastructure भी diversify करना चाहिए।
    service discovery के लिए backup anycast IP addresses भी हों तो अच्छा होगा।
    हमारी जैसी कंपनियां जितना भुगतान करती हैं, उसे देखते हुए इस स्तर की engineering preparedness की उम्मीद की जा सकती है, और इसे अभी भी ठीक किया जा सकता है।
    देर रात तक incident handle कर रहे employees के लिए #HugOps

    • खास तौर पर यह बात खीझ दिलाने वाली थी कि status check host भी zoom.us domain के अंदर था।

  • अगर Zoom CEO कहें, “आपकी कंपनी की वजह से हुई वैश्विक outage के लिए हम SLA credits चाहते हैं”, तो लगता है GoDaddy जवाब देगा, “माफ़ कीजिए। अगली खरीदारी या renewal पर हम आपको एक बार के लिए 10 डॉलर का discount coupon दे सकते हैं”
    ज़्यादातर कंपनियां उम्मीद करती हैं कि माफ़ी मांगने वाली एक Zoom call ग्राहक को बनाए रखने के लिए काफी होगी, और असल में अक्सर ऐसा चल भी जाता है
    किसी खास supplier outage में SLA credits और revenue impact के बीच asymmetry कितनी बड़ी होती है, और build vs buy के फैसले में इसे कैसे शामिल किया जाना चाहिए, इस पर पर्याप्त चर्चा नहीं हुई है

    • शायद कोई यह नहीं चाहेगा कि SLA credits को lost revenue के बड़े हिस्से की भरपाई करने के लिए optimize किया जाए
      ऐसा करने का मतलब होगा कि सामान्य operations के दौरान profit margin बहुत कम है
      SLA, outage से खोए revenue की भरपाई करने के बजाय, किसी unreliable supplier के साथ long-term contract से बाहर निकलने के साधन के तौर पर ज़्यादा उपयोगी है
    • Zoom जैसे scale की service GoDaddy क्यों इस्तेमाल करती है, समझ नहीं आता
      GoDaddy कई सालों से खराब रहा है, और top customer न होने पर ACME API को block कर देने का उनका तरीका मेरे लिए final straw था
      मैं उस पर कभी भरोसा नहीं करूंगा
    • अगर Zoom ही down हो गया हो तो माफ़ी मांगने वाली Zoom call भी नहीं हो सकती
    • symmetry लानी हो तो domain renewal की कीमत करीब 20 डॉलर नहीं, बल्कि compensation वहन करने के लिए millions of dollars होनी चाहिए
      अगर आप यही चाहते हैं, तो किसी insurer से उस incident के लिए custom insurance खरीदकर लगभग वैसी ही annual cost दे सकते हैं
      build vs buy में भी, खुद बनाया हुआ solution अक्सर खरीदे हुए से खराब होता है
      खरीदे गए product दुनिया भर के customers की bug reports से लगातार fix होते रहते हैं, लेकिन internal tools का उतना stress test होना और battle-hardened होना दुर्लभ है
    • CrowdStrike outage के समय Starbucks coupon offer करने की बात याद है। लगता है बात उसी दिशा में जा रही है

  • ऐसा लगता है कि MarkMonitor की तरफ कुछ हुआ। हो सकता है zoom.us को गलती से brand impersonation के रूप में flag किया गया हो, .us top-level domain चलाने वाले GoDaddy के पास copyright complaint दी गई हो, और GoDaddy ने उस complaint के आधार पर domain suspend कर दिया हो

    • मुमकिन है, लेकिन MarkMonitor Zoom का registrar है, इसलिए MarkMonitor और GoDaddy के बीच communication error से ऐसा result आने के और भी कई तरीके हो सकते हैं
      अगर MarkMonitor का ज़िक्र तो हुआ हो लेकिन कोई और relevance न हो, तो copyright complaint वाला theory ज़्यादा plausible लगता
    • हो सकता है मुझे गलत याद हो, लेकिन मुझे याद है कि एक automated service email आया था जिसमें कहा गया था कि Zoom.us को Zoom.com से replace किया जाएगा
      जब यह outage हुआ तो मुझे लगा कि आखिरकार उन्होंने “transition” कर दिया और कुछ गड़बड़ हो गई
      आज सुना कि @zoom_us Twitter account भी delete हो गया है
    • अगर यह सच है, तो यह ऐसे automated takedown actions को reject करने का बहुत साफ़ उदाहरण है
      GitHub, YouTube आदि पर copyright infringement complaints का दुरुपयोग हो सकता है और वास्तव में हो भी रहा है
      समझ नहीं आता कि समाज में presumption of guilt कब से default हो गया
      GoDaddy सरकार नहीं है, लेकिन यह स्वीकार्य नहीं है
      कोई इंसान domain को बस 3 सेकंड देखता तो समझ जाता कि यह false positive है और इसे हटाया नहीं जाना चाहिए

  • ThousandEyes का outage analysis: https://www.thousandeyes.com/blog/zoom-outage-analysis-april...

    • article में facts तो बहुत सूचीबद्ध हैं, लेकिन असल में क्या हुआ, यह explain नहीं करता
      उदाहरण के लिए, यह बताता है कि DNS क्या है, लेकिन outage क्यों हुआ यह नहीं बताता; बस timeline देता है, उस context के साथ जो DNS क्या है और कैसे काम करता है यह अभी सीख रहे लोगों के लिए उपयोगी है
    • मुझे बिल्कुल पता नहीं था कि .us जैसे domain के लिए सभी DNS queries actual nameserver तक जाने से पहले एक single root registry से होकर गुजरती हैं