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

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

2 एनीकास्ट

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

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

5 DNSSEC

6 RSSAC

7 RSSAC कॉकस

8 आम गलतफ़हमियाँ

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

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

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

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

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

वर्ष 2002 में, इंटरनेट सॉफ़्टवेयर कंसोर्टियम (ISC, अब इंटरनेट सिस्टम कंसोर्टियम) IP एनीकास्ट को असरदार तरीके से इस्तेमाल करने वाला पहला RSO बन गया, हालाँकि पहले WIDE प्रोजेक्ट ने इस तकनीक के साथ परीक्षण किया था। कई सालों के दौरान, अन्य RSO ने इसे फ़ॉलो किया। एनीकास्ट प्रत्येक ऑपरेटर को कई तरह के अलग-अलग इंस्टेंसेस से सेवा मुहैया कराने की सुविधा देता है। जबकि आज 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 प्राइमिंग क्वेरी के लिए प्रश्न अनुभाग काफी बड़ा हो सकता है।

तालिका 1: रूट प्राइमिंग रिस्पांस में उपयोग किए गए बाइट का स्पष्टीकरण

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

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

RSO अलग-अलग आदेशों, अलग-अलग परिचालन मॉडल और धन के अलग-अलग स्रोतों वाले स्वतंत्र संगठन होते हैं। ये अंतर एनीकास्ट इंस्टेंसेस की संख्या के साथ-साथ अन्य परिचालन विकल्पों को भी प्रभावित कर सकते हैं। 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 नाम का एक प्रोजेक्ट भी है। अधिक जानकारी यहाँ पाई जा सकती है।

तालिका 2: एनीकास्ट इंस्टेंसस का अनुरोध करने के लिए संपर्क जानकारी 

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

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

आप NSID क्वेरी विकल्प का उपयोग कर सकते हैं और फिर dig के आउटपुट के 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 फ़ाइलों के "Identifiers" खंड में पब्लिश करते हैं जो https://root-servers.org/ पर उपलब्ध हैं।

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 के उत्तर में बताया गया है, रिज़ॉल्वर सॉफ़्टवेयर एल्गोरिथ्म आम तौर पर कम लेटेंसी वाले रूट सर्वर को क्वेरी करने की कोशिश करेगा। इसलिए, कुछ रूट सर्वर में ज़्यादा लेटेंसी होने से यह ज़रूरी नहीं है कि ज़्यादा लेटेंसी वाले रूट सर्वर सिस्टम के लिए क्वेरी मिलेंगी।

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8 आधुनिक DNS क्वेरी में EDNS की क्या भूमिका होती है और इससे रूट सर्वर के संचालनों पर क्या प्रभाव पड़ता है?

EDNS या DNS के लिए एक्सटेंशन मेकैनिज़्म, जिसे RFC 6891 में परिभाषित किया गया है, जो पीछे की संगतता बनाए रखते हुए DNS प्रोटोकॉल की क्षमताओं को बेहतर बनाता है। यह आधुनिक DNS क्वेरी के लिए महत्वपूर्ण है, जिससे बड़े जवाब मिल पाते हैं, जैसे कि DNSSEC डेटा या अतिरिक्त रिकॉर्ड के साथ।

3.9 सिंगल रूट सर्वर में गलत कॉन्फ़िगरेशन का समग्र DNS इकोसिस्टम पर क्या प्रभाव पड़ता है? 

सिंगल रूट सर्वर में गलत कॉन्फ़िगरेशन के स्थानीयकृत या अस्थायी प्रभाव हो सकते हैं। हालाँकि, RSS को यह सुनिश्चित करने के लिए डिज़ाइन किया गया है कि समग्र DNS इकोसिस्टम, गलत कॉन्फ़िगरेशन या कंपोनेंट की विफलता की स्थिति में भी लचीला और विश्वसनीय बना रहता है।

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 ज़ोन डेटा पर एक क्रिप्टोग्राफ़िक संदेश डाइजेस्ट प्रदान करता है"। मौजूदा रूट ज़ोन में एक ऐसा ZONEMD रिकॉर्ड है जिसमें रूट ज़ोन का डिजिटल सिग्नेचर शामिल है।

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

4.3 रूट सर्वर संचालनों में ZONEMD क्रियान्वयन की क्या स्थिति है?

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

5.1 क्या DNSSEC, DNS की क्वेरी और जवाबों को गोपनीय बनाता है?

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

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

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

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

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

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 लेक्सिकन।

6.6 ICANN के समग्र नीति विकास की प्रक्रिया में RSSAC की क्या भूमिका है?

RSSAC, ICANN, के भीतर एक सलाहकार इकाई है, जिसका फ़ोकस विशिष्ट रूप से रूट सर्वर सिस्टम की संचालनात्मक स्थिरता, विश्वसनीयता और सुरक्षा से जुड़ी समस्याओं पर होता है। हालांकि RSSAC सीधे ICANN की नीतियां विकसित नहीं करता है, लेकिन वह नीतिगत चर्चाओं को सूचित करने के लिए तकनीकी विशेषज्ञता और सुझाव देता है। उदाहरण के लिए, RSSAC नई तकनीकों के क्रियान्वयन और रूट सर्वर सिस्टम पर उनके संभावित प्रभाव पर सलाह देता है। इन योगदानों से यह सुनिश्चित करने में मदद मिलती है कि ICANN की नीतियां DNS के संचालनों तथा सुरक्षा के सबसे अच्छे तरीकों के अनुरूप हों।  

6.7 व्यक्ति या संगठन फ़ीडबैक किस तरह दे सकते हैं या RSSAC के साथ किस तरह संलग्न हो सकते हैं?

RSSAC व्यापक ICANN समुदाय से फ़ीडबैक और संलग्नता को बढ़ावा देता है। व्यक्ति और संगठन सार्वजनिक बैठकों में भाग ले सकते हैं, सार्वजनिक परामर्श की अवधियों में ड्राफ़्ट प्रकाशनों पर टिप्पणियां कर सकते हैं या विषय विशेषज्ञों के रूप में RSSAC कॉकस में शामिल हो सकते हैं। RSSAC की गतिविधियों पर नियमित अपडेट ICANN की वेबसाइट पर उपलब्ध हैं और समुदाय के सदस्य RSSAC से ICANN सहायता टीम के माध्यम से सीधे संपर्क कर सकते हैं। खुली सहभागिता की यह प्रक्रिया सुनिश्चित करती है कि 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 घंटे दें।

7.5 RSSAC कॉकस RSSAC प्रकाशनों और सुझावों के विकास में किस तरह योगदान देता है?

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

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 क्वेरी करने वाले उपयोगकर्ताओं के लिए बेहतर गोपनीयता मुहैया कराता है।