- 8 जनवरी 2026 को Cloudflare की 1.1.1.1 सेवा अपडेट ने DNS response के भीतर रिकॉर्ड क्रम बदल दिया, जिससे दुनिया भर के कुछ उपयोगकर्ताओं के लिए DNS resolution failure हुआ
- समस्या की जड़ वह कोड बदलाव था जिसमें CNAME रिकॉर्ड A/AAAA रिकॉर्ड के पीछे चला गया, जबकि कुछ DNS client implementations रिकॉर्ड क्रम पर निर्भर थे
- खास तौर पर glibc के
getaddrinfo फ़ंक्शन और Cisco switch के DNSC process प्रभावित हुए, और बाद वाले मामले में reboot loop तक हुआ
- RFC 1034 केवल इतना कहता है कि “CNAME पहले आ सकता है(possibly preface)”, इसलिए रिकॉर्ड क्रम के लिए कोई स्पष्ट मानक मौजूद नहीं है
- Cloudflare ने CNAME को हमेशा पहले रखने वाली व्यवस्था पर वापसी की और स्पष्ट मानक परिभाषा के लिए IETF को Internet-Draft जमा किया
1. घटना का सार
- 8 जनवरी 2026 को 1.1.1.1 का memory usage कम करने वाला अपडेट deploy किया गया, जिससे DNS response के भीतर रिकॉर्ड क्रम में बदलाव हुआ
- यह बदलाव 2 दिसंबर 2025 को codebase में जोड़ा गया, 10 दिसंबर को test environment में deploy हुआ, और 7 जनवरी 2026 को global release शुरू हुई
- 8 जनवरी को 18:19 UTC पर incident घोषित किया गया, 18:27 पर rollback शुरू हुआ, और 19:55 पर recovery पूरी हुई
- अधिकांश आधुनिक DNS client response के भीतर रिकॉर्ड क्रम को अनदेखा करते हैं, लेकिन कुछ implementations यह मानकर चलते हैं कि CNAME हमेशा पहले आना चाहिए
- जैसे ही यह क्रम बदला, कुछ clients ने response को खाली मान लिया और resolution failure हुआ
2. CNAME chain और cache का व्यवहार
- डोमेन query के समय, उदाहरण के लिए
www.example.com कई CNAME chain से होकर अंतिम IP पर resolve होता है
- उदाहरण:
www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
- हर CNAME लिंक का अपना TTL(Time-To-Live) होता है, और इनमें से केवल कुछ ही expire हो सकते हैं
- 1.1.1.1 केवल expired हिस्सों को फिर से query करता है और मौजूदा cache तथा नए रिकॉर्ड को merge करके response बनाता है
3. कोड बदलाव का विवरण
- पुराने कोड में CNAME chain को पहले insert किया जाता था, और उसके बाद A/AAAA रिकॉर्ड जोड़े जाते थे
answer_rrs.extend_from_slice(&self.records); // CNAMEs first
- बदले हुए कोड में CNAME को अंत में जोड़ा गया
entry.answer.extend(self.records); // CNAMEs last
- इसके कारण response के भीतर CNAME नीचे चला गया, और कुछ clients इसे संभाल नहीं पाए
4. प्रभावित implementations के उदाहरण
- glibc का
getaddrinfo फ़ंक्शन response को क्रमवार parse करता है, इसलिए CNAME का पहले आना ज़रूरी होता है ताकि वह अगले नाम को follow कर सके
- अगर CNAME बाद में आता है, तो “expected name” update नहीं होता और परिणाम खाली रह जाता है
- Cisco Catalyst switch के 3 models का DNSC process भी प्रभावित हुआ, और 1.1.1.1 इस्तेमाल होने पर fatal error के साथ reboot loop हुआ
- Cisco ने इससे संबंधित service document प्रकाशित किया
5. जो implementations प्रभावित नहीं हुईं
- systemd-resolved response को OrderedSet structure के रूप में parse करता है, इसलिए CNAME की position से स्वतंत्र होकर पूरे set को खोज सकता है
- इसलिए रिकॉर्ड क्रम बदलने पर भी यह सामान्य रूप से काम करता रहा
6. RFC 1034 की अस्पष्टता
- RFC 1034 (1987) कहता है कि “response को एक या अधिक CNAME से preface किया जा सकता है”
- लेकिन इसमें MUST/SHOULD जैसे normative keywords नहीं हैं, इसलिए यह स्पष्ट requirement नहीं है
- RFC 2119 (1997) के बाद ही ऐसे keywords standardize हुए, इसलिए उस समय के दस्तावेज़ में स्पष्ट अनिवार्य भाषा नहीं थी
- Cloudflare ने शुरुआती implementation में CNAME को पहले रखा था, लेकिन tests के माध्यम से इसकी गारंटी नहीं दी गई थी
7. RRset और message section का अंतर
- RFC 1034 §3.6 स्पष्ट करता है कि RRset (एक ही name·type·class वाले रिकॉर्ड का set) के भीतर क्रम महत्वपूर्ण नहीं है
- लेकिन अलग-अलग RRset के बीच क्रम के बारे में कोई उल्लेख नहीं है
- §6.2.1 का उदाहरण भी एक ही name के दो A रिकॉर्ड तक सीमित है, और CNAME तथा A के सापेक्ष क्रम पर बात नहीं करता
- इसलिए CNAME और A रिकॉर्ड के बीच क्रम की परिभाषा खाली जगह बनी हुई है
8. CNAME chain के भीतर क्रम की समस्या
- अगर CNAME कई चरणों वाला हो, तो chain का अपना क्रम बिगड़ने पर भी क्रमवार parsing विफल हो सकती है
- उदाहरण: अगर
cdn.example.com CNAME server.cdn-provider.com पहले आ जाए, तो www.example.com CNAME cdn.example.com नहीं मिल पाता
- RFC 1034 में CNAME chain के क्रम के लिए भी कोई requirement नहीं है
9. resolver के व्यवहार का मानदंड
- RFC 1034 §5.2.2 कहता है कि “resolver को CNAME मिलने पर नए नाम के साथ query फिर से शुरू करनी चाहिए”
- लेकिन यह पूरे resolver (जैसे 1.1.1.1) के लिए दिया गया विवरण है,
glibc जैसे stub resolver इस logic को implement नहीं करते
- नतीजतन कुछ stub resolver RFC द्वारा अपेक्षित व्यवहार का पालन नहीं करते
10. DNSSEC की स्पष्ट शर्तों से तुलना
- RFC 4035 (DNSSEC) RRSIG रिकॉर्ड शामिल करने की प्राथमिकता को “MUST” के रूप में स्पष्ट करता है
- हालांकि यह “शामिल करना है या नहीं” पर नियम है, “क्रम” पर नहीं
- DNSSEC स्पष्ट inclusion rules देता है, लेकिन unsigned zones में RFC 1034 की अस्पष्टता अब भी बनी रहती है
11. Cloudflare का निष्कर्ष और कार्रवाई
- RFC के अनुसार CNAME क्रम अनिवार्य नहीं है, लेकिन कुछ clients इसे पूर्वधारणा मानते हैं, इसलिए
CNAME को हमेशा पहले रखने की नीति पर वापसी की गई
- भविष्य में ऐसी समस्या रोकने के लिए IETF को Internet-Draft जमा किया गया
- Cloudflare ने इस घटना से यह पुष्टि की कि 40 साल पुराने protocol की अस्पष्टता आज भी वास्तविक सिस्टमों को प्रभावित करती है
12. अतिरिक्त जानकारी
- Cloudflare, 1.1.1.1 सहित Connectivity Cloud के माध्यम से
enterprise network protection, internet-scale application acceleration, DDoS defense, और Zero Trust implementation support प्रदान करता है
- मुफ्त 1.1.1.1 app के ज़रिए ज़्यादा तेज़ और सुरक्षित इंटरनेट access संभव है
अभी कोई टिप्पणी नहीं है.