परिचय: डीएनएस के इंतज़ार का समय और वजहें
जैसे-जैसे वेब पेज कई मुश्किलों से जुड़ते हैं, कई डोमेन से मिलने वाले संसाधनों का रेफ़रंस देना, डीएनएस ब्राउज़ करने में काफ़ी समस्या हो सकती है. जब भी किसी क्लाइंट को नेटवर्क पर डीएनएस रिज़ॉल्वर के बारे में क्वेरी करनी होती है, तब इंतज़ार के समय के बारे में बताना अहम हो सकता है. यह इस बात पर निर्भर करता है कि रिज़ॉल्वर को कितने नाम वाले सर्वर की क्वेरी करनी है और कितने पास होने चाहिए. हालांकि, ऐसा दो से ज़्यादा नहीं हो सकता. उदाहरण के लिए, नीचे दिया गया स्क्रीन शॉट, पेज स्पीड वेब परफ़ॉर्मेंस मेज़रमेंट टूल से रिपोर्ट किया गया समय दिखाता है. हर बार, पेज से रिसॉर्स के बारे में बताता है; काले रंग के सेगमेंट, डीएनएस लुकअप को दिखाते हैं. इस पेज में, पहले 11 सेकंड में 13 लुकअप किए जाते हैं. इसके बाद, पेज लोड हो जाता है. हालांकि, कई लुकअप का इस्तेमाल एक साथ किया जाता है, लेकिन स्क्रीन शॉट से पता चलता है कि पेज के लोड होने में कुल 11 सेकंड से ज़्यादा समय लगता है. इसके लिए, सीरियल लुकअप का समय पांच होना चाहिए.
डीएनएस के लिए इंतज़ार के समय के दो कॉम्पोनेंट होते हैं:
- सर्वर और डीएनएस सर्वर के बीच इंतज़ार का समय. ज़्यादातर मामलों में, ऐसा आम तौर पर होने वाले दोतरफ़ा यात्रा के समय (आरटीटी) की वजह से, नेटवर्क सिस्टम में समस्याएं आती हैं: क्लाइंट और सर्वर मशीनों के बीच की भौगोलिक दूरी, नेटवर्क पर ज़्यादा ट्रैफ़िक होने, पैकेट लीक होने की स्थिति में और लंबे समय तक दोबारा स्विच होने में होने वाली देरी (औसतन एक सेकंड में); ओवरलोड सर्वर, सेवा में रुकावट आने और ऐसे ही अन्य काम.
- सर्वर और अन्य नाम सर्वर के बीच इंतज़ार का समय.
इंतज़ार के समय की यह वजह, मुख्य रूप से इन वजहों से होती है:
- कैश मेमोरी छूट गया. अगर किसी रिज़ॉल्वर के कैश से जवाब नहीं मिलता है, लेकिन दूसरे नाम सर्वर से बार-बार क्वेरी करनी पड़ती है, तो जोड़े गए नेटवर्क के लिए इंतज़ार का समय ज़्यादा माना जाता है. खास तौर पर, ऐसा तब होता है, जब आधिकारिक सर्वर भौगोलिक रूप से रिमोट हों.
- प्रावधान नहीं किया जा सकता. अगर डीएनएस रिज़ॉल्वर ओवरलोड हो जाते हैं, तो उन्हें डीएनएस रिज़ॉल्यूशन अनुरोधों और रिस्पॉन्स को सूची में डालना होगा. साथ ही, पैकेट को छोड़ना और फिर से भेजना शुरू किया जा सकता है.
- नुकसान पहुंचाने वाला ट्रैफ़िक. अगर किसी डीएनएस सेवा का प्रावधान हटाया गया है, तो भी DoS ट्रैफ़िक, सर्वर पर ज़रूरत से ज़्यादा लोड डाल सकता है. इसी तरह, कामिंस्की शैली के हमलों में बाढ़ के रिज़ॉल्वर हो सकते हैं, जिनके लिए कैश मेमोरी को बायपास करने की गारंटी दी जाती है. साथ ही, जिनका समाधान करने के लिए अनुरोध करना पड़ता है.
हमारा मानना है कि DNS की प्रतीक्षा का मुख्य कारण कैश मेमोरी में देरी है, इसलिए इस बारे में आगे चर्चा की जा सकती है.
कैश मेमोरी उपलब्ध नहीं है
भले ही, रिज़ॉल्वर में स्थानीय संसाधनों की भरमार हो, लेकिन रिमोट नेम सर्वर से बात करने में होने वाली बुनियादी देरी से बचना मुश्किल होता है. दूसरे शब्दों में, यह मानकर कि रिज़ॉल्वर को ज़रूरत के मुताबिक प्रावधान किया जाता है, ताकि सर्वर साइड पर कैश मेमोरी के लिए कोई समय न मिले. ऐसे में, इंतज़ार के समय के मामले में कैश मेमोरी की उपलब्धता काफ़ी कम रहती है. किसी गलती को मैनेज करने के लिए, रिज़ॉल्वर को कम से कम एक सर्वर से बात करनी होगी. हालांकि, अक्सर दो या उससे ज़्यादा बाहरी नेम सर्वर से बात करनी होती है. Googlebot के वेब क्रॉलर को ऑपरेट करने के दौरान, हमें उन सर्वर के लिए औसतन 130 मि॰से॰ का समय मिला जो जवाब देते हैं. हालांकि, यूडीपी पैकेट खोने और सर्वर के पास न पहुंचने की वजह से, पूरे 4 से 6% अनुरोध टाइम आउट हो जाते हैं. अगर हम पैकेट हानि, इस्तेमाल न किए गए नाम सर्वर, डीएनएस कॉन्फ़िगरेशन गड़बड़ियों वगैरह पर ध्यान देते हैं, तो एंड-टू-एंड रिज़ॉल्यूशन का औसत 300-400 मि॰से॰ का होता है. हालांकि, इसमें ज़्यादा उतार-चढ़ाव होता है और एक लंबी पूंछ होती है.
डीएनएस सर्वर के कैश मेमोरी में सेव होने की दर अलग-अलग हो सकती है. हालांकि, इन वजहों से कैश मेमोरी के छूटने की संभावना बहुत कम होती है:
- इंटरनेट का साइज़ और बढ़ोतरी. साफ़ तौर पर, नए उपयोगकर्ताओं के साथ-साथ नई साइटों के साथ-साथ, जैसे-जैसे इंटरनेट का विकास होता है, वैसे-वैसे ज़्यादातर कॉन्टेंट का कुछ ही इस्तेमाल होता है. हालांकि, कुछ साइटों (और इस वजह से डीएनएस के नाम) बहुत लोकप्रिय हैं, लेकिन ज़्यादातर साइटों का ऐक्सेस कुछ ही उपयोगकर्ताओं के पास होता है और इन्हें बहुत कम ऐक्सेस किया जाता है. इसलिए, ज़्यादातर अनुरोधों की वजह से कैश मेमोरी में सेव नहीं किया जाता.
- टाइम-टू-लिव (टीटीएल) वैल्यू कम है. कम डीएनएस TTL (टीटीएल) वैल्यू के लिए रुझान का मतलब है कि रिज़ॉल्यूशन ज़्यादा बार देखे जाने चाहिए.
- कैश आइसोलेशन. आम तौर पर, डीएनएस सर्वर को लोड बैलेंसर के पीछे डिप्लॉय किया जाता है, जो बिना किसी क्रम के अलग-अलग मशीनों को क्वेरी असाइन करते हैं. इस वजह से, हर सर्वर अलग कैश मेमोरी में सेव रहता है. हालांकि, शेयर किए गए पूल से कैश मेमोरी में सेव किए गए रिज़ॉल्यूशन का दोबारा इस्तेमाल नहीं किया जा सकता.
गड़बड़ी की गंभीरता को कम करना
Google की सार्वजनिक डीएनएस सेवा में, हमने डीएनएस लुकअप समय को कम करने के लिए कई तरीके अपनाए हैं. इनमें से कुछ तरीके काफ़ी हद तक स्टैंडर्ड हैं. कुछ प्रयोग प्रयोग के तौर पर किए जाते हैं:
- नुकसान पहुंचाने वाले ट्रैफ़िक के साथ-साथ क्लाइंट ट्रैफ़िक से लोड को मैनेज करने के लिए, सर्वर का सही तरीके से प्रावधान करना.
- डीओएस और एम्प्लफ़िकेशन हमलों को रोकना. हालांकि, यह ज़्यादातर सुरक्षा से जुड़ी समस्या होती है, लेकिन इसका समाधान उन समाधानों पर कम होता है जो सबके लिए उपलब्ध हैं. साथ ही, डीओएस पर रोक लगाने से परफ़ॉर्मेंस पर भी असर पड़ता है. ऐसा डीएनएस सर्वर पर लगने वाले अतिरिक्त ट्रैफ़िक को हटाकर होता है. उन हमलों के बारे में ज़्यादा जानकारी के लिए जिन पर हम हमला कर रहे हैं, सुरक्षा से जुड़े फ़ायदे वाला पेज देखें.
- शेयर किए गए कैश के साथ लोड संतुलन, ताकि दिखाए गए क्लस्टर में एग्रीगेट की गई कैश हिट की दर में सुधार हो सके.
- सभी उपयोगकर्ताओं से निकटता के साथ दुनिया भर में कवरेज देना.
क्लस्टर बनाने की प्रक्रिया काफ़ी तरीके से की जा रही है
कैशिंग डीएनएस रिज़ॉल्वर को आधिकारिक नाम सर्वर की तुलना में ज़्यादा महंगे काम करने पड़ते हैं, क्योंकि कई जवाबों को मेमोरी से दिखाया नहीं जा सकता; इसके बजाय, उन्हें दूसरे नाम सर्वर के साथ बातचीत करने की ज़रूरत पड़ती है और इस तरह बहुत सारे नेटवर्क इनपुट/आउटपुट की मांग करनी पड़ती है. इसके अलावा, ओपन रिज़ॉल्वर से कैश पॉइज़निंग की कोशिशों का खतरा बहुत ज़्यादा होता है. इससे कैश मेमोरी में जगह छोड़ने की दर बढ़ जाती है (जैसे कि वे हमले खास तौर पर उन नकली नामों के लिए भेजे जाते हैं जिन्हें कैश मेमोरी से हल नहीं किया जा सकता) और 'डीओएस' हमले, जो ट्रैफ़िक लोड में जुड़ जाते हैं. अगर रिज़ॉल्वर का प्रावधान काफ़ी नहीं है और वे लोड के साथ काम नहीं कर पाते, तो परफ़ॉर्मेंस पर खराब असर पड़ सकता है. पैकेट छूट जाते हैं और उन्हें फिर से ट्रांसफ़र करना पड़ता है. इसलिए, नाम सर्वर के अनुरोधों को सूची में जोड़ना ज़रूरी है. इन सभी वजहों से देरी होती है.
इसलिए, ज़्यादा वॉल्यूम वाले इनपुट/आउटपुट के लिए डीएनएस रिज़ॉल्वर का प्रावधान करना ज़रूरी है. इसमें संभावित डीडीओएस हमलों को हैंडल करना शामिल है, जिनके लिए कई मशीनों पर ओवर-प्रोविज़निंग का एक ही तरीका कारगर है. हालांकि, यह ज़रूरी है कि मशीन जोड़ते समय कैश हिट रेट कम न किया जाए. इसके लिए, लोडिंग में असरदार तरीके से बदलाव करने की नीति लागू करना ज़रूरी है, जिसके बारे में हमने नीचे बताया है.
शेयर की गई कैश मेमोरी का लोड बैलेंस
मशीनों को जोड़कर रिज़ॉल्वर इंफ़्रास्ट्रक्चर को बढ़ाने से, असल में कैश हिट हिट की दर कम हो सकती है, अगर लोड बैलेंस ठीक से नहीं किया गया हो. किसी सामान्य डिप्लॉयमेंट में, कई मशीनें एक लोड बैलेंसर के पीछे बैठती हैं, जो राउंड रॉबिन जैसे आसान एल्गोरिदम का इस्तेमाल करके, हर मशीन पर ट्रैफ़िक को बराबर बांटता है. इसका नतीजा यह होता है कि हर मशीन अपनी अलग कैश मेमोरी बनाती है, ताकि कैश मेमोरी में सेव किया गया कॉन्टेंट, मशीनों पर अलग रखा जा सके. अगर आने वाली हर क्वेरी को रैंडम मशीन पर बांटा जाता है, तो ट्रैफ़िक के हिसाब से, कैश मेमोरी में सेव न होने की दर को बराबर-बराबर बढ़ाया जा सकता है. उदाहरण के लिए, लंबी TTL (टीटीएल) वाले नामों के लिए, जिन क्वेरी का बार-बार अनुरोध किया जाता है उनके लिए कैश मेमोरी में छूट की दर, क्लस्टर में मशीनों की संख्या से बढ़ सकती है. (बहुत कम TTL (टीटीएल) वाले नामों के लिए, जिनकी क्वेरी बहुत कम बार की जाती है या जिनके वजह से कैश मेमोरी में सेव नहीं की गई क्वेरी (0 TTL (टीटीएल) और गड़बड़ियां) होती हैं.
कैशेबल नामों की हिट दर बढ़ाने के लिए, यह सर्वर की लोड-बैलेंस ज़रूरी है, ताकि कैश को फ़्रैगमेंट न किया जा सके. Google की सार्वजनिक डीएनएस सेवा में, हमारे पास कैशिंग के दो लेवल होते हैं. मशीनों के एक पूल में, उपयोगकर्ता के काफ़ी पास, हर मशीन पर कैश मेमोरी सबसे लोकप्रिय नामों में होती है. अगर क्वेरी को इस कैश मेमोरी से संतुष्ट नहीं किया जा सकता, तो इसे मशीन के किसी दूसरे पूल पर भेज दिया जाता है. इसमें कैश मेमोरी को, नाम के हिसाब से अलग-अलग किया जाता है. दूसरे स्तर की कैश मेमोरी के लिए, एक ही नाम की सभी क्वेरी एक ही मशीन पर भेजी जाती हैं, जिसमें नाम को कैश मेमोरी में सेव किया जाता है या जो't होता है.
बड़े भौगोलिक कवरेज के लिए सर्विंग क्लस्टर बांटना
बंद किए गए रिज़ॉल्वर के लिए, यह कोई समस्या नहीं है. खुले रिज़ॉल्वर के लिए, आपके सर्वर आपके उपयोगकर्ताओं के जितने करीब होंगे, वे क्लाइंट के स्तर पर उतने ही कम समय में दिखेंगे. इसके अलावा, ज़रूरत के हिसाब से भौगोलिक कवरेज होने से, इंतज़ार के समय में सुधार होता है, क्योंकि नाम सर्वर आम तौर पर, डीएनएस रिज़ॉल्वर और उनकी जगह की जानकारी के हिसाब से ऑप्टिमाइज़ किए गए नतीजे दिखाते हैं. इसका मतलब है कि अगर कॉन्टेंट देने वाली कंपनी, दुनिया भर की डुप्लीकेट साइटों को होस्ट करती है, तो उस कंपनी के नाम सर्वर, डीएनएस रिज़ॉल्वर के आस-पास मौजूद आईपी पते को दिखाएंगे.
Google की सार्वजनिक डीएनएस सेवा, दुनिया भर में मौजूद डेटा सेंटर में होस्ट की गई है. यह उपयोगकर्ताओं को भौगोलिक रूप से सबसे नज़दीकी डेटा सेंटर पर भेजने के लिए, किसी भी कास्ट रूटिंग का इस्तेमाल करती है.
इसके अलावा, Google की सार्वजनिक डीएनएस सेवा, EDNS क्लाइंट सबनेट (ईसीएस) के साथ काम करती है. यह रिज़ॉल्वर के लिए डीएनएस प्रोटोकॉल एक्सटेंशन है, जो नाम सर्वर को क्लाइंट लोकेशन पर फ़ॉरवर्ड करता है. इससे, रिज़ॉल्वर के आईपी पते के बजाय, असल क्लाइंट के आईपी पते के लिए ऑप्टिमाइज़ की गई जगह के हिसाब से संवेदनशील रिस्पॉन्स मिल सकता है. ज़्यादा जानकारी के लिए, कृपया अक्सर पूछे जाने वाले सवाल पढ़ें. Google Public DNS अपने-आप नाम सर्वर का पता लगाता है जो EDNS क्लाइंट सबनेट का समर्थन करता है.