Cloudflare 1.1.1.1 14 जुलाई 2025 आउटेज घटना

 (blog.cloudflare.com)
1 पॉइंट द्वारा GN⁺ 2025-07-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare ने 14 जुलाई 2025 को service topology बदलने के दौरान 1.1.1.1 public DNS Resolver में 62 मिनट की पूर्ण outage का सामना किया
  • दुनिया भर के अधिकांश users सीधे प्रभावित हुए और इंटरनेट इस्तेमाल न कर पाने जैसी स्थिति का सामना करना पड़ा
  • outage का कारण internal legacy system की गलत configuration था, और इसका बाहरी attack या BGP hijacking से कोई संबंध नहीं था
  • outage की शुरुआत गलत configuration changes के accumulation और network-wide reset के एक साथ होने से हुई
  • दोबारा ऐसी घटना रोकने के लिए gradual deployment system लागू करने और legacy configuration system को phase out करने की योजना तैयार की जा रही है

अवलोकन

14 जुलाई 2025 को Cloudflare ने service topology बदलते समय 1.1.1.1 public DNS Resolver में global network outage पैदा कर दिया। इस outage के कारण 1.1.1.1 और Gateway DNS services का उपयोग करने वाले users ने 62 मिनट तक इंटरनेट services अनुपलब्ध होने या गंभीर service degradation का अनुभव किया। यह internal legacy system की configuration error के कारण हुआ था, न कि किसी external attack या BGP hijacking की वजह से।

outage का दायरा और प्रभाव

  • 21:52 UTC ~ 22:54 UTC के दौरान 1.1.1.1 Resolver दुनिया भर में लगभग पूरी तरह अनुपयोगी स्थिति में था
  • अधिकांश global customers domain name resolution नहीं कर पाए, जिससे इंटरनेट का उपयोग करना ही असंभव हो गया
  • outage की स्थिति Cloudflare Radar में देखी जा सकती है
  • outage का कारण उस legacy system की गलत setting थी, जो Cloudflare के स्वामित्व वाले IP addresses को इंटरनेट पर advertise करने वाली infrastructure को manage करता है
  • 1.1.1.1 channel के जरिए Cloudflare तक पहुंचने वाला पूरा traffic गंभीर रूप से प्रभावित हुआ

outage का कारण और पृष्ठभूमि

  • Cloudflare DNS Resolver जैसी global services के लिए Anycast routing का उपयोग करता है
  • services कई regions में उपलब्ध हैं, लेकिन कुछ data localization की मांग वाली services केवल खास regions तक सीमित रहती हैं
  • 6 जून को भविष्य की DLS(data localization) service की तैयारी के लिए configuration change के दौरान, 1.1.1.1 Resolver IP range अनजाने में नए DLS में शामिल हो गया
    • यह error तुरंत प्रभावी नहीं हुआ और वास्तविक असर न होने के कारण alert भी trigger नहीं हुआ
  • 14 जुलाई को test purpose के लिए offline location को DLS topology में जोड़ने वाला change लागू किया गया
    • इस change ने global network configuration को force refresh कर दिया, जिससे पुरानी error सामने आ गई
    • 1.1.1.1 Prefixes दुनिया भर के data centers से withdraw हो गए और service रुक गई

outage timeline (सारांश)

  • 2025-06-06 17:38: DLS service के configuration change में 1.1.1.1 Prefixes शामिल हुए (कोई प्रभाव नहीं, error latent रही)
  • 2025-07-14 21:48: configuration change से network-wide configuration refresh हुआ, 1.1.1.1 Prefixes का global withdrawal शुरू
  • 2025-07-14 21:52: global DNS traffic में तेज गिरावट
  • 2025-07-14 22:01: internal alert, outage घोषित
  • 2025-07-14 22:20: previous configuration पर rollback, service recovery procedure शुरू
  • 2025-07-14 22:54: traffic सामान्य, alert clear, outage समाप्त

प्रभावित IP और protocols

  • प्रभाव का दायरा: 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 सहित IPv4, IPv6 के व्यापक Prefixes
  • UDP, TCP, DoT(DNS over TLS) query traffic में तेज गिरावट देखी गई
  • DoH(DNS over HTTPS) पर लगभग असर नहीं पड़ा, क्योंकि उसका बड़ा हिस्सा cloudflare-dns.com domain पर आधारित है

तकनीकी outage विवरण

1.1.1.1 Resolver service outage

  • 6 जून को DLS के लिए pre-configuration change के दौरान Prefixes error डाली गई
  • 14 जुलाई को test purpose के लिए offline location जोड़ी गई, जिससे network-wide settings refresh हुईं
  • इस प्रक्रिया में 1.1.1.1 Resolver Prefixes दुनिया भर में एक ही offline location तक सीमित हो गए और service withdraw हो गई

तकनीकी कारण विश्लेषण

  • Cloudflare इस समय legacy system और नई strategic system दोनों को साथ चलाता है और address space के हिसाब से routing advertisements को synchronize करता है

  • legacy system में manual updates और deployment की graduality की कमी होने से errors की संभावना अधिक रहती है

    • peer review और दूसरे engineers की review मौजूद थी, लेकिन canary deployment जैसी gradual rollout guarantee करने वाली structure नहीं थी

  • नई पद्धति hardcoding के बजाय topology-centered है, और gradual change rollout तथा monitoring system को अपनाती है

  • 22:01 पर DNS Resolver alert trigger हुआ

  • internal BGP routing table में Resolver routes पूरी तरह गायब पाए गए

  • Prefixes withdraw होने के बाद 1.1.1.0/24 subnet के लिए Tata Communications India(AS4755) ने BGP advertisement की कोशिश की

    • यह अस्थायी Prefix Hijack जैसा दिखा, लेकिन घटना से सीधे तौर पर संबंधित नहीं था

recovery procedure और आगे की कार्रवाई

  • 22:20 UTC पर previous configuration पर rollback और Prefixes की re-advertisement की गई
    • लगभग 77% traffic तुरंत recover हो गया
    • कुछ edge servers अपने-आप reset हो गए, इसलिए manual change management system के जरिए उन्हें फिर से apply करना पड़ा
    • network safety के लिए आमतौर पर gradual rollout किया जाता है, लेकिन इस incident में verification के बाद तेज़ी से लागू किया गया
  • 22:54 पर सभी locations सामान्य स्थिति में लौट आए

भविष्य के सुधार उपाय

  • gradual deployment framework(Stage Deployment) लागू करना: legacy deployment method को हटाना, health-based automatic rollback structure लाना
  • legacy system retirement को तेज़ करना: जोखिमभरी manual configuration और deployment methods हटाना, documentation और test coverage मजबूत करना

निष्कर्ष

Cloudflare 1.1.1.1 DNS Resolver outage internal configuration error के कारण हुआ था, और Cloudflare आगे stability improvement और recurrence prevention measures लागू करने पर पूरा जोर दे रहा है। कंपनी ने customers को हुई असुविधा के लिए माफ़ी मांगी है और भविष्य में ऐसी घटनाओं को न्यूनतम करने के लिए कदम लगातार मजबूत करने की बात कही है।

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

1 टिप्पणियां

 
GN⁺ 2025-07-17
Hacker News राय

  • बहुत से उपयोगकर्ताओं के लिए जब 1.1.1.1 resolver (DNS) काम नहीं करता, तो इसका मतलब होता है कि वे लगभग किसी भी इंटरनेट सेवा तक पहुँच नहीं बना पाते। लेकिन आम तौर पर क्या सभी डिवाइसों में दो DNS सर्वर सेट नहीं होते? क्या दूसरा भी डाउन था, या फिर वह उस पर स्विच क्यों नहीं हुआ, यह जानने की जिज्ञासा है

    • Cloudflare 1.1.1.1 और 1.0.0.1 दोनों को DNS सर्वर के रूप में सेट करने की सिफारिश करता है। लेकिन इस बार outage पैदा करने वाली configuration गलती के कारण 1.1.1.0/24 और 1.0.0.0/24 prefixes दोनों के लिए Cloudflare की BGP announcements रुक गईं
    • Android में Settings-Network & Internet-Private DNS में केवल एक ही "Private DNS provider hostname" दर्ज किया जा सकता है (जहाँ तक मुझे पता है)। और यह IP (1.1.1.1) लेने के बजाय पता (one.one.one.one) ही क्यों माँगता है, यह समझ नहीं आता। DNS सर्वर निर्दिष्ट करते समय IP से सेट करना कहीं ज़्यादा तर्कसंगत लगता है
    • दो को सूचीबद्ध करना, कुछ भी न होने से बेहतर है, लेकिन यह पूरी तरह पर्याप्त नहीं है। अगर एक डाउन हो जाए, तो कौन सा सही काम कर रहा है यह ट्रैक नहीं किया जाता, इसलिए आम तौर पर लंबा latency और बीच-बीच में दिक्कतें देखने को मिलती हैं। जब तक कि आप कई upstreams वाले local caching DNS proxy जैसी उन्नत setup का इस्तेमाल न कर रहे हों
    • अगर आपको लगता है कि आप DNS पर बात कर सकते हैं, तो सलाह है कि खुद सेवा चलाएँ। root domain . दशकों से ठीक चल रहा है, और 1.1.1.1 में समस्या आने की मुख्य वजह DNS खुद नहीं बल्कि anycast है। Cloudflare (और Google आदि) "vanity" IP addresses पर ज़ोर देते हैं—ऐसे IP इस्तेमाल करने के लिए anycast चाहिए, इसलिए असली समस्या DNS नहीं बल्कि anycast है। एक से अधिक providers चुनकर configure करने की सिफारिश है
    • Cloudflare की recommended configuration यह है कि backup server 1.0.0.1 को secondary DNS के रूप में भी रखा जाए, लेकिन इस incident में वह सर्वर भी प्रभावित हुआ

  • लगभग 20 मिनट के outage में 1.1.1.1 का traffic लगभग 20% गिरना दिलचस्प है। हैरानी होती है कि Cloudflare ऐसी साधारण और पुरानी समस्या से बार-बार टकराता रहता है (यह न पहली बार है, न शायद आख़िरी)। Google के 8.8.8.8 और 8.8.4.4 को दुनिया भर में लगभग 10 साल तक (1) एक सेकंड भी downtime नहीं हुआ। (1: कुछ क्षेत्रीय समस्याएँ थीं, लेकिन वह इंटरनेट की वजह से थीं, और Google की दूसरी सेवाओं में गंभीर outage होने पर भी DNS खुद सामान्य रूप से चलता रहा)

    • सिर्फ availability ही नहीं, DNS में speed और privacy भी महत्वपूर्ण हैं। अगर आप यूरोप में हैं, तो यूरोपीय वैकल्पिक DNS सूची से अमेरिकी कंपनियों (CLOUD Act के अधीन) के बजाय विकल्प चुन सकते हैं
    • यह कहना आसान नहीं कि Cloudflare जैसे विशाल और बेहद जटिल network environment में होने वाली engineering समस्याएँ इतनी आसानी से क्यों नहीं सुलझतीं; वास्तविकता यह है कि यह ऐसे मुद्दे हैं जिन्हें उद्योग के केवल 0.001% लोग ही अनुभव करते हैं
    • Cloudflare की incident response culture काफ़ी तर्कसंगत है, लेकिन proactive preventive measures को मज़बूती से बढ़ावा देने वाले incentives की कमी दिखती है
    • बताई गई 20% संख्या का मतलब है कि कुछ clients/resolvers कई बार response fail होने पर अस्थायी रूप से DNS सर्वर को बंद मान लेते हैं, ताकि उपयोगकर्ता को हर request पर 500 बार timeout का इंतज़ार न करना पड़े। लंबे समय में traffic graph पर volume वापस सामान्य हो जाता है
    • इस बात से सहमति है कि बहुत से लोग Google DNS का उपयोग नहीं करना चाहते

  • यह चौंकाने वाला है कि impact detect करने में 5 मिनट से ज़्यादा लग गए (जबकि main protocol traffic 10% तक गिरकर वहीं बना रहा)। मैंने इतने बड़े सिस्टम नहीं चलाए, लेकिन इस स्तर पर तो तुरंत alert की उम्मीद होती। जानना चाहता हूँ कि विशेषज्ञों को भी यह उचित लगता है या नहीं

    • detection speed और false positives के बीच लगातार तनाव रहता है। Nagios, Icinga जैसे monitoring systems आम तौर पर 3 बार लगातार failure होने पर ही event उठाते हैं, क्योंकि transient errors आम हैं। अगर alerts बहुत ज़्यादा आएँ, तो on-call लोग सुन्न पड़ जाते हैं और "थोड़ा इंतज़ार करते हैं" वाला रवैया बढ़ता है। Cloudflare जैसी global service सीधे नहीं चलाई, लेकिन 8 मिनट में reliable detection होना मुझे असामान्य नहीं लगता
    • पुराने NOC (Network Operations Center) की तरह अगर ऐसे graphs दीवार पर लगे होते, तो कोई एक नज़र डालकर "कुछ गड़बड़ है" कहता और तुरंत जुट जाता
    • लगता है कि impact शुरू होते समय service पूरी तरह down नहीं हुई होगी (खासकर अगर यह global rollout की शुरुआत रही हो), इसलिए प्रभाव को measurable बनने में समय लगा होगा
    • 1 मिनट के अंदर alert बजवाने से ज़्यादा यह alert infrastructure की performance test बन जाएगा। असली सवाल है कि क्या हर 1 मिनट पर data collection और calculation वास्तव में स्थिर तरीके से हो सकती है
    • जब metrics aggregation service crash हो जाती है, तो system दोबारा deploy होने तक metrics delay हो सकते हैं और 100% drop जैसा दिख सकता है। अगर 1 मिनट में alert भेज दिया जाए, तो रात 2 बजे अनावश्यक रूप से बहुत लोग जगेंगे, और यह बार-बार होने पर alerts ढीले पड़ते जाते हैं—इसलिए चीज़ें अक्सर 5 मिनट के आसपास tune हो जाती हैं

  • यह एक अच्छा summary post है। यह हिस्सा दिलचस्प है कि DoH (DNS over HTTPS) तक अधिकतर पहुँच cloudflare-dns.com domain के ज़रिए होती है (manual setup या browser में), और IP address न होने की वजह से इस outage का असर तुलनात्मक रूप से कम पड़ा। मैं कल प्रभावित हुआ था; router पर DoH enabled होने के बावजूद कुछ resolve नहीं हो रहा था, और 8.8.8.8 पर बदलते ही समस्या हल हो गई

    • जिज्ञासा है कि DoH वास्तव में कैसे काम करता है। cloudflare-dns.com का IP पता होना चाहिए, और संभव है कि router उसके लिए 1.1.1.1 ही इस्तेमाल कर रहा हो
    • आज एक नया domain सेट कर रहा था, और करीब 20 मिनट तक सिर्फ एक laptop के Firefox से ही पहुँच हो रही थी। Google DNS tool दिखा रहा था कि domain active है, और AWS server से SSH भी हो रहा था, लेकिन मेरे local network पर DNS lookup नहीं हो रहा था। cache flush किया और बहुत कुछ आज़माया, फिर पता चला कि वही Firefox browser अलग से Cloudflare DoH इस्तेमाल करने के लिए configure था
    • मैं सहमत नहीं हूँ। असली root cause को दुरूह शब्दावली में धुंधला कर दिया गया है, जिससे अनुभवी admins भी भ्रमित हो सकते हैं। "legacy" शब्द स्पष्ट नहीं है, बल्कि अधिक abstract और opaque लगता है। "Legacy components gradual deployment approach का उपयोग नहीं करते, और Cloudflare rollback और gradual deployment समर्थित modern approach अपनाएगा"—यह पढ़कर कुछ अंदाज़ा तो लगता है, लेकिन इसे इतना कठिन तरीके से लिखने की क्या ज़रूरत है
    • मेरा Unifi router automatic DoH पर है, और लगता है कि वह Cloudflare और Google दोनों का साथ में उपयोग करता है। मुझे कोई असर महसूस नहीं हुआ, इसलिए या तो Cloudflare DoH चलता रहा या वह तुरंत Google पर स्विच हो गया
    • कुल मिलाकर summary अच्छी है, लेकिन लेख की शुरुआत में दिया गया timeline वाला हिस्सा तथ्यात्मक रूप से सही नहीं है

  • dnsmasq का उपयोग करें तो कई DNS सर्वरों को एक साथ configure करके सबसे तेज़ response देने वाले सर्वर का उपयोग करना संभव है। एक service डाउन हो जाए तब भी लगभग कोई दिक्कत महसूस नहीं होती

    • strict-order setting के बिना all-servers इस्तेमाल करने पर dnsmasq अपने आप सभी servers को retry requests भेजता है। लेकिन अगर systemd-resolved इस्तेमाल कर रहे हों, तो वह केवल क्रम से retry करता है, इसलिए अलग-अलग providers के servers को बारी-बारी से रखना महत्वपूर्ण है। उदाहरण की तरह IPv4 और IPv6 को साथ मिलाने से failover और तेज़ हो सकता है। Quad9 का संबंधित IP default filtering enabled के साथ आता है, जबकि बाकी दो में ऐसा नहीं है, इसलिए उनके resolution results अलग हो सकते हैं। व्यक्तिगत रूप से अगर DNSSEC validation को महत्व देते हैं, तो validating और non-validating resolvers को मिलाना नहीं चाहिए (उदाहरण में दिए गए DNS सभी DNSSEC support करते हैं)
    • अगर मैं नहीं चाहता कि big tech कंपनियाँ (Cloudflare, Google आदि) मेरे सारे DNS records देखें, और DoH भी नहीं चाहता, तो क्या कोई अधिक private setup संभव है? dnsmasq में भरोसेमंद छोटे DNS की सूची इस्तेमाल करना अच्छा लग सकता है, लेकिन हर query कई DNS providers को भेजना बदतमीज़ी तो नहीं, यह सोचता हूँ। privacy-focused स्थिर DNS सूची कहाँ मिलेगी, यह भी पता नहीं
    • कई DNS providers की policies और priorities अलग होती हैं, इसलिए मैं दोनों को एक-दूसरे का विकल्प नहीं मानता। बल्कि एक ही चुनूँगा और ISP के DNS को backup के रूप में रखूँगा
    • systemd-resolved इस्तेमाल करने पर default रूप से DoT और DNSSEC support मिलता है, इसलिए मिलते-जुलते व्यवहार संभव हैं। अगर centralized DNS से पूरी तरह बचना है, तो Tor daemon चलाकर network पर DNS resolver expose किया जा सकता है। कई resolvers भी संभव हैं
    • all-servers setting के बिना भी dnsmasq समय-समय पर हर server पर query race कराता है (default रूप से हर 20 सेकंड में retry)। अचानक outage में भी असर कुछ सेकंड से ज़्यादा नहीं रहना चाहिए

  • अगर outage लगभग 1 घंटे का भी हो, तो यह महीने के हिसाब से 0.13% और साल के हिसाब से 0.0114% होता है। जिज्ञासा है कि Cloudflare इस service पर कौन सा SLO (service level objective) लागू करता है। लिंक मिला, लेकिन वह केवल paid services के लिए है। इस outage के कारण जुलाई availability "< 99.9% but >= 99.0%" श्रेणी में जाएगी, और इस स्थिति में उपयोग शुल्क का 10% refund मिलेगा

    • brand reputation बनाए रखने के लिए शायद यह सालाना 99.9% या उससे ज़्यादा होगा

  • यह दिलचस्प है कि incident के बाद भी traffic पूरी तरह सामान्य पर नहीं लौटा। हाल में OpenWrt के luci-app-https-dns-proxy का उपयोग करके Cloudflare और Google DNS पर एक साथ query भेजता हूँ, और DoH लगभग प्रभावित नहीं हुआ था, इसलिए outage का एहसास नहीं हुआ (अगर DoH भी टूटता तो शायद Google पर auto-switch हो जाता)

    • incident के तुरंत बाद traffic तुरंत recover क्यों नहीं हुआ, इस पर लेख के बाद वाले हिस्से में और चर्चा है। लगता है कुछ servers के लिए सीधा intervention ज़रूरी था
    • outage होने पर अक्सर इंटरनेट ही नहीं चलता, इसलिए लोग कुछ देर के लिए कुछ और करने लगते हैं। अनुमान है कि उस समय बहुत कम लोग DNS provider बदलते होंगे
    • clients DNS lookup results को अस्थायी रूप से cache करते हैं, इसलिए outage के बाद भी कुछ समय तक पुराने values इस्तेमाल हो सकते हैं

  • यह चौंकाने वाला है कि 1.1.1.1 और 1.0.0.1 दोनों एक ही change से प्रभावित हुए। अब DNS backup के लिए पूरी तरह अलग provider इस्तेमाल करना चाहिए लगता है (जैसे 8.8.8.8, 9.9.9.9)

    • दोनों addresses वास्तव में उसी एक service से दिए जाते हैं। उन्हें कभी भी परस्पर स्वतंत्र backups के रूप में advertise नहीं किया गया था
    • DNS का मूल design उद्देश्य सबसे नज़दीकी resolver का उपयोग करना था। कई providers, backbones और regions में विविधता के साथ (और जहाँ संभव हो Anycast addresses से बचते हुए) सही तरह distribute करके इस्तेमाल करना बेहतर है। लेकिन इस मामले में DNS की कार्यप्रणाली के कारण अप्रत्याशित समस्याएँ भी मिल सकती हैं
    • वैसे भी स्थिति हमेशा से ऐसी ही थी
    • मैं पहले से OpenDNS, Quad9 और Cloudflare को मिलाकर दो Pi-hole instances पर configure करके उपयोग कर रहा हूँ। मेरी ज़्यादातर devices उन दोनों Pi-hole को अलग-अलग DNS के रूप में इस्तेमाल करती हैं
    • वास्तव में "DNS backup" जैसी धारणा का कोई ख़ास मतलब नहीं है। ज़्यादातर clients बस किसी एक address को मनमाने ढंग से चुनकर इस्तेमाल करते हैं, और एक के डाउन होने पर अपने-आप दूसरे पर failover नहीं करते। व्यवहार उम्मीद के मुताबिक नहीं होता

  • Cloudflare की internal topology इस तरह विकसित हो रही है कि "legacy" और "strategic" systems sync में रहें। यह लेख तकनीकी और गैर-तकनीकी, दोनों तरह के पाठकों के लिए स्थिति को स्पष्ट रूप से समझाता है। migration process को भी काफ़ी रोचक बना दिया गया है। incident से हुई असुविधा के लिए माफ़ी और आगे सुधार व पुनरावृत्ति रोकने की प्रतिबद्धता प्रभावशाली लगी। ऐसी corporate attitude की काफ़ी सराहना है

    • "legacy" शब्द तकनीकी लोग ज़्यादा इस्तेमाल करते हैं, जबकि "strategic" को marketing या non-technical leaders ज़्यादा इस्तेमाल करते हैं, इसलिए दोनों को मिलाकर उपयोग करने से दोनों पक्षों को उलझन और झुंझलाहट हो सकती है

  • यह आश्चर्यजनक है कि कई engineers ने rebranding की समीक्षा की, फिर भी 1.1.1.0/24 को rerouting list में जोड़ने वाली गलती किसी की नज़र में नहीं आई। सोचता हूँ किस तरह की human error, या दुर्भावना, से यह हुआ होगा। DLS (Domain List Service) में 1.1.1.1/32 और 1.0.0.1/32 को single location के रूप में assign करने से रोकने के लिए hardcoded exception की ज़रूरत लगती है

    • शायद वजह यह रही हो कि "Jerry ने किया है, तो ठीक ही होगा" जैसी भरोसे वाली मानसिकता रही हो
    • मैं आम तौर पर "लोगों को नहीं, tools को दोष" देने की तरफ़ झुकता हूँ। system structure या configuration file generation के तरीके के कारण ऐसी गलतियाँ आसानी से निकल सकती हैं (खासकर अगर diff auto-generated हो)। आखिर code review भी इंसान ही करते हैं, इसलिए इस तरह की failure mode मूलतः process की समस्या है। व्यवहारिक रूप से, बहुत बड़े service outage को रोकने के लिए कई स्तरों पर multiple safeguards वाली defense strategy चाहिए