निजी नेटवर्क के लिए शीर्ष स्तर डोमेन / डोमेन प्रत्यय?


115

हमारे कार्यालय में, हमारे पास एक स्थानीय क्षेत्र नेटवर्क है जो विशुद्ध रूप से आंतरिक डीएनएस सेटअप के साथ है, जिस पर क्लाइंट सभी के रूप में नामित हैं whatever.lan। मेरे पास एक VMware पर्यावरण है, और वर्चुअल-मशीन-ओनली नेटवर्क पर, मैं वर्चुअल मशीन का नाम देता हूं whatever.vm

वर्तमान में, वर्चुअल मशीनों के लिए यह नेटवर्क हमारे स्थानीय क्षेत्र नेटवर्क से उपलब्ध नहीं है, लेकिन हम इन वर्चुअल मशीनों को स्थानांतरित करने के लिए एक उत्पादन नेटवर्क स्थापित कर रहे हैं, जो लैन से पहुंच योग्य होगा । परिणामस्वरूप, हम डोमेन प्रत्यय / TLD के लिए एक कन्वेंशन पर समझौता करने की कोशिश कर रहे हैं जो हम इस नए नेटवर्क पर मेहमानों के लिए लागू कर रहे हैं जिसे हम सेट कर रहे हैं, लेकिन हम एक अच्छा साथ नहीं दे सकते, जो कि .vm, .localऔर .lanहमारे वातावरण में सभी मौजूदा धारणाएं हैं।

तो, इस स्थिति में सबसे अच्छा अभ्यास क्या है? क्या TLDs या डोमेन नामों की एक सूची है जो शुद्ध आंतरिक नेटवर्क के लिए उपयोग करना सुरक्षित है?


2
.Local का उपयोग न करें। खासकर अगर आपको कोई Apple क्लाइंट मिला है।
रेनियरट

2
.test को इस कारण से अलग रखा गया है: Secure.wikimedia.org/wikipedia/en/wiki/.test
CWSpear

1
@CWSpear यह वास्तविक कारण .test आरक्षित नहीं है, हालांकि यह परीक्षण नेटवर्क के लिए उपयोग करने के लिए एक सुरक्षित डोमेन बनाता है जो इंटरनेट से जुड़ा नहीं होगा।
voretaq7

10
@Otto सर्वोत्तम अभ्यास यह तय करेंगे कि आप "वास्तविक" डोमेन नाम (ICANN से मान्यता प्राप्त TLD के तहत) प्राप्त करें और अपने स्थानीय सामान के लिए उस का उपडोमेन बनाएं (जैसे रजिस्टर mydomain.com, internal.mydomain.comएक आंतरिक एनएस को सौंपते हैं , और विभाजित हॉरर DNS को ठीक से कॉन्फ़िगर करते हैं ( BIND में "देखे गए" तो आप इंटरनेट पर आंतरिक नाम / पते लीक नहीं करते हैं। यह TLD / pseudo-TLD की तरह सुंदर नहीं है, लेकिन इसके टूटने की संभावना कम है क्योंकि यह आपके नियंत्रण में है।
voretaq7

9
हालाँकि : एक वास्तविक डोमेन नाम का उपयोग न करें जो आपने पहले ही सार्वजनिक-सामना करने वाली उत्पादन सेवाओं के लिए उपयोग किया है। विभिन्न इंटरैक्शन हैं जिनके बीच अनुमति दी जाती है www.example.comऔर *.internal.example.comजिनके बीच अनुमति नहीं है www.example.comऔर *.example.net, सबसे विशेष रूप से क्रॉस-साइट कुकी सेटिंग। एक ही डोमेन पर आंतरिक और बाहरी सेवाओं को चलाने से यह जोखिम बढ़ जाता है कि एक सार्वजनिक सेवा का समझौता आंतरिक सेवाओं को कुछ प्रभावित करेगा, और इसके साथ ही एक असुरक्षित आंतरिक सेवा बाहरी सेवा के आंतरिक दुरुपयोग को भी भड़का सकती है।
बॉब

जवाबों:


94

एक आविष्कृत TLD का उपयोग न करें। अगर आईसीएएनएन इसे सौंप देता, तो आप बड़ी मुसीबत में पड़ जाते। एक ही बात अगर आप किसी अन्य संगठन के साथ विलय करते हैं जो एक ही डमी टीएलडी का उपयोग करने के लिए होता है। यही कारण है कि विश्व स्तर पर अद्वितीय डोमेन नाम पसंद किए जाते हैं।

मानक, RFC 2606 के नाम उदाहरण, प्रलेखन, परीक्षण के लिए हैं, लेकिन सामान्य उपयोग के लिए और अच्छे कारणों के लिए कुछ भी नहीं है: आज, एक वास्तविक और अद्वितीय डोमेन नाम प्राप्त करना इतना आसान और सस्ता है कि उपयोग करने का कोई अच्छा कारण नहीं है डमी एक।

इसलिए, iamthebest.orgइसे खरीदने और अपने उपकरणों के नाम के लिए उपयोग करें।


53
पूरी तरह से सुरक्षित होने के लिए मैं सब कुछ अपनी कंपनी के डोमेन नाम के उपडोमेन पर रखूँगा, जैसे local.company.org, vm.company.org, इत्यादि।
जुन्न

4
+1 यह। संभवतः आपकी कंपनी के पास पहले से ही एक डोमेन है। बस इसमें से एक उप-डोमेन बनाएं। इसे आपके LAN के बाहर दिखाई / resolvable होना आवश्यक नहीं है।
डैन कार्ली

3
ठीक है, यहां तक ​​कि बहुत अच्छे वकीलों के साथ, आपको ट्रेडमार्क आमंत्रित करके ".lan" या ".local" का दावा करने में परेशानी होगी। और तर्क "यह केवल आंतरिक है" बेहद कमजोर है: संगठन विलय करते हैं, साथी संगठनों के साथ आभासी निजी नेटवर्क स्थापित करते हैं और बस ऐसी गलतियां करते हैं कि "निजी" नाम लीक हो जाते हैं।
बोर्त्ज़मेयर

8
इसके साथ मेरा एकमात्र बीफ यह है कि आप वास्तव में एक डोमेन "नहीं" खरीद सकते हैं: आप केवल एक किराए पर ले सकते हैं। कुछ बोजो बिल का भुगतान करना भूल जाते हैं (और यह कुछ हाई-प्रोफाइल मामलों में हुआ है) और आपके कॉन्फ़िगरेशन का एक मुख्य हिस्सा कुछ यादृच्छिक स्क्वैटर में जाता है। तो आप अपनी कंपनी के डोमेन का उपयोग करें? Execs रीब्रांड करने या खरीदने के लिए तय करते हैं, और आप एक पुराने नाम के साथ फंस गए हैं। .Local काफी अच्छी तरह से काम करता था, लेकिन अब इसे एक निश्चित कंपनी द्वारा उन तरीकों से पूर्वनिर्धारित किया गया है जो अच्छा खेलने से इनकार करते हैं। मैं वास्तव में ऐसा कुछ देखना चाहूंगा। इस उद्देश्य के लिए .lan या .internal औपचारिक रूप से आरक्षित है, लेकिन तब तक यह सबसे अच्छा विकल्प है।
जोएल कोएल

6
@ योएल कोएल के साथ सहमत हैं, आप एक किराएदार हैं, और कुछ भी नहीं है। आंतरिक उपयोग के लिए केवल दो आरक्षित TLD नाम होने चाहिए, जिन्हें सार्वजनिक रूप से अमान्य माना जाना चाहिए और सार्वजनिक नेटवर्क द्वारा उपलब्ध नहीं होना चाहिए। एक नाम आंतरिक घरेलू उपयोग के लिए होगा, दूसरा नाम आंतरिक व्यावसायिक उपयोग के लिए होगा। दोनों को एक ही अर्थ में "निजी TLDs" माना जाएगा कि हमारे पास "निजी सबनेट" हैं जो गैर-रूटेबल (192.168.xx और ilk) हैं। यह घर उपयोगकर्ताओं को .local और mDNS में मजबूर होने के अलावा कुछ करने की अनुमति देता है। किसी भी डोमेन के साथ NAT के पीछे एक आंतरिक LAN चलाने वाले छोटे व्यवसायों के लिए Ditto।
ऐवे पायने

49

आंतरिक मशीनों के लिए अपनी कंपनी के पंजीकृत डोमेन के उप-डोमेन का उपयोग करें, जिनके नाम आप इंटरनेट पर उपलब्ध नहीं चाहते हैं। (फिर, ज़ाहिर है, केवल उन नामों को अपने आंतरिक DNS सर्वर पर होस्ट करें।) यहाँ काल्पनिक उदाहरण निगम के लिए कुछ उदाहरण दिए गए हैं।

इंटरनेट का सामना करना पड़ सर्वर:
में www.example.com को
mail.example.com
dns1.example.com

आंतरिक मशीनें:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

मैंने "कॉर्प" का उपयोग यह बताने के लिए किया कि इस उप-डोमेन ने आंतरिक कॉरपोरेट नेटवर्क पर मशीनों का वर्णन किया है, लेकिन आप यहां कुछ भी उपयोग कर सकते हैं, जैसे कि "आंतरिक": client1.internal.example.com।

याद रखें, भी, कि DNS क्षेत्र और उप-डोमेन को आपकी नेटवर्क नंबरिंग योजना के साथ संरेखित करने की आवश्यकता नहीं है। उदाहरण के लिए, मेरी कंपनी के 37 स्थान हैं, प्रत्येक का अपना सबनेट है, लेकिन सभी स्थान समान (आंतरिक) डोमेन नाम का उपयोग करते हैं। इसके विपरीत, आपके पास केवल एक या कुछ सबनेट हो सकते हैं, लेकिन कई सहकर्मी आंतरिक डोमेन या उप-डोमेन के स्तर को आपकी मशीनों को व्यवस्थित करने में आपकी सहायता कर सकते हैं।


32

आंतरिक उप-डोमेन का उपयोग करने का एक और फायदा है: FQDN के बजाय चतुराई से खोज प्रत्यय और केवल होस्टनाम का उपयोग करके, आप कॉन्फ़िगरेशन फ़ाइलों का निर्माण कर सकते हैं जो विकास, क्यूए और उत्पादन दोनों में काम करते हैं।

उदाहरण के लिए, आप हमेशा अपनी कॉन्फ़िगरेशन फ़ाइल में "डेटाबेस = dbserv1" का उपयोग करते हैं।

विकास सर्वर पर, आप खोज प्रत्यय "dev.example.com" => डेटाबेस सर्वर का उपयोग करते हैं: dbserv1.dev.example.com

QA सर्वर पर, आप खोज प्रत्यय "qa.example.com" => डेटाबेस सर्वर का उपयोग करते हैं: dbserv1.qa.example.com

और उत्पादन सर्वर पर, आप खोज प्रत्यय को "example.com" => डेटाबेस सर्वर में उपयोग करते हैं: dbserv1.example.com सेट करें

इस तरह, आप प्रत्येक वातावरण में समान सेटिंग्स का उपयोग कर सकते हैं।


2
यह शानदार है।
क्रिस मैग्नसन

19
जब तक कोई व्यक्ति किसी समस्या का परीक्षण करने के लिए उत्पादन खोज प्रत्यय के साथ अपने कार्य केंद्र को गलत तरीके से कॉन्फ़िगर करता है, और बाद में अनजाने में उत्पादन रिकॉर्ड का एक गुच्छा अपडेट करता है।
जोएल कोएल

1
यह बहुत कच्चा है, एसआरवी रिकॉर्ड पार्स करने के लिए बहुत सरल हैं और इसे किसी भी क्षेत्र के भीतर रखा जा सकता है, जैसे कि एक ही डीबी सर्वर अपने क्षेत्र में कार्य करता है। इस स्थिति में कुछ बिट कोड आपकी कॉन्फिगर फाइल के अंदर वैल्यू भर रहा होगा। और आप SRV कुंजी के रूप में डेटाबेस का नाम और होस्टनाम की ओर इशारा करते हुए पाठ्यक्रम के मूल्य का उपयोग कर सकते हैं। मैं कभी खोज प्रत्यय पर भरोसा नहीं करता। आप TXT रिकॉर्ड के साथ भी काफी रचनात्मक हो सकते हैं, और यदि वे रहस्य हैं तो उन्हें एईएस 256 एनक्रिप्टेड (तब बेस 64 एनकोडेड) मानों के साथ भर सकते हैं। आप सभी प्रकार की चीजों के लिए TXT रिकॉर्ड का उपयोग कर सकते हैं।
अंजीर

देखें, लेकिन मैं क्या चाहता हूँ example.com, example.dev और example.stg है। अंतिम 2 केवल एक निजी नेटवर्क पर हैं, क्या मैं शून्य कॉन्फ़िगर एक्सेस के लिए स्थानीय DNS सर्वर सेटअप कर सकता हूं? अभी भी सभी साइटों के लिए यहां एक समान कॉन्फ़िगरेशन का उपयोग करके, बस परिवर्तन tld तक बढ़ रहा है। होस्ट फ़ाइल के साथ .dev के लिए आसान, लेकिन शून्य कॉन्फिगरेशन ...
DigitalDesignDj

14

चूँकि इस प्रश्न के पिछले उत्तर लिखे गए थे, इसलिए RFC के कुछ जोड़े आए हैं जिन्होंने मार्गदर्शन को कुछ हद तक बदल दिया है। RFC 6761 निजी नेटवर्क के लिए विशेष मार्गदर्शन प्रदान किए बिना विशेष-उपयोग डोमेन नामों पर चर्चा करता है। RFC 6762 अभी भी अनरजिस्टर्ड TLDs का उपयोग नहीं करने की सिफारिश करता है, लेकिन यह भी स्वीकार करता है कि ऐसे मामले हैं जहां यह वैसे भी किया जाएगा। चूंकि बहुस्तरीय DNS (RFC का मुख्य विषय) के साथ आमतौर पर इस्तेमाल किया जाता है। मुखर संघर्ष, निजी परिशिष्ट निजी DNS Namespaces निम्नलिखित TLDs की सिफारिश करते हैं:

  • इंट्रानेट
  • अंदर का
  • निजी
  • कॉर्प
  • घर
  • लैन

आईएएनए दोनों आरएफसी को पहचानता प्रतीत होता है लेकिन वर्तमान में परिशिष्ट जी में सूचीबद्ध नामों को शामिल नहीं करता है।

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


परिशिष्ट G में आपके द्वारा उद्धृत सूची से पहले है: "हम अपंजीकृत शीर्ष-स्तरीय डोमेन के उपयोग की अनुशंसा नहीं करते हैं"। यह अधिक महत्वपूर्ण बिंदु है। दिए गए नामों का उपयोग करने के लिए "अनुशंसित" नहीं किया गया है, वे बस देखे गए नाम हैं .localजो बेहतर काम करेंगे जो मल्टीकास्टडएनएस के लिए आरक्षित है, जो परिशिष्ट जी में चर्चा है
पैट्रिक मेवज़ेक

2
मैं असहमत होता। मुख्य बिंदु सलाह की गैरबराबरी है: 'यह मत करो ... लेकिन जब आप करते हैं ...' घर / छोटे व्यवसाय / गैर-सार्वजनिक रूप से सामना करने वाले नेटवर्क को एक TLD पंजीकृत करना चाहिए यह अपेक्षा यथार्थवादी नहीं है। लोग अब तक सभी की मदद के लिए अपंजीकृत TLD का बेहतर उपयोग करने जा रहे हैं और 'ठीक है, यहां बता रहे हैं कि अपंजीकृत TLD की एक सूची जो आप आंतरिक रूप से उपयोग कर सकते हैं' के बजाय हर कोई हार्ड लाइन सलाह का पालन करने जा रहा है।
ब्लिहप

हम तब भी असहमति में रहेंगे। तथ्य यह है कि कुछ लोग TLD का उपयोग करते हैं जैसे वे आंतरिक हैं (उदाहरण के लिए .MAIL कई दस्तावेज़ों में पाया गया) यही कारण है कि इन TLD को प्रतिनिधि बनाना संभव नहीं था और अब अनिश्चित काल के लिए मर चुके हैं। इसलिए लोगों को इस तरह से TLD का उपयोग करने के लिए सिफारिश करना जारी रखना वैश्विक इंटरनेट समुदाय के लिए एक असहमति है। सलाह कहती है कि चूंकि कुछ TLD पहले से ही ऐसे दुरुपयोग किए जाते हैं, अगर लोगों को दुर्व्यवहार करना पड़ता है, तो उन्हें नए लोगों का दुरुपयोग करने के बजाय उन लोगों को फिर से उपयोग करना चाहिए। TFCs के लिए RFC2606 स्पष्ट रूप से उपयोग करने के लिए स्पष्ट है जो काम करेगा:.EXAMPLE .TEST .INVALID
पैट्रिक मेवज़ेक

12

जैसा कि पहले ही कहा गया है, आपको अपने निजी नेटवर्क के लिए अपंजीकृत TLD का उपयोग नहीं करना चाहिए। खासकर अब जबकि ICANN लगभग किसी को भी नए TLD को पंजीकृत करने की अनुमति देता है। फिर आपको एक वास्तविक डोमेन नाम का उपयोग करना चाहिए

दूसरी तरफ, RFC 1918 स्पष्ट है:

ऐसे पतों के अप्रत्यक्ष संदर्भ उद्यम के भीतर समाहित होने चाहिए। ऐसे संदर्भों के प्रमुख उदाहरण DNS रिसोर्स रिकॉर्ड और आंतरिक निजी पतों के संदर्भ में अन्य जानकारी हैं। इसलिए आपके नाम सर्वर को इंटरनेट पर प्रसारित होने वाले निजी रिकॉर्ड को रोकने के लिए विचारों का उपयोग करना चाहिए।


10

हम भौतिक से मेजबानों के आभासी नामकरण में कोई अंतर नहीं मानते हैं - वास्तव में, हमने भौतिक परत से होस्ट कॉन्फ़िगरेशन (सॉफ़्टवेयर) को अमूर्त करने के लिए लिया है।

इसलिए हम हार्डवेयर आइटम खरीदते हैं, और उनके ऊपर होस्ट आइटम बनाते हैं (और हमारे दस्तावेज़ में यह दिखाने के लिए एक सरल संबंध का उपयोग करते हैं)।

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


-4

मुझे यकीन नहीं है कि यह आपकी मदद करेगा, लेकिन मेरे एडब्ल्यूएस खाते के अंदर आंतरिक डीएनएस के लिए, मैं .awsटल्ड के रूप में उपयोग करता हूं , और यह पूरी तरह से ठीक काम करता है।

मुझे पता है कि कुछ TLD हैं जिनका आपको केवल उपयोग नहीं करना चाहिए, लेकिन उनके अलावा, मुझे नहीं लगता कि यह बहुत सख्त है।

मैंने कुछ बड़ी कंपनियों में काम किया, जहां वे TLD के रूप में प्रमाणीकरण स्रोत का उपयोग करेंगे, जिसका अर्थ है कि अगर यह MS / Windows सर्वर था, तो सक्रिय निर्देशिका को स्रोत के रूप में उपयोग करते हुए, यह होगा .ad, और कुछ अन्य होंगे .ldap(वे क्यों थे? एक ही स्रोत का उपयोग कर रहे हैं? या सर्वर एक ही निर्देशिका सेवा से प्रतिकृति? मैं नहीं जानता, यह उस तरह था जब मैं वहाँ गया था)

सौभाग्य


2
अमेज़ॅन ने अब .awsएक TLD के रूप में पंजीकृत किया है ताकि आप अंततः समस्याओं को देखना शुरू कर सकें: nic.aws
मार्क McKinstry

1
जानकारी के लिए, .aws हाल ही में "25 मार्च 2016" => newgtlds.icann.org/en/program-status/delegated-strings
ब्रूनो एडेल

जब तक मुझे नहीं लगता कि एक टोनी टीएलडी का उपयोग करना बहुत बड़ी बात है, कम से कम नहीं अगर पूरी प्रणाली बंद हो जाए और बड़े पैमाने पर इंटरनेट के साथ संवाद करने के लिए एक प्रॉक्सी का उपयोग करता है, तो ".aws" वास्तव में एक बुरा विकल्प है जब तक कि आप नहीं। AWS में नहीं! वहाँ बहुत से बोधगम्य परिदृश्य है जहाँ आप AWS के साथ संवाद करने में सक्षम नहीं होंगे।
अंजीर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.