किसी डोमेन के शीर्ष (उर्फ रूट) पर CNAME रिकॉर्ड का उपयोग क्यों नहीं किया जा सकता है?

Question

यह जोन के एप्स (या जड़ों) में CNAME के ​​बारे में एक कैननिकल प्रश्न है

यह अपेक्षाकृत सामान्य ज्ञान है जो CNAMEएक डोमेन के शीर्ष पर रिकॉर्ड एक वर्जित अभ्यास है।

उदाहरण: example.com. IN CNAME ithurts.example.net.

एक सर्वश्रेष्ठ मामले में नेमसर्वर सॉफ़्टवेयर कॉन्फ़िगरेशन को लोड करने से मना कर सकता है, और सबसे खराब स्थिति में यह कॉन्फ़िगरेशन को स्वीकार कर सकता है और example.com के लिए कॉन्फ़िगरेशन को अमान्य कर सकता है।

हाल ही में मैंने एक वेबहोस्टिंग कंपनी को एक व्यावसायिक इकाई को निर्देश दिए थे, जिसे हमें अपने डोमेन के एपेक्स को एक नए रिकॉर्ड के लिए CNAME की आवश्यकता थी। यह जानते हुए कि यह एक आत्मघाती विन्यास होगा जब BIND को खिलाया जाएगा, मैंने उन्हें सलाह दी कि हम अनुपालन नहीं कर पाएंगे और यह सामान्य रूप से चारपाई सलाह थी। वेबहोस्टिंग कंपनी ने रुख लिया कि यह मानक आरएफसी को परिभाषित करने से मना नहीं है और उनका सॉफ्टवेयर इसका समर्थन करता है। यदि हम एपेक्स को CNAME नहीं कर सकते हैं, तो उनकी सलाह है कि उनके पास कोई भी सर्वोच्च रिकॉर्ड नहीं होगा और वे एक पुनर्निर्देशित वेबसर्वर प्रदान नहीं करेंगे। ...क्या?

हम में से ज्यादातर लोग जानते हैं कि RFC1912 इस बात पर जोर देता है A CNAME record is not allowed to coexist with any other data., लेकिन चलो यहाँ अपने आप से ईमानदार रहें, कि RFC केवल सूचनात्मक है। निकटतम मैं जानता हूँ कि क्रिया को करना मना है जो अभ्यास RFC1034 से है :

यदि CNAME RR नोड पर मौजूद है, तो कोई अन्य डेटा मौजूद नहीं होना चाहिए; यह सुनिश्चित करता है कि एक विहित नाम और उसके उपनामों का डेटा अलग-अलग नहीं हो सकता है।

दुर्भाग्य से मैं उद्योग में लंबे समय से यह जानने के लिए हूं कि "नहीं होना चाहिए" "नहीं होना चाहिए" के समान नहीं है, और यह अधिकांश सॉफ्टवेयर डिजाइनरों के लिए खुद को फांसी देने के लिए पर्याप्त रस्सी है। यह जानते हुए कि एक स्लैम डंक के लिए संक्षिप्त लिंक की कुछ भी कमी मेरे समय की बर्बादी होगी, मैंने कंपनी को दूर करने के लिए एक डांट के साथ दूर करने की अनुमति दी, जो कि बिना उचित प्रकटीकरण के आमतौर पर उपयोग किए गए सॉफ़्टवेयर को तोड़ सकता है।

यह हमें प्रश्नोत्तर में लाता है। एक बार के लिए मैं हमें शीर्ष CNAME के ​​पागलपन के बारे में वास्तव में तकनीकी प्राप्त करना चाहता हूं , और इस मुद्दे पर स्कर्ट नहीं करना चाहिए जैसे हम आमतौर पर किसी विषय पर पोस्ट करते हैं। RFC1912 सीमा से दूर है, क्योंकि यहाँ कोई अन्य सूचनात्मक RFC लागू है जिसके बारे में मैंने नहीं सोचा था। चलो इस बच्चे को बंद कर दें।

Comments

RFC 1034 काफी समय और अनुभव से RFC 2119 की भविष्यवाणी करता है।

— माइकल हैम्पटन

Answer 1

CNAMEरिकॉर्ड मूल रूप से कई नामों की अनुमति देने के लिए बनाए गए थे जो संसाधन के लिए एकल "विहित नाम" के लिए समान संसाधन प्रदान करते हैं। नाम आधारित आभासी होस्टिंग के आगमन के साथ, यह उनके लिए आईपी पते के उपनाम के रूप में उपयोग करने के लिए सामान्य हो गया है। दुर्भाग्य से, एक वेब होस्टिंग पृष्ठभूमि से आने वाले अधिकांश लोग DNS में तुल्यताCNAME को इंगित करने के लिए रिकॉर्ड की उम्मीद करते हैं , जो कि कभी भी इरादा नहीं रहा है। एपेक्स में रिकॉर्ड प्रकार होते हैं जो स्पष्ट रूप से एक कैनोनिकल होस्ट संसाधन ( ; ) की पहचान में उपयोग नहीं किए जाते हैं , जो एक बुनियादी स्तर पर मानक को तोड़ने के बिना उतारा नहीं जा सकता है। (विशेषकर जोन में कटौती के संबंध में )NSSOA

दुर्भाग्य से, मूल डीएनएस मानक को नियंत्रित करने वाले मानकों से पहले लिखा गया था कि यह महसूस किया गया था कि सुसंगत व्यवहार ( आरएफसी 2119 ) को परिभाषित करने के लिए स्पष्ट क्रिया आवश्यक थी । अस्पष्ट शब्दों के कारण कई कोने के मामलों को स्पष्ट करने के लिए RFC 2181 बनाना आवश्यक था , और अद्यतित वर्बेज यह स्पष्ट करता है कि मानक को तोड़े बिना शीर्ष अलियासिंग प्राप्त करने के लिए उपयोग CNAME नहीं किया जा सकता है।

6.1। जोन अथॉरिटी

ज़ोन के लिए आधिकारिक सर्वर को ज़ोन की उत्पत्ति के लिए NS रिकॉर्ड्स में शामिल किया गया है, जो स्टार्ट ऑफ़ अथॉरिटी (SOA) रिकॉर्ड के साथ हर ज़ोन में अनिवार्य रिकॉर्ड है। ऐसा सर्वर एक क्षेत्र में सभी संसाधन रिकॉर्ड के लिए आधिकारिक है जो दूसरे क्षेत्र में नहीं हैं। एनएस रिकॉर्ड जो एक जोन कट का संकेत देते हैं, वे चाइल्ड ज़ोन की संपत्ति हैं, जो उस चाइल्ड ज़ोन की उत्पत्ति के लिए कोई अन्य रिकॉर्ड हैं, या इसके किसी भी उप-डोमेन हैं। एक ज़ोन के लिए एक सर्वर को दूसरे ज़ोन में नामों से संबंधित प्रश्नों के लिए आधिकारिक उत्तर नहीं देने चाहिए, जिसमें NS और शायद A शामिल हैं, एक ज़ोन कट पर रिकॉर्ड करता है, जब तक कि यह दूसरे ज़ोन के लिए एक सर्वर नहीं होता है।

यह स्थापित करता है कि SOAऔर NSरिकॉर्ड अनिवार्य हैं, लेकिन यह कहता है कि Aयहां दिखाई देने वाले या अन्य प्रकार के बारे में कुछ भी नहीं है। ऐसा प्रतीत हो सकता है कि मैं इसे उद्धृत करूं, लेकिन यह एक क्षण में अधिक प्रासंगिक हो जाएगा।

RFC 1034 उन समस्याओं के बारे में कुछ अस्पष्ट था जो CNAMEअन्य रिकॉर्ड प्रकारों के साथ मौजूद होने पर उत्पन्न हो सकती हैं। RFC 2181 अस्पष्टता को हटाता है और स्पष्ट रूप से उन रिकॉर्ड प्रकारों को बताता है जिन्हें उनके साथ मौजूद होने की अनुमति है:

10.1। CNAME संसाधन रिकॉर्ड

DNS CNAME ("कैनोनिकल नाम") रिकॉर्ड किसी अन्य नाम से संबद्ध कैनोनिकल नाम प्रदान करने के लिए मौजूद है। किसी एक उपनाम के लिए केवल एक ही विहित नाम हो सकता है। यह नाम आम तौर पर एक ऐसा नाम होना चाहिए, जो DNS में कहीं और मौजूद हो, हालांकि DNS में अपरिभाषित नाम के साथ उपनाम के साथ कुछ दुर्लभ अनुप्रयोग हैं। एक उपनाम (CNAME रिकॉर्ड का लेबल), यदि DNSSEC उपयोग में है, तो SIG, NXT और KEY RRs हो सकते हैं, लेकिन कोई अन्य डेटा नहीं हो सकता है। यही है, DNS में किसी भी लेबल के लिए (किसी भी डोमेन नाम) वास्तव में निम्न में से एक सच है:

• एक CNAME रिकॉर्ड मौजूद है, वैकल्पिक रूप से SIG, NXT और KEY RR के साथ,
• एक या अधिक रिकॉर्ड मौजूद हैं, कोई भी CNAME रिकॉर्ड नहीं है,
• नाम मौजूद है, लेकिन किसी भी प्रकार का कोई संबद्ध आरआर नहीं है,
• नाम बिल्कुल मौजूद नहीं है।

इस संदर्भ में "उपनाम नाम" CNAMEरिकॉर्ड के बाएं हाथ की ओर है । बुलेट की गई सूची यह स्पष्ट रूप से स्पष्ट करती है कि ए SOA, NSऔर Aरिकॉर्ड को नोड पर नहीं देखा जा सकता है जहां CNAMEयह भी दिखाई देता है। जब हम इसे खंड 6.1 के साथ जोड़ते CNAMEहैं, तो शीर्ष पर मौजूद होना असंभव है क्योंकि इसे अनिवार्य SOAऔर NSरिकॉर्ड के साथ रहना होगा ।

(यह काम करने के लिए लगता है, लेकिन अगर किसी के पास सबूत के लिए एक छोटा रास्ता है, तो कृपया उस पर एक दरार दें।)

---

अपडेट करें:

ऐसा लगता है कि क्लाउडफ़ेयर के हालिया फैसले से एक और अवैध सीएनजी रिकॉर्ड को डोमेन के शीर्ष पर परिभाषित करने की अनुमति देने के निर्णय से आ रहा है , जिसके लिए वे ए रिकॉर्ड को संश्लेषित करेंगे। लिंक किए गए लेख द्वारा वर्णित "आरएफसी अनुपालन" इस तथ्य को संदर्भित करता है कि क्लाउडफेयर द्वारा संश्लेषित रिकॉर्ड DNS के साथ अच्छी तरह से खेलेंगे। यह इस तथ्य को नहीं बदलता है कि यह पूरी तरह से कस्टम व्यवहार है।

मेरी राय में यह बड़े DNS समुदाय के लिए एक असहमति है: यह वास्तव में एक CNAME रिकॉर्ड नहीं है, और यह लोगों को यह विश्वास दिलाने में गुमराह करता है कि अन्य सॉफ्टवेयर इसे अनुमति नहीं देने के लिए कमी है। (जैसा कि मेरा प्रश्न दर्शाता है)

Comments

मैं इस प्रमाण से सहमत हूं और मुझे नहीं लगता कि प्रमाण के इस दो चरण पथ विशेष रूप से लंबे या जटिल हैं। (1. ज़ोन एपेक्स में कम से कम SOA+ NSरिकॉर्ड होने की गारंटी है । 2. CNAMEरिकॉर्ड को अन्य डेटा के साथ सह-अस्तित्व की अनुमति नहीं है)

— हाकन लिंडक्विस्ट

कुल मिलाकर, मुझे लगता है कि यह एक बहुत अच्छी व्याख्या है। अगर कुछ भी जोड़ा जा सकता है, तो मुझे लगता है कि यह संभवतः आगे बताएगा कि CNAMEवास्तव में रिकॉर्ड का क्या मतलब है, क्योंकि यह संभवतः सबसे व्यापक रूप से गलत समझा जाने वाला रिकॉर्ड प्रकार है। भले ही यह उस बिंदु से परे है, लेकिन मुझे लगता है कि यह अक्सर पूछे जाने वाले प्रश्न का एक सीधा परिणाम है, जिसमें से अधिकांश (अधिकांश?) की उचित समझ नहीं है CNAME।

— हाकिन लिंडक्विस्ट

ठीक है यह अवैध है लेकिन क्या इसका कोई मतलब है? CNAME वाले डोमेन को NS और SOA रिकॉर्ड की आवश्यकता क्यों है? और अगर ऐसा होता है, तो यह उनके पास क्यों नहीं है?

— डेनिस होवे

@ डेनिस जिसका बड़े पैमाने पर एक टिप्पणी के भीतर जवाब नहीं दिया जा सकता है। सबसे छोटा उत्तर यह है कि आपको RFC (1034, 1035) को पढ़ने की आवश्यकता है और इस बात की अच्छी समझ है कि रेफरल क्या हैं, रेफरल के लिए आवश्यक व्यवहार क्या हैं (AUTHORITY, SOA रिकॉर्ड उपस्थिति इत्यादि), और इस प्रकार का क्यों "रेफरल-कम" अलियासिंग कार्यात्मक स्तर पर DNS सर्वरों की कई अपेक्षाओं का उल्लंघन करता है। और यह बस के साथ शुरू करने के लिए है। यह प्रश्न यहाँ के लिए एक अच्छा विषय नहीं है क्योंकि यह सट्टा है और इस समस्या में निहित नहीं है कि आप एक ठीक से डिज़ाइन किए गए मानकों के अनुरूप काम कर रहे हैं, जो DNS सर्वर का अनुपालन करता है।

— एंड्रयू बी

@Ekevoo वन SRVइसके बजाय अपनाए गए HTTP कार्यान्वयन को तर्क दे सकता है , जिसने इसे गैर-मुद्दा भी बनाया होगा। यहाँ जो चर्चा की गई है, वह समस्या सीमित नहीं है; CNAMEलोकप्रिय धारणा के विपरीत, जो आवश्यक है उसके लिए एक महान मैच नहीं है। अंत में, जैसा CNAMEकि लोगों की अपेक्षा के अनुरूप काम नहीं करता है!) और इसे पुन: डिज़ाइन नहीं किया जा सकता है और जैसा कि HTTP कार्यान्वयन का उपयोग नहीं करते हैं, SRVयह अधिक संभावना नहीं लगती है कि "alias" शैली की कार्यक्षमता HTTP को पूरा करने के लिए अधिक प्रचलित हो जाती है (रिकॉर्ड प्रकार विशिष्ट अलियासिंग को दृश्य रिकॉर्ड प्रकार के बजाय पर्दे के पीछे लागू किया गया है

— हाकन लिंडक्विस्ट

Answer 2

इंटरनेट सिस्टम कंसोर्टियम ने हाल ही में CNAME पर एक ज़ोन के शीर्ष पर एक राइट-अप पोस्ट किया है , यह प्रतिबंध क्यों मौजूद है, और कई विकल्प हैं। यह किसी भी समय जल्द ही बदलने की संभावना नहीं है, दुख की बात है:

हम यह नहीं बदल सकते हैं कि एक ही समय में दुनिया में सभी DNS सर्वर कार्यान्वयन को बदलने के बिना विशेष CNAME रिकॉर्ड का उपयोग कैसे किया जाता है। ऐसा इसलिए है क्योंकि इसका अर्थ और व्याख्या डीएनएस प्रोटोकॉल में कड़ाई से परिभाषित किया गया था; सभी मौजूदा DNS क्लाइंट और सर्वर कार्यान्वयन इस विनिर्देश का पालन करते हैं। '' आराम '' का प्रयास कैसे CNAME आधिकारिक सर्वर में एक साथ उपयोग किए बिना सभी DNS रिज़ॉल्वर को वर्तमान में बदलने के बिना किया जाता है, जिससे नाम रिज़ॉल्यूशन टूट जाएगा (और वेब और ईमेल सेवाएँ उन संगठनों के लिए उपलब्ध नहीं हैं जो 'आराम से' अधिकृत सर्वर समाधान लागू कर रहे हैं।

लेकिन उम्मीद है:

वर्तमान में चर्चा किए जा रहे एक अन्य संभावित समाधान में एक नया डीएनएस संसाधन रिकॉर्ड प्रकार जोड़ा जाएगा जो कि ब्राउज़र देखेंगे, जो कि शीर्ष पर मौजूद हो सकता है। यह http अनुरोधों के लिए एक एप्लिकेशन-विशिष्ट होस्टनाम होगा (एमएक्स काम करने के तरीके के समान)।

पेशेवरों: यह डीएनएस डिजाइन के साथ पूरी तरह से संगत है।
विपक्ष: यह अभी तक उपलब्ध नहीं है, और इसके लिए ब्राउज़र क्लाइंट अपडेट की आवश्यकता होगी।

Comments

"आशा है कि"? पहले से ही एक "समाधान" था, यानी HTTP एसआरवी रिकॉर्ड, लेकिन ये सार्वभौमिक रूप से खारिज कर दिए गए थे। स्पष्ट नहीं है कि "समस्या" क्या है।

— माइकल हैम्पटन

मुझे HTTP SRV के बारे में भी जानकारी नहीं थी, इसलिए मुझे कोई सुराग नहीं है कि इसे अस्वीकार क्यों किया गया। उम्मीद है कि यह संभावित नया समाधान जब भी / यदि सामने आता है, तो बेहतर स्वागत होता है।

— डैनियल लियुज़ी

Answer 3

यदि आप पूरे क्षेत्र को पुनर्निर्देशित कर रहे हैं, तो आपको DNAME का उपयोग करना चाहिए। RFC 6672 के अनुसार ,

DNAME RR और CNAME RR [RFC1034] एक संभावित डोमेन नाम से भिन्न डोमेन नाम से संबंधित डेटा को संभावित रूप से देखने का कारण बनते हैं। दो संसाधन रिकॉर्ड के बीच का अंतर यह है कि CNAME RR अपने मालिक के डेटा की खोज को किसी अन्य एकल नाम पर निर्देशित करता है, जबकि DNAME RR अपने मालिक के नाम के वंशजों के डेटा के लिए एक अलग (एकल) नोड के तहत संबंधित नामों को देखता है। पेड़।

उदाहरण के लिए, डोमेन नाम "foo.example.com" के लिए एक ज़ोन (RFC 1034 [RFC1034], खंड 4.3.2, चरण 3 देखें) और एक DNAME संसाधन रिकॉर्ड "example.com" पर पाया जाता है। "example.com" के अंतर्गत सभी क्वेरीज़ को "example.net" पर निर्देशित किया जाएगा। लुकअप प्रक्रिया "foo.example.net" के नए क्वेरी नाम के साथ चरण 1 पर वापस आ जाएगी। यदि क्वेरी का नाम "www.foo.example.com" था, तो नया क्वेरी नाम "www.foo.example.net" होगा।

Comments

यह एक गलत व्याख्या है। RFC 6672 .2.2 में तालिका की दूसरी पंक्ति देखें । एक एपेक्स DNAME एपेक्स में DNAME के ​​अलावा अन्य क्वेरी प्रकारों के लिए कोई मैच नहीं होगा, जिसका परिणाम एपेक्स ए या AAAA रिकॉर्ड के वास्तविक एलियासिंग में नहीं होता है।

— एंड्रयू बी

एक शीर्ष DNAME के ​​परिणामस्वरूप शीर्ष नाम के प्रश्नों का कोई पुनर्निर्देशन नहीं होगा । यह कहना है कि यह कोई में परिणाम देंगे तकनीकी रूप से सही नहीं है मैच । यदि आप NS, SOA, या किसी अन्य RR प्रकार जो वास्तव में शीर्ष नाम के लिए मौजूद हैं, के लिए क्वेरी करने पर भी आपको एक मैच मिलेगा । से आरएफसी 6672 : "एक DNAME रिकॉर्ड क्षेत्र शीर्ष पर मौजूद न हो, वहाँ अभी भी प्रथागत SOA और एन एस संसाधन रिकॉर्ड वहाँ रूप में अच्छी तरह के लिए एक की जरूरत है इस तरह के एक DNAME करने के लिए इस्तेमाल नहीं किया जा सकता। दर्पण , पूरी तरह से एक क्षेत्र के रूप में यह नहीं है ज़ोन एपेक्स को मिरर करें। "

— क्क्सप्लसोन डेस