संक्षिप्त जवाब
DNS ऑपरेशन को नियंत्रित करने वाले मानकों की आवश्यकता है कि सभी उपकरणों का मिलान PTR रिकॉर्ड हो? नहीं।
क्या कुछ प्रोटोकॉल के मानकों के लिए ऐसे PTRरिकॉर्ड की आवश्यकता होती है जो संगत Aया AAAAरिकॉर्ड से सहमत हों ? हाँ।
क्या RFC द्वारा संचालित कुछ एप्लिकेशन की आवश्यकताएं समान नहीं हैं? हाँ।
क्या CNTR में PTR रिकॉर्ड हो सकता है? हां, लेकिन CNAME लक्ष्य को प्रश्न में डिवाइस का अद्वितीय नाम होना चाहिए (और अन्य CNAME नहीं)। ( RFC 2181 R10.2 , RFC1034 .23.6.2 )
क्या PTR रिकॉर्ड बनाना एक सर्वोत्तम अभ्यास है? आमतौर पर ऐसा माना जाता है, लेकिन इसकी अपनी समस्याएं हैं।
लंबा जवाब
यह प्रश्नोत्तर एक आम गलतफहमी को दूर करने में मदद करने के इरादे से प्रदान किया जाता है।
का एक दुखद अंत underquoted अनुभाग RFC1796 यहाँ लागू होता है:
यह एक अफसोसजनक रूप से अच्छी तरह से फैली भ्रांति है कि RFC के रूप में प्रकाशन कुछ स्तर की मान्यता प्रदान करता है। यह नियमित पत्रिका में प्रकाशन से कम से कम या अधिक नहीं है। वास्तव में, प्रत्येक RFC के पास इंटरनेट मानकीकरण प्रक्रिया के साथ अपने संबंध के सापेक्ष एक स्थिति है: सूचनात्मक, प्रायोगिक, या मानक ट्रैक (प्रस्तावित मानक, ड्राफ्ट मानक, इंटरनेट मानक), या ऐतिहासिक।
RFC1912 सूचनात्मक है। RFC1033 स्पष्ट रूप से लेबल और के एक अधिकारी पदनाम है नहीं है अज्ञात जो यह इतना पुराना है कि इसका मतलब है, यह कुछ भी के लिए एक संदर्भ नहीं माना जाना चाहिए । वे मानकों को परिभाषित नहीं करते हैं, न ही उन्हें आधिकारिक तौर पर एक मानक बढ़ाने के लिए इस्तेमाल किया जा सकता है। उन्हें कभी भी इस संदर्भ में उद्धृत नहीं किया जाना चाहिए कि वे एक मानक को परिभाषित कर रहे हैं।
सूचनात्मक आरएफसी सुझावों को अच्छी सलाह के रूप में सोचें और आमतौर पर सर्वोत्तम अभ्यास स्वीकार किए जाते हैं। रिवर्स डीएनएस सिफारिशें एक नज़र में समझ में आती हैं: इन दिशानिर्देशों का पालन करने से उन स्थितियों में डालने का जोखिम कम होता है जहां कोई एप्लिकेशन काम करने में विफल रहता है क्योंकि रिवर्स डीएनएस आवश्यक नहीं था और इसके लिए योजना नहीं बनाई गई थी। आप निश्चित रूप से एक DNS व्यवस्थापक से अपेक्षा नहीं कर सकते हैं कि वह हर उस एप्लिकेशन / प्रोटोकॉल को जान सके जिसकी उसे आवश्यकता है, और दुख की बात यह है कि उन रिकॉर्ड्स का अनुरोध करने वाले सेवा स्वामियों का भी यही हाल है।
कहा कि, बहुत अच्छा स्वचालन के बाहर , अनिवार्य PTR रिकॉर्ड निर्माण नीतियां भी प्रदूषण पैदा करती हैं।
- यह
PTRरिकॉर्ड के लिए अत्यंत सामान्य है कि उपकरणों के समान A/ AAAAरिकॉर्ड के साथ तालमेल न रखा जाए, क्योंकि उपकरणों का PTRसमय के साथ बोगस डेटा का रेंगना हो जाता है। यह डेटा केवल उन लोगों को गुमराह करने का काम करता है जो उस जानकारी को विश्वसनीय मानते हैं। जब वे प्रेत समस्या का कारण बन रहे होते हैं, तो कुछ अनुप्रयोग मालिक उस पर कूदने के लिए उत्सुक होते हैं। समस्या केवल तब तक खराब होती रहेगी क्योंकि IPv6 को अपनाना अधिक सामान्य हो जाता है, विशेष रूप से वाहक आकार के IP स्पेस के लिए जिम्मेदार DNS व्यवस्थापक के लिए।
- एक ही आईपी पते के लिए कई पीटीआर रिकॉर्ड होना बहुत बेकार है, और सूचनात्मक आरएफसी की सलाह का पालन करना अनिवार्य रूप से इसका परिणाम होगा। देखें: DNS में एकाधिक PTR रिकॉर्ड की सिफारिश क्यों नहीं की जाती है?
क्या बदतर है: एक पीटीआर रिकॉर्ड की अनुपस्थिति, या एक गलत पीटीआर रिकॉर्ड? यदि एक प्रोटोकॉल टूट जाता है क्योंकि इसके मानक के लिए वैध DNS की आवश्यकता होती है, तो दोनों खराब हैं, और बाद वाला वास्तव में बदतर हो सकता है । उसके बाहर, हर किसी की बात पर अलग राय है। यह ठीक है: आप उन नीतियों और उपकरणों को एक साथ रखने के लिए स्वतंत्र हैं जो आपकी टीम और कंपनी के लिए सबसे अच्छा काम करते हैं। बस सुनिश्चित करें कि वे लगातार परिणाम देते हैं और पैदावार करते हैं, और याद रखें कि रिवर्स डीएनएस केवल उतना ही सटीक होगा जितना समय और अनुशासन आपके टीम के सदस्यों को देना होगा।
लेकिन गुम PTR रिकॉर्ड के कारण sshd लटक जाते हैं!
यह भी सच नहीं है। लोग अक्सर एक PTR रिकॉर्ड (NXDOMAIN) का अभाव है, और के बीच की रेखा को भ्रमित टूट रिवर्स DNS।
NXDOMAINयदि आप एक ऐसी सेवा के साथ संचार कर रहे हैं जो आगे की पुष्टि के लिए रिवर्स DNS (FCrDNS) की आवश्यकता होती है, तो एक उत्तर का कारण होगा। मेल सर्वर, केर्बरोस, ओरेकल स्कैन वीआईपी, आदि।
ब्रोकन रिवर्स DNS वह है जब आपके लिए NXDOMAINसमय पर फैशन में प्रतिक्रिया प्राप्त करना असंभव है । कई अनुप्रयोग (सबसे प्रसिद्ध sshd) रिवर्स डीएनएस लुकअप पर ब्लॉक कर देंगे यदि समय पर फैशन में अपस्ट्रीम स्रोतों से प्रतिक्रिया प्राप्त करने में समस्याएं हैं, जिससे एप्लिकेशन के भीतर देरी हो सकती है।
sshdधीरे-धीरे जवाब देने के विशिष्ट मामले को अंदर डालकर बचा जा सकताUseDNS noहैsshd_config। (लेकिन भले ही आप उस समस्या के आसपास काम कर सकते हैं जो अभी भी स्वीकार्य नहीं है, अगर DNS समय से उलट हो या सर्वर विफलता प्रतिक्रिया उत्पन्न करे।)