DNS में एक NS में एक CNAME बिंदु हो सकता है?

Question

क्या एक NS रिकॉर्ड को CNAME होना चाहिए? उदाहरण के लिए:

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A   10.1.1.1

यह बाइंड में काम नहीं करता है, हालांकि यह (निश्चित रूप से) करता है:

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A   10.1.1.1

इस सेटअप को प्रतिबंधित करने वाले RFC के लिए किसी भी संकेत की सराहना की जाएगी।

Answer 1

NS RR ( RFC1035 ) को परिभाषित करने वाला वास्तविक RFC केवल यह कहता है कि यह RR- प्रकार के लक्ष्य को निर्दिष्ट किए बिना एक डोमेन-नाम है (हालांकि यह स्पष्ट करता है कि यह IP नहीं हो सकता)। यह RFC1912 में विशिष्ट उल्लेख प्राप्त करता है , हालांकि खंड 2.4:

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

काफी जरूरी नहीं है, लेकिन यह निश्चित रूप से आपके द्वारा देखे जा रहे व्यवहार पर फिट बैठता है

Comments

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

— लार्क्स 19

मैंने पाया कि RFC 2181 10.3 स्पष्ट रूप से कहता है कि यह अमान्य है लेकिन आपका उत्तर काफी अच्छा था।

— मार्क वैगनर

अतिरिक्त स्पष्टता के लिए: MUST NOTक्रिया यहाँ मायने नहीं रखती क्योंकि RFC 1912 सूचनात्मक है और एक मानक को परिभाषित नहीं करता है। मार्क सही है कि RFC 2181 सही संदर्भ है। (RFC 1034 भाषा के मानकों के ठोस होने से पहले लिखा गया था, इसलिए अस्पष्टता)

— एंड्रयू बी