RFC 2782 के उल्लंघन में CNAME उर्फ़ की ओर इशारा करते हुए SRV रिकॉर्ड प्रकाशित?

कुछ कार्य जिम्मेदारियों के दौरान मुझे एसआरवी रिकॉर्ड्स पर हड्डी लगाने की आवश्यकता होती है, और मैं डीएनएस के साथ एक विकिपीडिया बयान को समेटने की कोशिश कर रहा हूं जो मैं डीएनएस में देख रहा हूं।

विकिपीडिया के SRV रिकॉर्ड प्रविष्टि के अनुसार ,

SRV रिकॉर्ड्स में लक्ष्य पता रिकॉर्ड (A या AAAA रिकॉर्ड) के साथ होस्टनाम को इंगित करना चाहिए। CNAME रिकॉर्ड के साथ होस्टनाम की ओर इशारा करना एक मान्य कॉन्फ़िगरेशन नहीं है।

लेकिन मैं उन रिकॉर्ड्स को देखता हूँ जहाँ digएक SRV रिकॉर्ड एक नाम की ओर इशारा करता है जो CNAME रिकॉर्ड में अन्य नाम है।

यह कुछ इस तरह है:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

ऐसा लगता है कि एसआरवी रिकॉर्ड ठीक उसी तरह कॉन्फ़िगर किया गया है जिस तरह से विकिपीडिया प्रविष्टि कहता है कि अनुमति नहीं है। मुझे क्या गलतफहमी है? क्या यह नहीं दिखा रहा है कि SRV रिकॉर्ड alias.domain.com पर इंगित करता है, जिसमें CNAME रिकॉर्ड है, पता रिकॉर्ड नहीं है?

domain-name-system cname-record srv-record

— स्कॉट
स्रोत

मेरी कंपनी में हम SRV रिकॉर्ड का उपयोग करते हैं, और उनमें से अधिकांश CNAME का उपयोग कर रहे हैं और यह ठीक काम करता है, इसलिए नियमों के खिलाफ या नहीं, यह अच्छी तरह से काम करता है :)

— olivierg

जवाबों:

विकिपीडिया लेख जो आप रिपोर्ट कर रहे हैं कि SRV रिकॉर्ड के लिए प्रासंगिक RFC 2782 क्या है:

लक्ष्य

लक्ष्य होस्ट का डोमेन नाम। इस नाम के लिए एक या एक से अधिक पता रिकॉर्ड होना चाहिए, नाम जरूरी नहीं एक उपनाम होना चाहिए (RFC 1034 या RFC 2181 के अर्थ में)।

आप जो देख रहे हैं वह नियमों का स्पष्ट उल्लंघन है; हालाँकि, यह काम कर सकता है (और यह आमतौर पर होता है), यदि जो भी क्लाइंट एप्लिकेशन उस एसआरवी रिकॉर्ड को देख रहा है वह एक CNAME रिकॉर्ड को ठीक से संभालने के लिए पर्याप्त स्मार्ट है, भले ही वह केवल प्रतिक्रिया में ए रिकॉर्ड की उम्मीद कर रहा हो।

लेकिन यह भी काम नहीं कर सकता है : यह असमर्थित है और पूरी तरह से ग्राहक के आवेदन पर निर्भर है; इस प्रकार इसे टाला जाना चाहिए, क्योंकि यह उचित नियमों का पालन नहीं कर रहा है और गलत और / या अप्रत्याशित परिणाम हो सकता है।

यह CNAME के लिए MX रिकॉर्ड को इंगित करने के समान है, जिसे न केवल एक , बल्कि दो RFC में गलत के रूप में परिभाषित किया गया है , और फिर भी यह काफी सामान्य अभ्यास है (और कोई मेल सर्वर को इसके साथ कोई समस्या नहीं है)।

— मास्सिमो
स्रोत

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

— एंड्रयू बी

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

— मासिमो

एप्लिकेशन को बहुत स्मार्टनेस की आवश्यकता नहीं है, यह बस 4443 पोर्ट पर "alias.domain.com" से कनेक्ट करने के लिए ओएस से पूछेगा और इसके लिए सभी विवरण छोड़ देगा।

— मासिमो

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

— एंड्रयू बी

कुछ मेल सर्वरों ने सक्रिय रूप से एमएक्स को CNAMEs में अनदेखा करना शुरू कर दिया, जैसे GMX medienconsulting.at/…

— Marcel Waldvogel

यह प्रतिबंधित व्यवहार का एक उदाहरण है, हाँ। प्रतिबंध स्वयं "लक्ष्य" की परिभाषा में RFC 2781 से आता है :

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

डीएनएस सर्वर सॉफ्टवेयर निषिद्ध विन्यास की अनुमति देना दुर्भाग्य से नया नहीं है। यह हो सकता है और होता है, जैसा कि अन्य रिकॉर्ड प्रकारों के साथ होता है, जहां अलियास लक्ष्य जैसे NSऔर निषिद्ध हैं MX। (उपर्युक्त)

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

संक्षेप में, मानक से चिपके रहें। यह केवल सुरक्षित चीज है।

— एंड्रयू बी
स्रोत