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


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

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

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

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

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

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

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

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

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


107
2017-07-19 10:53


मूल


आरएफसी 1034 काफी समय और अनुभव से आरएफसी 2119 का अनुमान लगाता है। - Michael Hampton♦


जवाब:


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

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

6.1। जोन प्राधिकरण

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

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

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

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

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

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

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

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


अद्यतन करें:

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

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


85
2017-07-19 10:53



मैं इस सबूत से सहमत हूं और मुझे नहीं लगता कि सबूत का यह दो चरण पथ विशेष रूप से लंबा या शांत है। (1. ज़ोन एपेक्स कम से कम होने की गारंटी है SOA + NS रिकॉर्ड, 2। CNAME रिकॉर्ड को अन्य डेटा के साथ सह-अस्तित्व की अनुमति नहीं है) - Håkan Lindqvist
कुल मिलाकर, मुझे लगता है कि यह एक बहुत अच्छी व्याख्या है। अगर कुछ भी जोड़ा जा सकता है, तो मुझे लगता है कि यह संभवतः आगे बताएगा कि क्या CNAME वास्तव में रिकॉर्ड का मतलब है, क्योंकि शायद यह सबसे व्यापक रूप से गलत प्रकार का गलत रिकॉर्ड है। भले ही यह बिंदु से परे है, मुझे लगता है कि यह एक एफएक्यू है, कई लोगों का सीधा परिणाम है (अधिकांश?) की उचित समझ नहीं है CNAME। - Håkan Lindqvist
@ डेनिस जिसे किसी टिप्पणी के भीतर व्यापक रूप से उत्तर नहीं दिया जा सकता है। सबसे छोटा जवाब यह है कि आपको आरएफसी (1034, 1035) को पढ़ने की जरूरत है और रेफ़रल के बारे में अच्छी समझ है, रेफ़रल के लिए आवश्यक व्यवहार क्या हैं (प्राधिकरण, एसओए रिकॉर्ड उपस्थिति, आदि), और इस प्रकार का "रेफ़रल-कम" एलियासिंग कार्यात्मक स्तर पर DNS सर्वर की कई अपेक्षाओं का उल्लंघन करता है। और यह बस शुरू करने के लिए है। यह प्रश्न यहां के लिए एक अच्छा विषय नहीं है क्योंकि यह सट्टा है और किसी समस्या में जड़ नहीं है जिसे आप एक उचित ढंग से डिज़ाइन किए गए, मानकों के अनुरूप DNS सर्वर के साथ काम करना चाहते हैं। - Andrew B
@ डेनिस हाउ संक्षिप्त रूप से: एनएस और एसओए रिकॉर्ड के बिना "एक डोमेन" जैसी कोई चीज़ नहीं है। वे गैर-वैकल्पिक रिकॉर्ड हैं। - hakamadare
@Ekevoo कोई तर्क दे सकता है कि HTTP कार्यान्वयन को अपनाया जाना चाहिए था SRV इसके बजाय, यह भी एक गैर-मुद्दा बना दिया होगा। यहां पर चर्चा की गई समस्या तक सीमित नहीं है; CNAME लोकप्रिय धारणा के विपरीत, आवश्यकतानुसार एक महान मैच नहीं है। अंत में, के रूप में CNAME लोगों की अपेक्षा नहीं करता है (!) और पूर्ववत रूप से फिर से डिजाइन नहीं किया जा सकता है और क्योंकि HTTP कार्यान्वयन का उपयोग नहीं किया जाता है SRV ऐसा लगता है कि "उपनाम" शैली कार्यक्षमता HTTP को पूरा करने के लिए अधिक प्रचलित हो जाती है (दृश्य प्रकार विशिष्ट एलियासिंग दृश्यमान दृश्य प्रकार के बजाय दृश्यों के पीछे लागू) - Håkan Lindqvist


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

डीएनएन आरआर और सीएनएन आरआर [आरएफसी 1034] एक लुकअप का कारण बनता है      (संभावित रूप से) डोमेन नाम से संबंधित डेटा वापस अलग करें      पूछे गए डोमेन नाम से। दोनों के बीच का अंतर      संसाधन रिकॉर्ड यह है कि सीएनएन आरआर डेटा के लुकअप को निर्देशित करता है      इसका मालिक दूसरे नाम पर है, जबकि एक डीएनएन आरआर लुकअप को निर्देशित करता है      अपने मालिक के नाम के वंशजों के आंकड़ों के लिए इसी नाम पर डेटा के लिए      पेड़ के एक अलग (एकल) नोड के नीचे।

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


0
2018-03-27 15:41



यह एक गलत व्याख्या है। तालिका की दूसरी पंक्ति का संदर्भ लें आरएफसी 6672 §2.2। एक शीर्ष DNAME के ​​परिणामस्वरूप शीर्ष पर DNAME के ​​अलावा क्वेरी प्रकारों के लिए कोई मिलान नहीं होगा, यानी परिणामस्वरूप शीर्ष ए या एएएए रिकॉर्ड का वास्तविक अलियासिंग नहीं होता है। - Andrew B
एक शीर्ष डीएनएन परिणामस्वरूप नहीं होगा पुनर्निर्देशन शीर्ष नाम के प्रश्नों के लिए। तकनीकी रूप से यह कहना सही नहीं है कि इसका नतीजा होगा मैच। यदि आप एनएस, एसओए, या वास्तव में किसी अन्य आरआर प्रकार के लिए पूछते हैं तो आपको अभी भी एक मैच मिल जाएगा वर्तमान शीर्ष नाम के लिए। से आरएफसी 6672: "यदि ज़ोन शीर्ष पर एक डीएनएन रिकॉर्ड मौजूद है, तो वहां भी परंपरागत एसओए और एनएस संसाधन रिकॉर्ड होने की आवश्यकता है। ऐसे डीएनएन का उपयोग नहीं किया जा सकता आईना एक क्षेत्र पूरी तरह से, जैसा कि यह नहीं करता है आईना ज़ोन एपेक्स। " - Quuxplusone