सार्वजनिक, निजी, स्थिर और समर्पित स्वतंत्र पता गुण हैं। एक परिनियोजन मैप बनाएँ जो रूटिंग, फ़ायरवॉल, फ़ॉरवर्ड DNS, रिवर्स DNS और TLS को भी कवर करे, और प्रत्येक सेटिंग को उस पक्ष के साथ सत्यापित करें जो उसे नियंत्रित करता है।
पता गुण भिन्न प्रश्नों के उत्तर देते हैं
सार्वजनिक और निजी बताते हैं कि किसी पते को कहाँ रूट किया जाना है। स्थिर और गतिशील बताते हैं कि कोई असाइनमेंट समय के साथ कैसे व्यवहार करता है। समर्पित और साझा बताते हैं कि किसी सेवा के भीतर पता कैसे उपयोग या आवंटित किया जाता है। ये अलग-अलग गुण हैं: एक स्थिर सार्वजनिक पता कई साइटों की सेवा कर सकता है, और एक निजी पता नियंत्रित नेटवर्क के भीतर गतिशील रूप से असाइन किया जा सकता है।
परिनियोजन में प्रत्येक पते की भूमिका लिखें: सार्वजनिक प्रवेश बिंदु, आंतरिक डेटाबेस, प्रबंधन मार्ग या आउटबाउंड कनेक्शन। फिर पहचानें कि इसे कौन असाइन करता है और क्या बदल सकता है। यह कॉन्फ़िगरेशन कार्य को इस धारणा पर निर्भर होने से रोकता है कि समर्पित का अर्थ स्थायी रूप से निश्चित है या सार्वजनिक का अर्थ सेवा पहुँच योग्य है। पहुँच रूटिंग, फ़ायरवॉल और एप्लिकेशन के लिसनर पर भी निर्भर करती है।
निजी एड्रेसिंग को अभी भी रूटिंग और एक्सेस नियंत्रण की आवश्यकता होती है
RFC 1918 निजी नेटवर्क के लिए IPv4 श्रेणियाँ 10.0.0.0/8, 172.16.0.0/12 और 192.168.0.0/16 आरक्षित करता है। उनके पते विश्व स्तर पर अद्वितीय सार्वजनिक गंतव्य नहीं हैं। एक नेटवर्क आउटगोइंग कनेक्शनों के लिए निजी पतों का अनुवाद कर सकता है या स्पष्ट मार्गों के माध्यम से निजी नेटवर्क जोड़ सकता है। अनुवाद के पीछे एक इनबाउंड सेवा को जानबूझकर प्रकाशन विधि की आवश्यकता होती है; अकेले DNS रिकॉर्ड बदलना वह मार्ग नहीं बनाता।
IPv6 के अपने पता प्रकार और स्कोप हैं, जिनमें लिंक-लोकल एड्रेसिंग और विश्व स्तर पर रूटेबल यूनिकास्ट पते शामिल हैं। इसे अलग से समीक्षा करें, बजाय यह मानने के कि कोई IPv4 फ़ायरवॉल या अनुवाद नियम IPv6 को कवर करता है। एक निजी पता प्रमाणीकरण तंत्र नहीं है, और एक सार्वजनिक IPv6 पता हर सेवा को उजागर करने का कारण नहीं है। प्रत्येक प्रासंगिक नेटवर्क से एक्सेस का परीक्षण करें और उपयुक्त सीमा पर प्रशासन को प्रतिबंधित करें।
स्थिर नाम और स्थिर पते संबंधित हैं
DHCP एक प्रोटोकॉल के माध्यम से पता कॉन्फ़िगरेशन आवंटित करता है और लीज़ का उपयोग कर सकता है। गतिशील रूप से असाइन किया गया पता कुछ समय तक अपरिवर्तित रह सकता है; यह उसकी स्थायित्व को संविदात्मक गारंटी नहीं बनाता। जब कोई एप्लिकेशन स्थिर पते पर निर्भर करता है, तो कल के कनेक्शन से अनुमान लगाने के बजाय प्रदाता की असाइनमेंट और परिवर्तन नीति को सत्यापित करें।
गतिशील DNS पता बदलने के बाद नाम अपडेट कर सकता है, लेकिन क्लाइंट अभी भी पिछला उत्तर कैश कर सकते हैं। यह अगम्य लिसनर, अनुपस्थित इनबाउंड मार्ग या कैरियर-ग्रेड पता अनुवाद को भी पार नहीं कर सकता। इसका उपयोग तब करें जब नेटवर्क कनेक्शन की अनुमति देता है और एप्लिकेशन अपडेट विलंब सहन करता है। होस्ट किए गए परिनियोजन के लिए, इसके आसपास allowlist या बाहरी एकीकरण बनाने से पहले इच्छित पता जीवनचक्र का दस्तावेज़ीकरण करें।
| गुण | क्या पुष्टि करें | सामान्य गलत धारणा |
|---|---|---|
| सार्वजनिक या निजी | रूटिंग स्कोप और एक्सेस पथ | अकेला पता सेवा को पहुँच योग्य बना देता है |
| स्थिर या गतिशील | असाइनमेंट और परिवर्तन नीति | अपरिवर्तित लीज़ स्थायी होती है |
| समर्पित या साझा | आवंटन और अनुमत उपयोग | समर्पित पता अनाम पहचान प्रदान करता है |
| IPv4 या IPv6 | रूटिंग और फ़ायरवॉल दोनों कॉन्फ़िगरेशन | एक प्रोटोकॉल की सेटिंग्स दूसरे को कवर करती हैं |
फ़ॉरवर्ड DNS और रिवर्स DNS के स्वामी भिन्न होते हैं
फ़ॉरवर्ड DNS नामों को A और AAAA पता रिकॉर्ड जैसे डेटा से मैप करता है। रिवर्स DNS पता-संबंधित नेमस्पेस और PTR रिकॉर्ड का उपयोग करके पते को नाम से जोड़ता है। फ़ॉरवर्ड DNS ज़ोन को नियंत्रित करने वाला संगठन आवश्यक रूप से पता श्रेणी के लिए रिवर्स DNS को नियंत्रित करने वाला संगठन नहीं होता। रिवर्स नाम का वादा करने से पहले सही कॉन्फ़िगरेशन पथ प्राप्त करें।
उपयुक्त रिज़ॉल्वर के माध्यम से रिकॉर्ड जाँचें और परिणाम रिकॉर्ड करें। होस्ट की पहचान करने के इच्छित PTR के लिए, यह भी जाँचें कि संबंधित फ़ॉरवर्ड रिकॉर्ड अपेक्षित पते की ओर इंगित करता है या नहीं। रिवर्स DNS परिचालन पहचान और कुछ मेल-सिस्टम जाँचों का समर्थन कर सकता है, लेकिन यह किसी एप्लिकेशन को प्रमाणित नहीं करता या संदेश वितरण की गारंटी नहीं देता। मेल भेजने के लिए अपने स्वयं के डोमेन, प्रतिष्ठा और प्रमाणीकरण समीक्षा की भी आवश्यकता होती है।
हर HTTPS साइट के लिए समर्पित पता आवश्यक नहीं है
HTTP होस्ट रूटिंग और TLS Server Name Indication एक्सटेंशन समर्थित क्लाइंट और सर्वर को नाम से साइट या प्रमाणपत्र चुनने देते हैं। इसलिए कई HTTPS साइटें एक पते का उपयोग कर सकती हैं, बिना प्रति डोमेन एक सार्वजनिक पता आवश्यक किए। वास्तविक होस्टिंग कॉन्फ़िगरेशन और आवश्यक क्लाइंट निर्धारित करते हैं कि वह व्यवस्था उपयुक्त है या नहीं।
अतिरिक्त पता तभी चुनें जब कोई प्रलेखित आवश्यकता इसकी माँग करे, जैसे समर्थित नेटवर्क पृथक्करण या कोई बाहरी सिस्टम जो अलग एंडपॉइंट की अपेक्षा करता है। पता प्रतिष्ठा समस्याओं से उन्मुक्ति या सेवा संचालित करने वाले व्यक्ति की पहचान प्रदान नहीं करता। प्रमाणपत्र, होस्टनेम रूटिंग और पता आवंटन को अलग-अलग जाँच के रूप में रखें। उपयोगकर्ताओं द्वारा वास्तव में विज़िट किए जाने वाले होस्टनेम के माध्यम से परोसे गए प्रमाणपत्र को सत्यापित करें।
रिकॉर्ड बदलने से पहले परिनियोजन मैप का उपयोग करें
प्रत्येक होस्टनेम, पता रिकॉर्ड, लिसनर, फ़ायरवॉल पथ और जिम्मेदार पक्ष वाला एक छोटा मैप बनाएँ। प्रशासन, बैकअप और किसी भी आउटबाउंड allowlist को शामिल करें। जाँचें कि SwissOctet कॉन्फ़िगरेशन आपके आवश्यक पता विकल्प को सूचीबद्ध करता है या नहीं और उस पर निर्भर होने से पहले रिवर्स DNS नियंत्रण के बारे में पूछें। कैटलॉग विकल्पों को पहले से प्रावधानित लाइव असाइनमेंट के रूप में प्रस्तुत न करें।
स्थानांतरण के दौरान, उपयोगकर्ताओं को वहाँ निर्देशित करने से पहले गंतव्य एप्लिकेशन और TLS सेटिंग्स तैयार करें। DNS कैश का ध्यान रखें और एक व्यावहारिक रिकवरी पथ बनाए रखें। फ़ॉरवर्ड रिज़ॉल्यूशन, वास्तविक एप्लिकेशन पहुँच और अपेक्षित रिवर्स नाम को अलग-अलग सत्यापित करें। मैप विफलताओं का पता लगाना आसान बनाता है क्योंकि गलत रिकॉर्ड, बंद पोर्ट और बेमेल प्रमाणपत्र अलग-अलग समस्याएँ हैं जिनके अलग-अलग स्वामी हैं।
आपकी व्यावहारिक चेकलिस्ट।
- पता भूमिका, असाइनमेंट और स्वामित्व को मैप करें।
- IPv4 और IPv6 को अलग-अलग जाँचें।
- DNS पर निर्भर होने से पहले इनबाउंड रूटिंग सत्यापित करें।
- पहचानें कि PTR रिकॉर्ड कौन नियंत्रित करता है।
- होस्टनेम, प्रमाणपत्र और एप्लिकेशन का एक साथ परीक्षण करें।
महत्वपूर्ण विवरण।
क्या समर्पित IP सेवा को अनाम बनाता है?+
नहीं। यह आवंटन या उपयोग व्यवस्था का वर्णन करता है, पहचान या गोपनीयता गारंटी का नहीं। खातों, ट्रैफ़िक और एप्लिकेशन डेटा के अलग-अलग निहितार्थ होते हैं।
क्या मैं अपने डोमेन के DNS पैनल से PTR रिकॉर्ड सेट कर सकता हूँ?+
केवल तभी जब वह प्रासंगिक रिवर्स ज़ोन को भी नियंत्रित करता हो। पता प्रदाता सामान्यतः उस ज़ोन को नियंत्रित करता है या अलग अनुरोध प्रक्रिया प्रदान करता है।
क्या प्रत्येक HTTPS डोमेन को अपना पता चाहिए?+
आवश्यक नहीं। समर्थित क्लाइंट और सर्वर नाम-आधारित रूटिंग और TLS SNI का उपयोग कर सकते हैं। वास्तविक होस्टिंग और क्लाइंट आवश्यकताओं को सत्यापित करें।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- RFC 1918: निजी इंटरनेट के लिए पता आवंटन www.rfc-editor.org
- RFC 2131: Dynamic Host Configuration Protocol www.rfc-editor.org
- RFC 1035: DNS कार्यान्वयन और विनिर्देश www.rfc-editor.org
- RFC 4291: IPv6 एड्रेसिंग आर्किटेक्चर www.rfc-editor.org
- RFC 6066: TLS एक्सटेंशन, जिनमें Server Name Indication शामिल है www.rfc-editor.org
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।