क्या CNAME पहले आता है, या A रिकॉर्ड पहले?

• 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 जमा किया गया
  • दस्तावेज़: draft-jabley-dnsop-ordered-answer-section
  • लक्ष्य: DNS response में CNAME handling क्रम का स्पष्ट standardization
• 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 संभव है

[GN⁺]

Hacker News की राय

• मुझे लगा RFC की भाषा इतनी अस्पष्ट नहीं है
  “possibly preface” का मतलब ऐसे पढ़ा जाता है कि “अगर CNAME record है, तो उसे पहले जोड़ा जाता है”, न कि “चाहें तो उसे कहीं भी जोड़ सकते हैं”

  • मैं भी ऐसा ही सोचता हूँ। “prefix किया जा सकता है” का मतलब यह नहीं कि “suffix भी किया जा सकता है”
    लेकिन यह सिर्फ़ वाक्य की व्याख्या का मामला नहीं है; असली बात यह है कि दुनिया के सबसे महत्वपूर्ण DNS servers में से एक चलाने वाली टीम ने CNAME response logic बदल दी
    यह टेस्ट में साफ़ तौर पर टूटा होगा, फिर भी किसी ने “क्या यह order महत्वपूर्ण है?” नहीं पूछा, यह हैरानी की बात है
    Cloudflare हाल के समय में समस्याओं को काफ़ी पारदर्शिता से साझा करता है, लेकिन यह मामला “मज़ेदार तथ्य साझा करना” जैसा लगता है
    इतने बड़े सिस्टम में ऐसी चीज़ का टेस्ट पास कर जाना काफ़ी बड़ी गलती लगता है
  • लेख में बताया गया है कि अस्पष्टता एक दूसरे वाक्य से आती है — “response section में RR order का अंतर महत्वपूर्ण नहीं है”
    क्योंकि उदाहरण को सामान्यीकृत किया जा सकता है, इसलिए इसे “हर मामले में order मायने नहीं रखता” के रूप में ग़लत समझा जा सकता है
    आख़िरकार, एक व्यक्ति की “स्पष्ट समझ” दूसरे व्यक्ति को “क्या आपने दस्तावेज़ पूरा पढ़ा?” जैसी लग सकती है
    यह मामला normative language के महत्व को दिखाता है
  • आपको लग सकता है कि यह अस्पष्ट नहीं है, लेकिन व्यवहार में यह अस्पष्ट था, और इसे सुधारने की कोशिशें भी हुई थीं
    संबंधित चर्चा IETF mailing list में देखी जा सकती है
  • मैं भी आपकी राय से सहमत हूँ। RFC के उदाहरण 6.2.1 की व्याख्या ग़लत लगती है
    “order का अंतर महत्वपूर्ण नहीं है” का मतलब सिर्फ़ उस खास उदाहरण में है, न कि सामान्य नियम को नज़रअंदाज़ करना
    कहा जाता है कि RFC 1034 ने RRset को परिभाषित किया, लेकिन वास्तव में ऐसी कोई term definition वहाँ नहीं है
    Cloudflare की व्याख्या अपवाद को सामान्य नियम समझ लेने जैसी लगती है
    हालाँकि CNAME chain के order पर स्पष्ट नियम नहीं है, इसलिए उस हिस्से में थोड़ी अस्पष्टता फिर भी बची रहती है
  • लेख में इसका ज़िक्र भी है। यह इस बात की ओर इशारा करता है कि RFC वह दस्तावेज़ है जो normative words (MUST, SHOULD) के standardize होने से पहले लिखा गया था

• यह मामला ऐसा लगता है जहाँ Hyrum’s Law और Postel’s Law एक साथ काम कर रहे थे
  “अगर API के users काफ़ी ज़्यादा हों, तो सिस्टम के हर observable behavior पर कोई न कोई निर्भर हो जाएगा” और
  “जो भेजो उसमें conservative रहो, जो पाओ उसमें liberal रहो” — इन दोनों सिद्धांतों का टकराव है

  • लेकिन अब Postel’s Law को धीरे-धीरे हानिकारक सिद्धांत माना जाने लगा है
  • सही है, लेकिन Hyrum’s Law का मूल बिंदु यह है कि दुनिया में अनगिनत edge cases मौजूद हैं
    इस बार मुद्दा यह है कि glibc का resolver टूट गया — यह कोई दुर्लभ स्थिति नहीं है
    असली खबर यह है कि Cloudflare ने ठीक से टेस्ट नहीं किया
  • अंत में यह इंसानी स्तर की leaky abstraction की समस्या है
  • xkcd comic है जो Hyrum’s Law को बिल्कुल सही ढंग से दिखाती है

• इस bug ने मुझे पुरानी याद दिला दी
  2011 में जब Cloudflare ने RFC को नज़रअंदाज़ करके domain apex पर CNAME की अनुमति दी थी
  उस समय की blog post में लिखा था कि “RFC वगैरह को छोड़कर वास्तविक समस्या हल करेंगे”
  लेकिन CNAME name-level alias की अवधारणा है, इसलिए apex पर रखने से NS, MX, SOA caching टूट जाती है
  उस समय कई engineers ने चेतावनी दी थी, लेकिन रुख़ “move fast and break things” वाला था
  फिर भी इस बार CNAME chain और A record order को इतने बारीक स्तर पर देखना प्रगति ही है

  • आपकी बात से सहमत हूँ। पुराने BIND में “cannot have CNAME and other data” error अनगिनत बार देखा है
    CNAME और alias की अवधारणा लंबे समय से भ्रम पैदा करती रही है, और RFC1034 की non-normative language ने उस भ्रम को और बढ़ाया
    यह उसी तरह की जमा हुई अस्पष्टता का नतीजा है, लेकिन फिर भी किसी बड़े service provider का ऐसी गलती करना स्वीकार करना मुश्किल है
  • लेकिन अगर specification को जानबूझकर तोड़ा गया हो, तो क्या उसे सच में “bug” कहा जा सकता है?
    मुझे तो लगता है कि specification खुद ही समस्या थी

• यह चौंकाने वाला है कि glibc का सामान्य DNS lookup record order पर निर्भर करता है
  हैरानी है कि 20 साल से ज़्यादा समय तक इससे कोई बड़ा मुद्दा नहीं हुआ
  शायद ज़्यादातर DNS operators ने टेस्टिंग के दौरान अनुभव से सीख लिया होगा कि order मायने रखता है

  • शायद इस तरह की समस्या अक्सर हुई होगी, लेकिन छोटे पैमाने की services में यह बस नज़रअंदाज़ हो गई होगी
    Cloudflare की तरह जब इसका असर दुनिया भर के लाखों devices पर पड़ा, तब यह ध्यान में आया
    हालाँकि यह जानना दिलचस्प होगा कि क्या Cloudflare ने glibc जैसे open source resolvers को patch भेजा है
  • server side पर order बनाए रखना आम बात थी, और जो servers ऐसा नहीं करते थे उन्हें compatibility issues के कारण जल्दी ठीक कर दिया जाता था
    CNAME वाकई संभालने में मुश्किल चीज़ है (DJB के notes देखें)
  • इंटरनेट वास्तव में कुछ मुख्य authoritative server implementations पर निर्भर है, इसलिए सबने लगभग वही order rules अपनाए
  • अगर order constraint हटाना है, तो DNS names को तेज़ी से lookup करने वाला data structure चाहिए
    glibc जैसे साधारण resolvers में cache नहीं होती, इसलिए इसे लागू करने के लिए बड़े code changes चाहिए होंगे

• Cloudflare का यह कहना कि “RFC CNAME order की मांग नहीं करता” शब्दों में नुक़्ताचीनी जैसा लगता है
  सिर्फ़ इसलिए कि “MUST” नहीं है, यह मान लेना कि “कोई भी order चलेगा” ज़बरदस्ती की व्याख्या है
  गलती मान लेना और आगे बढ़ जाना दुनिया को बेहतर बनाता है
  भाषाई बहस से ज़िम्मेदारी टालना उल्टा भरोसा कम करता है

• लगता है Cloudflare ने RFC1034 को ठीक से नहीं समझा
  उनके DNS interface में अगर CNAME है तो A, AAAA को रोका जाता है, लेकिन दूसरे records की अनुमति रहती है
  इसलिए जब CNAME और TXT साथ मौजूद होते हैं, तो cache-dependent results आते हैं
  internet.nl में भी ऐसी समस्या मिली थी
  कुछ users ने mxtoolbox guide देखकर setup किया, लेकिन यह RFC1034 से टकराता है

  • वह guide शायद दो अलग-अलग explanations को मिला देती है
    एक है “DMARC service को CNAME के ज़रिए delegate कैसे करें”, और दूसरी “इसे सीधे host कैसे करें”
    लगता है screenshot ने भ्रम पैदा किया

• Cloudflare का आख़िरकार इस निष्कर्ष पर पहुँचना कि “CNAME को दूसरे records से पहले आना चाहिए” तर्कसंगत है

  • मुझे भी यह निष्कर्ष अच्छा लगा। चाहे सब ग़लत हों, कभी-कभी हक़ीक़त के हिसाब से चलना पड़ता है

• कंपनी में DNS manage करते हुए मैंने DNS की कई सीमाएँ महसूस की हैं
  खासकर जब SERVFAIL होता है, तो client यह नहीं समझ पाता कि समस्या किस server में है
  नतीजतन, कई DNS servers और cache layers बेकार की retry storm पैदा कर देते हैं
  इसके अलावा search path ग़लत domains पर बार-बार NXDOMAIN queries भेजता रहता है

  • मैंने भी ऐसा ही अनुभव किया है। एक दिन से ज़्यादा समय तक सिर्फ़ caching server को देखते रहे, लेकिन आख़िर में समस्या authoritative server की निकली
  • BIND 9 में इसे कम करने के लिए servfail-ttl option है
    RFC2308 section 7.1 के अनुसार SERVFAIL responses को cache करना अनुमत है
    standard पुराना है, लेकिन तरीका अब भी वैध है

• Cloudflare अक्सर standards तोड़ता है, और फिर उसे सही ठहराने के लिए नया RFC लिखता है
  RFC 8482 जैसी चीज़ें उद्योग के लिए कलंक लगती हैं
  “इस बार भी भ्रम रोकने के लिए नया Internet-Draft submit किया” — यह बात विडंबनापूर्ण लगती है

• 1.1.1.1 जैसे बड़े DNS server के लिए glibc जैसे वास्तविक resolvers को शामिल करने वाले integration tests होने चाहिए
  फिर भी यह सवाल है कि ऐसी समस्या सिर्फ़ production में ही क्यों सामने आई

  • शायद यह सिर्फ़ उस दुर्लभ combination में हुआ होगा जहाँ cache expiry order बिगड़ने के बाद glibc फिर से query करता है
    अलग-अलग tests पास हो गए होंगे, लेकिन दोनों शर्तें साथ आने वाला case छूट गया होगा