RSSAC अक्सर पूछे जाने वाले प्रश्न

इस पेज में सामान्य तौर पर, RSSAC के सबसे अधिक पूछे जाने वाले अनेक प्रश्न और उत्तर हैं। जैसे-जैसे उत्तरों में बदलाव हों या नए प्रश्न बार-बार आते हों, वैसे ही इसे अपडेट किया जाएगा।

यदि आपका कोई प्रश्न है, जो नीचे सूचीबद्ध नहीं है या आपको अधिक जानकारी अथवा स्पष्टीकरण चाहिए, तो आप सीधे ask-rssac@icann.org पर मेल भेज सकते हैं। यदि आप इस अक्सर पूछे जाने वाले प्रश्न के साथ किसी प्रश्न का उल्लेख करना चाहते हैं, तो कृपया अपने ईमेल में प्रश्न का नंबर और शीर्षक शामिल करें। रूट सर्वर ऑपरेटर भी अक्सर पूछे जाने वाले प्रश्न तैयार रखते हैं।

विषयों की सूची

1. रूट सर्वर की संख्या
2. एनीकास्ट
3. DNS और नेटवर्किंग
4. रूट ज़ोन इन्टेग्रिटी
5. DNSSEC
6. RSSAC
7. RSSAC कॉकस
8. सामान्य गलतफ़हमियाँ

1. रूट सर्वर की संख्या

   1.1 यहाँ पर 13 रूट नाम सर्वर क्यों हैं?

   वर्ष 1985 में चार रूट सर्वर थे। वर्ष 1987-1991 तक सात थे, और सभी यू.एस.ए. में स्थित थे। वर्ष 1993 तक आठ थे। इस समय, किसी समस्या का सामना करना पड़ा।RFC 1035 तय करता है कि "UDP जिन [DNS] संदेशों को ले जाता है वे 512 बाइट्स तक सीमित किए जाते हैं।" अधिक रूट नाम वाले सर्वर जोड़ने की वजह से, 512 बाइट्स से अधिक एक प्राइमिंग रिस्पॉन्स होगा। 512 बाइट की सीमा के लिए RFC 1035 कोई मूल कारण नहीं बताता है, लेकिन यह भी ध्यान देने योग्य है कि उस समय एक सामान्य आवश्यकता थी कि इंटरनेट पर IP पैकेट 576 बाइट्स तक सीमित हों।

   रूट सर्वर ऑपरेटर्स ने महसूस किया कि अगर वे DNS नाम कम्प्रेसन का लाभ उठा सकें, तो अधिक नाम सर्वर जोड़े जा सकते हैं। इस तरह, root-servers.net ज़ोन में रूट सर्वर नाम देने की पेशकश की गई थी। वर्ष 1995 तक मौजूदा नौ रूट सर्वर का नाम बदलकर, "a.root-servers.net", "b.root-servers.net" वगैरह कर दिया गया। वर्ष 1997 में, चार और जोड़े गए, जिससे रूट सर्वर आइडेंटिफ़ायर्स (RSI) की कुल संख्या 13 तक हो गई।

   वर्ष 1998 तक, डॉ. जॉन पोस्टेल, IANA के एडमिनिस्ट्रेटर के रूप में, रूट सर्वर ऑपरेटर्स को काम सौंपने वाले व्यक्ति थे। वर्ष 1998 में उनकी मृत्यु के बाद, ऑपरेटर्स की संख्या नहीं बदली है हालाँकि, कुछ वर्षों में आपूर्ति में छोटी संख्या में बदलाव हुए हैं।

   वर्ष 1998 से, परिदृश्य कई मायनों में बदल गया है। प्रत्येक रूट सर्वर ने अपना खुद का IPv6 पता जोड़ा है, और ICANN ने DNS सिक्योरिटी एक्सटेंशन्स (DNSSEC) के साथ ज़ोन में साइन किया है। साथ ही, DNS (EDNS) प्रोटोकॉल एक्सटेंशन के लिए एक्सटेंशन मैकेनिज़्म का उपयोग करके, UDP पर ले जाए जाने वाले संदेशों के आकार का विस्तार किया गया है। इन बदलावों की वजह से, 512 बाइट UDP सीमा और RSI की 13 की सीमा, दोनों ही बहुत कम महत्वपूर्ण बन गई हैं।

   वर्ष 2002 में, Internet Software Consortium (ISC, अब Internet Systems Consortium) IP एनीकास्ट को असरदार तरीके से इस्तेमाल करने वाला पहला रूट सर्वर ऑपरेटर बन गया, हालाँकि पहले WIDE प्रोजेक्ट ने तकनीक के साथ परीक्षण किया था। इन वर्षों में, अन्य रूट सर्वर ऑपरेटर्स ने अनुसरण किया। एनीकास्ट प्रत्येक ऑपरेटर को कई तरह के अलग-अलग इंस्टेंसेस से सेवा मुहैया कराने की सुविधा देता है। जबकि आज 13 RSI हैं, फिर भी वास्तव में दुनिया भर में 1500 से अधिक एनीकास्ट के इंस्टेंसेस हैं।

   रूट सर्वर सिस्टम (RSS) के इतिहास की बेहतर समझ के लिए, कृपया RSSAC023v2: रूट सर्वर सिस्टम का इतिहास पढ़ें। यदि आप RSS के निरंतर विकास में रुचि रखते हैं, तो कृपया RSSAC037: DNS रूट सर्वर सिस्टम के लिए प्रस्तावित संचालन मॉडल पढ़ें।

   1.2 रूट सर्वर आइडेंटिफ़ायर्स की सीमा 13 होने के पीछे का गणित क्या था?

   वर्ष 1997 में रूट सर्वर .COM, .NET और .ORG ज़ोन के लिए आधिकारिक सर्वर के रूप में भी काम कर रहे थे और इस जोड़ी गई अतिरिक्त कार्यक्षमता की वजह से, इस बात पर ख़ास प्रतिबंध लग गया कि RSI की कितनी संख्या हो सकती हैं। रूट ज़ोन के लिए प्राइमिंग क्वेरी की तरह, .COM, .NET और .ORG ज़ोन के लिए NS RRSET क्वेरी करने से बाइट की सीमा 512 से अधिक नहीं हो सकती थी और चूँकि एक ही तरह के सर्वर इन ज़ोन में काम कर रहे थे, इसलिए वही सीमा सभी पर लागू हो रही थी।

   DNS रिस्पॉन्स पैकेट में भी प्रश्न अनुभाग में पूछा गया पूरा प्रश्न होता है। प्रश्न अनुभाग के लिए, कोई रूट प्राइमिंग क्वेरी का रिस्पॉन्स हमेशा 5 बाइट्स का उपयोग करेगा। कुल 5 के लिए, QNAME 1 बाइट लेता है और QTYPE और QCLASS प्रत्येक 2 लेता है। हालाँकि, किसी .COM प्राइमिंग क्वेरी के लिए प्रश्न अनुभाग काफी बड़ा हो सकता है।

   उद्देश्य	बाइट्स
   DNS हेडर	12
   पहला NS रिकॉर्ड	31
   कम्प्रेस किए गए 12 NS रिकॉर्ड	(12 * 15) 180
   13 A रिकॉर्ड्स	(13 * 16) 208
   प्रश्न अनुभाग QTYPE और QCLASS	4
   प्रश्न अनुभाग QNAME	?
   	=
   	435

   तालिका 1: रूट प्राइमिंग रिस्पॉन्स में इस्तेमाल किए जाने वाले बाइट्स के बारे में स्पष्टीकरण

   इस्तेमाल हो रहे 435 बाइट्स के साथ ही, इसमें सवाल सेक्शन में QNAME के लिए 77 बाइट्स उपलब्ध रहती हैं। उस समय यह तय किया गया था कि .COM, .NET और .ORG के लिए भेजी जाने वाली अधिकांश क्वेरीज़ को समायोजित करने के लिए 64 बाइट पर्याप्त होंगी। एक और सर्वर जोड़ने के लिए 25 बाइट्स की आवश्यकता होगी, और 435 + 64 + 25 > 512 के बाद से, यह निर्णय लिया गया कि कोई अन्य सर्वर न जोड़ा जाए।

2. एनीकास्ट

   2.1 कुछ ऑपरेटर्स के पास कई एनीकास्ट इंस्टेंसेस क्यों होते हैं, जबकि अन्य ऑपरेटर्स के पास कुछ ही होते हैं?

   रूट सर्वर ऑपरेटर्स (RSO) अलग-अलग आदेश, अलग-अलग परिचालन मॉडल, और धन के अलग-अलग स्रोतों वाले स्वतंत्र संगठन होते हैं। ये अंतर एनीकास्ट इंस्टेंसेस की संख्या के साथ-साथ अन्य परिचालन विकल्पों को भी प्रभावित कर सकते हैं। रूट सर्वर ऑपरेटर्स के पास उच्च स्तर की स्वतंत्रता होती है कि वे अपने नेटवर्क को असरदार तरीके से कैसे इस्तेमाल करते हैं; RSSAC042: रूट सर्वर ऑपरेटर स्वतंत्रता पर RSSAC के बारे में जानकारी देखें। सभी RSO उच्च गुणवत्ता वाली रूट DNS सेवा मुहैया कराने के लिए प्रतिबद्ध हैं।

   2.2 क्या एनीकास्ट नोड्स की संख्या असीमित है, या यह एक निश्चित संख्या तक सीमित है?

   एनीकास्ट ऑपरेशन कोRFC 4786 "एनीकास्ट सर्विसेज के ऑपरेशन" औरRFC 7094 "IP एनीकास्ट के आर्किटेक्चर पर विचार" में परिभाषित और वर्णित किया गया है। एनीकास्ट सेवा में नोड्स की संख्या की कोई अंतर्निहित सीमा नहीं है।

   2.3 रूट सर्वर आधिकारिक रूट ज़ोन की प्रतिकृति बना रहे हैं और इसे फिर से पब्लिश कर रहे हैं, फिर एनीकास्ट इंस्टेंस उनके डेटा को फिर से पब्लिश कर रहे हैं। इन दो प्रकार के रिपब्लिशिंग में क्या अंतर है?

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

   2.4 हम एक स्थानीय शहर में रूट सर्वर के एनीकास्ट इंस्टेंस को होस्ट करते हैं। हम देख रहे हैं कि वह दुनिया भर की क्वेरीज़ का जवाब दे रहा है। मैं इसे केवल स्थानीय क्षेत्र की क्वेरीज़ का जवाब देने वाला कैसे बना सकता हूँ?

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

   2.5 वर्ष 2016 में Dyn पर बड़ा भारी हमला हुआ था। क्या सभी रूट सर्वर एनीकास्ट इंस्टेंसेस के साथ ऐसा ही हो सकता है?

   हाँ, कम से कम सिद्धांत के तौर पर। यह भी एक कारण है कि RSS के कई ऑपरेटर और कई रूट सर्वर इंस्टेंसेस होते हैं। बड़ी संख्या में एनीकास्ट के इंस्टेंसेस RSS की क्षमता को बढ़ाते हैं और निश्चित रूप से हमले की स्थितियों में मदद करते हैं। हालाँकि, रूट सर्वर सिस्टम पर विश्व स्तर पर पहले भी हमला किया गया है, लेकिन कोई भी हमला पूरे सिस्टम को ख़त्म करने में सफल नहीं रहा है।

   2.6 मैं अपने संगठन के लिए रूट सर्वर के एनीकास्ट इंस्टेंस का अनुरोध कैसे करूँ?

   कृपया नीचे दी गई संपर्क जानकारी का उपयोग करके रूट सर्वर ऑपरेटर्स से सीधे संपर्क करें। प्रश्न 3.4 के समान ही, आप इसके बजाय जैसा कि RFC 8806 में बताया गया है, बिना रूट सर्वर एनीकास्ट सिस्टम का औपचारिक रूप से हिस्सा बने हुए, रूट ज़ोन की एक स्थानीय कॉपी चलाने पर भी विचार कर सकते हैं।

   लैटिन अमेरिका और कैरेबियन (LACNIC) के लिए इंटरनेट एड्रेस रजिस्ट्री में LACNIC क्षेत्र के देशों में एनीकास्ट रूट सर्वर इंस्टेंस की स्थापना को बढ़ावा देने के लिए +Raices नाम का एक प्रोजेक्ट भी है। अधिक जानकारी यहाँ पाई जा सकती है।

   Cogent Communications
   यूएस डिपार्टमेंट ऑफ़ डिफ़ेंस (NIC)
   ICANN	https://www.dns.icann.org/imrs/host/
   Internet Systems Consortium, Inc.	https://www.isc.org/f-root/hosting-an-f-root-node/
   NASA (एम्स रिसर्च सेंटर)
   Netnod	https://www.netnod.se/i-root/i.root-servers.net
   RIPE NCC	https://www.ripe.net/analyse/dns/k-root/hosting-a-k-root-node
   यूनिवर्सिटी ऑफ़ मेरीलैंड
   यूनिवर्सिटी ऑफ़ सदर्न कैलिफ़ोर्निया विश्वविद्यालय, इंफ़ॉर्मेशन साइंस इन्स्टिट्यूट	https://b.root-servers.org/
   यूएस आर्मी (रिसर्च लैब)
   Verisign, Inc.	https://www.verisign.com/rirs
   WIDE प्रोजेक्ट

   2.7 मैं कैसे तय करूँ कि रूट सर्वर आइडेंटिटी का कौनसा इंस्टेंस मेरी क्वेरीज़ का उत्तर देता है?

   रूट सर्वर आइडेंटिटी के लिए ख़ास क्वेरीज़ भेजने के लिए, आप Unix या Mac-आधारित कंप्यूटर सिस्टम से 'डिग' उपयोगिता का इस्तेमाल कर सकते हैं। रिस्पॉन्स से पता चलेगा कि किस एनीकास्ट साइट ने क्वेरी प्राप्त की।

   आप NSID क्वेरी विकल्प का उपयोग कर सकते हैं और फिर डिग के आउटपुट के OPT Pseudosection में रिपोर्ट की गई NSID स्ट्रिंग की खोज कर सकते हैं:

   $ dig +nsid @a.root-servers.net
   …
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags:; udp: 1472
   ; NSID: 6e 33 2e 75 73 2d 77 61 73 2e 72 6f 6f 74 ("n3.us-was.root")
   …
   

   प्रत्येक रूट सर्वर आइडेंटिटी अपनी एनीकास्ट साइट नेमिंग स्कीम चुनने के लिए स्वतंत्र है, लेकिन आम तौर पर साइटों का नाम IATA एयरपोर्ट कोड्स या UN/LOCODE का इस्तेमाल करके रखा जाता है। कुछ रूट सर्वर आइडेंटिटी अपनी साइट के नेमिंग कन्वेन्शन्स को अपनी संबंधित YAML फ़ाइलों के "आइडेंटिफ़ायर्स" खंड में पब्लिश करते हैं जो https://root-servers.org/ पर उपलब्ध हैं।

3. DNS और नेटवर्किंग

   3.1 पुनरावर्ती सर्वर किस रूट सर्वर को क्वेरी करने के लिए चुनते हैं, और मेरे पुनरावर्ती सर्वर को कौन से रूट सर्वर आइडेंटिफ़ायर को प्राथमिकता देनी चाहिए?

   इसे "सर्वर चयन एल्गोरिथ्म" कहा जाता है। DNS प्रोटोकॉल यह नहीं बताता है कि किसी पुनरावर्ती नाम वाले सर्वर को किसी विशेष क्वेरी के लिए सेट में से कैसे चुनना चाहिए। इस तरह, प्रत्येक पुनरावर्ती सॉफ़्टवेयर विक्रेता अपने खुद के सर्वर चयन एल्गोरिथ्म को तय करता है। कुछ रिज़ॉल्वर कार्यान्वयन कम से कम लेटेंसी वाले सर्वर पर या उन सर्वर में से किसी एक पर "लॉक ऑन" कर देंगे, जिनमें सबसे तेज़ के समान लेटेंसी है। कुछ रिज़ॉल्वर कार्यान्वयन हर बार सर्वर को अनियमित रूप से चुनते हैं, और कुछ जटिल सूत्रों के आधार पर क्वेरीज़ वितरित करते हैं।

   ख़ास सर्वर को प्राथमिकता देने या उनसे बचने के लिए इसे प्रभावित करने की कोशिश करने के बजाय, अपने पुनरावर्ती सॉफ़्टवेयर को डिज़ाइन के अनुसार अपना काम करने देना शायद अधिक भरोसेमंद है।

   3.2 क्या आप समझा सकते हैं कि DNS कैसे UDP और TCP पोर्ट 53, दोनों का इस्तेमाल करता है?

   क्वेरीज़ के लिए लगभग सभी DNS क्लाइंट डिफ़ॉल्ट रूप से UDP ट्रांसपोर्ट का इस्तेमाल करते हैं। हालाँकि, कुछ ऐसी स्थितियाँ हैं जब इसके बजाय TCP का इस्तेमाल करने की ज़रूरत होती है।

   TCP का सबसे आम उपयोग तब होता है, जब UDP रिस्पॉन्स कट जाता है। इस तरह का कटाव तब होता है, जब किसी एक UDP संदेश में फिट होने के लिए सर्वर का रिस्पॉन्स बहुत बड़ा हो जाता है। यह क्लाइंट के विज्ञापित UDP बफर आकार और किसी भी रिस्पॉन्स के आकार की उस सीमा पर निर्भर करता है, जिसे सर्वर खुद के लिए तय कर सकता है। जब क्लाइंट को कटे हुए बिट सेट के साथ रिस्पॉन्स मिलता है, तो DNS प्रोटोकॉल कहता है कि पूरा रिस्पॉन्स प्राप्त करने के लिए उसे TCP पर क्वेरी की फिर से कोशिश करनी होगी।

   DNS के लिए TCP का एक अन्य उपयोग ज़ोन ट्रांसफ़र है। चूँकि पूरे ज़ोन आम तौर पर एक UDP संदेश में फिट होने की तुलना में बहुत बड़े होते हैं, इसलिए इन्हें TCP पर प्रदर्शित करना सही रहता है।

   जब कोई सर्वर खुद को हमले के दायरे में पाता है, तो TCP भी भूमिका निभा सकता है। स्रोत धोखेबाज़ी वाला है या नहीं, यह तय करने के तरीके के रूप में सर्वर क्लाइंट को कटा हुआ रिस्पॉन्स भेज सकता है। TCP कनेक्शन स्थापित करने वाले ग्राहकों को गैर-धोखेबाज़ी वाले स्रोतों के रूप में व्हाइट लिस्ट किया जा सकता है। इसके अतिरिक्त, रिस्पॉन्स रेट लिमिटिंग (RRL) के रूप में जानी जाने वाली तकनीक कभी-कभी कटे हुए रिस्पॉन्स भेजती है, ताकि वैध ग्राहकों को TCP पर रिस्पॉन्स प्राप्त करने का अवसर मिले, जबकि हमले वाला ट्रैफ़िक फिर से कोशिश नहीं करेगा।

   DNS सॉफ़्टवेयर में DNS-ओवर-TCP लागू करना ज़रूरी है। अतिरिक्त जानकारी के लिए, कृपयाRFC 7766 देखें।

   3.3 मैं अपने द्वारा चलाए जाने वाले रिकर्सिव सर्वर और रूट सर्वर के बीच लेटेंसी को कैसे कम करूँ?

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

   रूट नाम वाले सर्वर को भेजे जाने वाली क्वेरीज़ के लिए, अपने रिकर्सिव नाम वाले सर्वर को छोड़ने वाले ट्रैफ़िक का विश्लेषण करें। यदि आपको उम्मीद से अधिक ट्रैफ़िक दिखाई देता है, तो हो सकता है कि आप अपने एप्लिकेशन या नेटवर्क कॉन्फ़िगरेशन को ठीक करने में सक्षम हों, ताकि उन्हें इतनी बार रूट की क्वेरी करने की ज़रूरत न पड़े। असल लेटेंसी को मापने के लिए "डिग" उपयोगिता जैसे प्रोग्राम का इस्तेमाल करें। अगर कम से कम दो रूट सर्वर 100 मिलीसेकंड के भीतर हों, तो यह आम तौर पर पर्याप्त होना चाहिए।

   अपने रिकर्सिव सर्वर और आपके रिकर्सिव नाम वाले सर्वर द्वारा इस्तेमाल किए जा रहे रूट सर्वर के बीच नेटवर्क पथ की खोज करने के लिए "ट्रेसरूट" जैसे टूल का इस्तेमाल करें। यदि आपको कुछ ऐसा मिलता है जिसका कोई अर्थ न हो (जैसे दूर के स्थानों से रूटिंग), तो अपने ISP से पूछें कि क्या रूटिंग में बदलाव किया जा सकता है।

   सेवा के माप की DNS गुणवत्ता के बारे में अधिक जानकारी के लिए, Réseaux IP Européens (RIPE) एटलस प्रोजेक्ट अपने DNSMON प्रोजेक्ट की रूट सेवा में सेवा की गुणवत्ता को मॉनिटर करता है। जैसे कि सैकड़ों RIPE एटलस एंकरों द्वारा मापी गई अधिकांश सर्वर की लेटेंसी 60 मिली सेकंड से कम है।

   अगर आस-पास उचित रूप से कोई रूट सर्वर न हो, तो आप-पास के उस एक्सचेंज पॉइंट या डेटा केंद्र की पहचान करने की कोशिश कर सकते हैं, जहाँ रूट सर्वर स्थित हो सकता है। एक या उससे अधिक रूट सर्वर ऑपरेटर्स से पूछें कि क्या वे वहाँ सर्वर लगाने के इच्छुक होंगे। हालाँकि, यह ध्यान दें कि यदि किसी स्थान पर पहले से ही कोई रूट सर्वर है, तो ऑपरेटर आमतौर पर वहाँ कोई दूसरा रूट सर्वर नहीं रखना चाहेंगे। आपhttp://www.root-servers.org पर जाने के बाद, पृष्ठ के निचले भाग पर मौजूद रूट सर्वर अनुभाग में "संपर्क ईमेल" बटन का पता लगाकर, ऑपरेटर की संपर्क जानकारी प्राप्त कर सकते हैं।

   3.4 क्या आप रूट ज़ोन फ़ाइल डाउनलोड करके और स्वयं हस्ताक्षर को मान्य करके रूट सर्वर स्थापित कर सकते हैं?

   RFC 8806 से पता चलता है कि यह कैसे करना है, साथ ही ऐसा करने के लिए संभावित डाउनसाइड्स के बारे में कई चेतावनियाँ सूचीबद्ध करता है। ध्यान दें कि इसके लिए DNSSEC की पुष्टि ज़रूरी है। LocalRoot प्रोजेक्टभी देखें।

   3.5 कोई रिकर्सिव सर्वर किसी जानकारी को कब तक कैशे में सेव करेगा?

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

   रूट ज़ोन के मामले में, कुछ रिकॉर्ड 24-घंटे के TTL के साथ और अन्य 48-घंटे के TTL के साथ काम में लाए जाते हैं। कुछ रिज़ॉल्वर में कैशे में सेव करने का अधिकतम समय आमतौर पर 24 घंटे होता है।

   3.6 चूँकि तय समय के बाद कैशिंग गलत जानकारी देगी, इसलिए किसी रिज़ॉल्वर को सही DNS जानकारी के साथ कैसे अपडेट किया जा सकता है?

   अगर आपको संदेह है कि रिकर्सिव नाम वाले सर्वर की कैशे में डेटा पुराना है, तो आप इसकी कैशे को फ़्लश कर सकते हैं या सर्वर की प्रक्रिया को फिर से शुरू कर सकते हैं।

   3.7 DNS प्राइमिंग क्वेरीज़ और रिस्पॉन्सेस क्या हैं?

   DNS रिकर्सिव रिज़ॉल्वर्स को नियमित क्वेरीज़ का उत्तर देना शुरू करने से पहले, उन्हें रूट ज़ोन से किसी ख़ास डेटा के साथ अपनी कैशे को तैयार करने की ज़रूरत होती है।RFC 8109 से पता चलता है कि रिकर्सिव रिज़ॉल्वर्स कौन सी क्वेरीज़ भेजते हैं और वे रूट सर्वर से क्या रिस्पॉन्सेस चाहते हैं।

4. रूट ज़ोन इन्टेग्रिटी

   4.1 ऑपरेटर कैसे सुनिश्चित करते हैं कि रूट ज़ोन की कॉपी ठीक से बनाई गई है?

   अलग-अलग RSO को रूट ज़ोन फ़ाइल का ट्रांसफ़र रूट ज़ोन मेंटेनर (RZM) से DNS ज़ोन ट्रांसफ़र प्रोटोकॉल (RFC 5936 में AXFR और RFC 1995 में IXFR) के ज़रिए होता है। ये ज़ोन ट्रांसफ़र के संदेश RFC 2845 में दी गई जानकारी के मुताबिक, TSIG संसाधन रिकॉर्ड के उपयोग से सुरक्षित किए जाते हैं। ये विश्वसनीय प्रोटोकॉल हैं और इनमें डेटा करप्शन की कोई ज्ञात समस्या नहीं है। इसके अलावा, चूँकि रूट ज़ोन साइन किए गए हैं, इसलिए DNSSEC सत्यापनकर्ताओं द्वारा ग़लत या हेरफेर वाले उत्तरों का पता लगाया जा सकता है। जहाँ संभव हो, वहाँ DNSSEC सत्यापन के उपयोग को RSSAC प्रोत्साहित करता है।

   RSO को अलर्ट करने के लिए, RZM ज़ोन में बदलावों की तुरंत सूचना के लिए, RFC 1996 में परिभाषित DNS सूचना सुविधा का इस्तेमाल करता है कि कॉपी करने या ट्रांसफ़र करने के लिए एक नया (अर्थात, नया वर्शन) ज़ोन उपलब्ध है।

   4.2 ZONEMD क्या है और यह रूट ज़ोन डेटा की इन्टेग्रिटी की रक्षा कैसे कर सकता है?

   चूँकि किसी भी पाथ में किसी भी डेटा करप्शन को रोकना असंभव है, इसलिए यह महत्वपूर्ण है कि रिज़ॉल्वर्स DNSSEC का इस्तेमाल करके प्राप्त होने वाले सभी उत्तरों को मान्य करें (अनुभाग 5 देखें)। यह सुनिश्चित करने के लिए अन्य मैकेनिज़्म को अतिरिक्त रूप से काम पर लगाया गया है कि काम पर लगाया गया हर रूट सर्वर इंस्टेंस अपनी क्षमता के अनुसार डेटा पर बेहतरीन काम करता है। जैसा कि ऊपर चर्चा की गई है, RSO और RZM द्वारा TSIG के उपयोग से, यह सुनिश्चित होता है कि ट्रांसफ़र के दौरान रिकॉर्ड डेटा करप्ट न हो।

   RFC 8976 एक ऐसे ZONEMD रिकॉर्ड का इस्तेमाल करके, किसी DNS ज़ोन फ़ाइल की इन्टेग्रिटी को सुनिश्चित करने के लिए एक मैकेनिज़्म को परिभाषित करता है जो "स्थिरता से DNS ज़ोन डेटा पर एक क्रिप्टोग्राफ़िक मैसेज डाइजेस्ट मुहैया कराता है"। जैसा कि रूट-सर्वर ऑपरेटर्स द्वारा पब्लिश एक विवरण में बताया गया है, RSO ZONEMD रिकॉर्ड्स के शुरूआती पब्लिकेशन के बाद पहले वर्ष के लिए ZONEMD सत्यापन सक्षम नहीं करेंगे। इसे अभी तक काम पर नहीं लगाया गया है, लेकिन भविष्य में ऐसा करने की योजना है।

   ZONEMD डेटा की इन्टेग्रिटी और मूल प्रामाणिकता के लिए किसी पूर्ण रूट ज़ोन के प्राप्तकर्ताओं को ज़ोन सामग्री को सत्यापित करने के लिए सक्षम करेगा। DNSSEC यह सुनिश्चित करने के लिए DNS साइन वाले डेटा (जिसमें रूट ज़ोन शामिल है) के अंतिम-उपयोगकर्ताओं को सक्षम करता है कि ट्रांज़िट के दौरान डेटा को हैंडल कर सकने वाले पथ और सर्वर पर ध्यान दिए बिना, उन्हें प्राप्त हुए उत्तर प्रामाणिक हैं।

5. DNSSEC

   5.1 क्या DNSSEC DNS क्वेरीज़ और रिस्पॉन्सेस को गोपनीय बनाता है?

   नहीं, यह DNS डेटा की उत्पत्ति को प्रमाणित करने के साथ-साथ इसकी इन्टेग्रिटी की रक्षा करके, DNS आधारभूत संरचना में केवल एक सुरक्षा परत जोड़ता है।

   5.2 क्या DNSSEC के कारण स्थानीय रूप से रूट ज़ोन की कॉपी देना अधिक कठिन हो जाता है?

   नहीं, रूट ज़ोन की स्थानीय कॉपी देने का बस यही अर्थ है कि किसी बदलाव के बिना रूट ज़ोन की अप-टू-डेट कॉपी दी जाए। रूट ज़ोन मैनेजर (RZM) के सभी आवश्यक DNSSEC हस्ताक्षरों के साथ रूट ज़ोन आता है।

   रूट ज़ोन पर स्थानीय रूप से काम करने के बारे में अधिक जानकारी के लिए प्रश्न 3.4 औरRFC 8806 देखें।

6. RSSAC

   6.1 क्या RSSAC मीटिंग सभी के लिए उपलब्ध हैं?

   RSSAC, ICANN मीटिंग में समय-समय पर टेलीकॉन्फ़्रेंस करता है और मीटिंग रखता है। मीटिंग और टेलीकॉन्फ़्रेंस के मिनट (जहां उपलब्ध हों) यहां देखे जा सकते हैं। किसी RSSAC टेलीकॉन्फ़्रेंस या वर्क सेशन पर नज़र रखने के लिए, कृपया दूरस्थ प्रतिभागिता से जुड़ी जानकारी के लिए rssac-staff@icann.org पर संपर्क करें।

   ICANN मीटिंग में होने वाली ज़्यादातर RSSAC मीटिंग निरीक्षकों के लिए खुली होती हैं, जब तक कि मीटिंग को ICANN के एजेंडा में बंद के रूप में मार्क नहीं किया गया हो। RSSAC, ICANN मीटिंग में पब्लिक सेशन भी रखता है जहां कम्युनिटी के सदस्यों को अपने सवाल पूछने के लिए आमंत्रित किया जाता है।

   6.2 RSSAC और SSAC के बीच क्या संबंध है?

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

   दोनों समूहों की सीमा में कुछ ओवरलैप है। दोनों समूहों को एक-दूसरे के काम के प्रति जागरूक रखने के लिए SSAC, RSSAC के लिए एक संपर्क अधिकारी की नियुक्ति करता है। इसके अलावा, ICANN की मीटिंग में, SSAC और RSSAC एक संयुक्त मीटिंग रखते हैं।

   SSAC का वर्णन ICANN वाले उपनियमों के सेक्शन 12.2(b) में किया गया है। अतिरिक्त जानकारी यहां मिल सकती है।

   6.3 RSSAC और RZERC कैसे संबंधित हैं? क्या RZERC, RSSAC का एक सबसेट है?

   रूट सर्वर सिस्टम एडवाइजरी कमेटी (RSSAC) और रूट ज़ोन इवोल्यूशन रिव्यू कमेटी (RZERC) ICANN के भीतर अलग-अलग समितियाँ हैं, हालाँकि उनके बीच संपर्क हैं और व्यक्ति दोनों समितियों में कार्य कर सकते हैं।

   RSSAC चार्टर कहता है कि यह:
   "..ICANN बोर्ड और समुदाय को रूट सर्वर सिस्टम के संचालन, व्यवस्थापन, सुरक्षा और इन्टेग्रिटी से जुड़े मामलों पर सलाह देता है।" RSSAC की भूमिका के बारे में अधिक जानकारी के लिए, कृपया RSSAC033: RSSAC और रूट-ऑप्स के बीच अंतर पर RSSAC विवरण पढ़ें।

   RZERC चार्टर कहता है कि यह:
   "..DNS रूट ज़ोन की सामग्री में प्रस्तावित आर्किटेक्चरल बदलावों, DNS रूट ज़ोन में बदलाव करने में इस्तेमाल किए जाने वाले हार्डवेयर और सॉफ़्टवेयर घटकों सहित सिस्टम, और DNS रूट ज़ोन के वितरण के लिए इस्तेमाल किए जाने वाले मैकेनिज़्म की समीक्षा करने की उम्मीद करता है।"

   निम्नलिखित ग्राफिक प्रत्येक समूह की भूमिकाओं को समझाने में मदद करता है।

   

   6.4 क्या कोई समय-सीमा है जब हमें पता चल जाता है कि RSSAC को कितने रूट सर्वर चाहिए? अक्षरों की संख्या निर्धारित करने के लिए मूल्यांकन कब होगा?

   रूट सर्वर की संख्या या RSO की संख्या कितनी होनी चाहिए, इसके बारे में RSSAC की कोई पूर्व कल्पना नहीं है। ऑपरेटर्स की संख्या पर मौजूदा सीमा तकनीकी है, प्रशासनिक नहीं।

   6.5 मुझे RSSAC पब्लिकेशन कहाँ मिल सकते हैं?

   RSSAC पब्लिकेशनRSSAC पब्लिकेशन पेज पर उपलब्ध हैं। रूट सर्वर सिस्टम से परिचित होने वाले लोगों की विशेष रुचिRSSAC023v2: रूट सर्वर सिस्टम का इतिहास औरRSSAC026v2: RSSAC लेक्सिकन हैं।

7. RSSAC कॉकस

   RSSAC कॉकस के बारे में जानकारी उनकेमुख्य वेब पेज पर मिल सकती है।

   7.1 RSSAC सदस्य और RSSAC कॉकस सदस्य के बीच क्या अंतर है?

   RSSAC में हर एक रूट सर्वर ऑपरेटर से नियुक्त किए गए प्रतिनिधि और विकल्प के साथ-साथ अलग-अलग समूहों के संपर्क अधिकारी शामिल हैं। RSSAC कॉकस में वे DNS विशेषज्ञ होते हैं जिनकी रूट सर्वर सिस्टम में रुचि है। RSSAC द्वारा प्रकाशित ज़्यादातर (लेकिन सभी नहीं) परामर्श RSSAC कॉकस द्वारा बनाया जाता है, जबकि RSSAC वह औपचारिक सलाहकार समिति है जो ICANN बोर्ड और कम्युनिटी को प्रसारण के लिए प्रकाशनों की अंतिम अनुमति देती है।

   सभी RSSAC सदस्य RSSAC कॉकस के भी सदस्य हैं। RSSAC सदस्यों की सूची यहां मिल सकती है। RSSAC कॉकस सदस्यों की सूची यहां मिल सकती है। RSSAC कॉकस में शामिल होने संबंधी जानकारी RSSAC कॉकस के मुख्य पेज पर मिल सकती है।

   7.2. क्या RSSAC कॉकस मीटिंग सभी के लिए खुली हैं?

   RSSAC कॉकस ICANN सालाना जनरल मीटिंग में और सभी सम-संख्या वाले IETF में जनरल मीटिंग रखता है। सभी जनरल मीटिंग निरीक्षकों के लिए उपलब्ध हैं। RSSAC कॉकस वर्क पार्टी की मीटिंग निरीक्षकों के लिए उपलब्ध नहीं हैं।

   सभी RSSAC कॉकस सदस्यों को RSSAC कॉकस की सभी जनरल मीटिंग और RSSAC कॉकस वर्क पार्टी मीटिंग में आमंत्रित किया जाता है।

   7.3 RSSAC कॉकस के कितने सदस्य हो सकते हैं, इसकी कोई सीमा है?

   नहीं।

   7.4 RSSAC कॉकस सदस्यों की समय से जुड़ी आवश्यकताएँ क्या हैं?

   RSSAC कॉकस सदस्यों से उम्मीद की जाती है कि वे कार्य दलों में भाग लें और RSSAC कॉकस मेलिंग सूची में भाग लें। कुछ सदस्य दूसरों की तुलना में अधिक समय देने में सक्षम होंगे, और कुछ कार्य दल और दस्तावेज़ समीक्षा के लिए दूसरों की तुलना में अधिक समय की आवश्यकता होती है। हालाँकि, RSSAC आम तौर पर चाहेगा कि सदस्य कॉकस गतिविधियों पर प्रति माह कम से कम 4 घंटे दें।

8. सामान्य गलतफ़हमियाँ

   DNS कैसे काम करता है, इस पर परिचय के लिए कृपयाडैनियल कर्रेनबर्ग द्वारा गैर-विशेषज्ञों के लिए इंटरनेट डोमेन नाम प्रणाली के बारे में जानकारी पढ़ें।

   8.1 क्या रूट सर्वर यह नियंत्रित करते हैं कि इंटरनेट ट्रैफ़िक कहाँ जाता है?

   नहीं, राउटर्स और BGP प्रोटोकॉल उस पथ को निर्धारित करते हैं जो पैकेट नेटवर्क के माध्यम के ज़रिए स्रोत से गंतव्य तक ले जाते हैं। DNS मानव-उन्मुख नामों से IP पतों में एक मैपिंग मुहैया कराता है, और ये ऐसे IP पते हैं, जिन्हें राउटर्स अंततः यह निर्धारित करने के लिए उपयोग करते हैं कि पैकेट कहाँ जाने चाहिए।

   8.2 क्या अधिकांश DNS क्वेरीज़ रूट सर्वर द्वारा हैंडल की जाती हैं?

   नहीं, ज़्यादातर को रिकर्सिव रिज़ॉल्वर द्वारा रूट सर्वर के साथ किसी भी इंटरैक्शन के बिना उनके कैशे में पहले से मौजूद डेटा से हैंडल किया जाता है। यदि किसी रिकर्सिव रिज़ॉल्वर के पास टॉप-लेवल डोमेन के बारे में बिना समय समाप्ति वाली जानकारी नहीं है या उसकी कैशे में खुद रूट्स हैं, तो रिकर्सिव रिज़ॉल्वर केवल किसी रूट सर्वर के साथ ही इंटरैक्ट करता है। रूट सर्वर द्वारा प्राप्त लगभग सभी क्वेरीज़ की वजह से, एक रेफ़रल रिस्पॉन्स होता है जो रिकर्सिव नाम वाले सर्वर को बताती है कि अगला प्रश्न कहाँ पूछना है।

   8.3 क्या रूट सर्वर आइडेंटिफ़ायर का कोई ख़ास अर्थ है?

   कोई भी रूट सर्वर आइडेंटिफ़ायर ख़ास नहीं है।

   8.4 क्या केवल 13 रूट सर्वर हैं?

   वैश्विक रूप से 1500 से अधिक सर्वर हैं, लेकिन केवल 13 रूट सर्वर आइडेंटिफ़ायर (RSI) हैं, जिनमें से प्रत्येक एक IPv4 और एक IPv6 पते और एनीकास्ट रूटिंग का इस्तेमाल करता है।

   8.5 क्या रूट सर्वर ऑपरेटर स्वतंत्र रूप से संचालन के कार्य करते हैं?

   RSO स्वतंत्र रूप से कार्य करते हैं, लेकिन वे RSSAC और अन्य प्लैटफ़ॉर्म के ज़रिए एक-दूसरे के साथ क़रीबी से मिलकर काम भी करते हैं। अधिक जानकारी के लिए, RSSAC042: रूट सर्वर ऑपरेटर स्वतंत्रता पर RSSAC के बारे में जानकारी देखें।

   8.6 क्या रूट सर्वर केवल DNS क्वेरी का TLD वाला भाग ही प्राप्त करते हैं?

   वर्तमान में, रूट सर्वर (और वास्तव में सभी DNS सर्वर) को आमतौर पर DNS अनुरोध में संपूर्ण क्वेरी नाम प्राप्त होता है। हालाँकि, एक नई DNS सुविधा बताई गई है, जो आवश्यक होने पर केवल डोमेन नाम के TLD भाग को रूट सर्वर पर भेज देगी।

   RFC 9156 से पता चलता है कि कैसे रिकर्सिव DNS सर्वर क्वेरी नाम का केवल सबसे छोटा आवश्यक भाग ही भेज सकते हैं। इसे क्वेरी नाम मिनिमाइज़ेशन या QNAME मिनिमाइज़ेशन कहा जाता है। QNAME मिनिमाइज़ेशन रिकर्सिव DNS सर्वर के साथ काम करता है, डोमेन नाम के केवल उन्हीं ज़रूरी भागों को वे सर्वर पर भेजते हैं, जिनके बारे में वे क्वेरी करते हैं। QNAME मिनिमाइज़ेशन का इस्तेमाल करने वाले रिकर्सिव DNS सर्वर को रूट सर्वर की क्वेरी का केवल TLD भाग ही भेजना चाहिए। यह वायर पर जानकारी की मात्रा को कम करता है और इसलिए DNS क्वेरी करने वाले उपयोगकर्ताओं के लिए बेहतर गोपनीयता मुहैया कराता है।