कम DNS विलंबता तेज़ ब्राउज़िंग के लिए एक महत्वपूर्ण कारक है। इसे कम करने के लिए, DNS सर्वरों का सावधानीपूर्वक चयन करना महत्वपूर्ण है लेकिन सबसे पहले आपको बेकार के प्रश्नों से छुटकारा पाना होगा।
यही कारण है कि DNS को मूल रूप से एक अत्यधिक कैशेबल प्रोटोकॉल के रूप में डिज़ाइन किया गया था। ज़ोन प्रशासक व्यक्तिगत रिकॉर्ड के लिए एक समय सीमा (TTL) निर्धारित करते हैं, और रिज़ॉल्वर अनावश्यक ट्रैफ़िक से बचने के लिए मेमोरी में रिकॉर्ड संग्रहीत करते समय इस जानकारी का उपयोग करते हैं।
क्या कैशिंग प्रभावी है? कुछ साल पहले, मेरे छोटे से शोध से पता चला कि यह सही नहीं है। आइए वर्तमान स्थिति पर नज़र डालें।
जानकारी एकत्र करने के लिए मैंने पैच लगाया प्रतिक्रिया के लिए TTL मान संग्रहीत करने के लिए। इसे प्रत्येक आने वाले अनुरोध के लिए, इसके रिकॉर्ड के न्यूनतम TTL के रूप में परिभाषित किया गया है। यह वास्तविक ट्रैफ़िक के TTL वितरण का एक अच्छा अवलोकन देता है, और व्यक्तिगत अनुरोधों की लोकप्रियता को भी ध्यान में रखता है। सर्वर का पैच किया गया संस्करण कई घंटों तक काम करता रहा।
परिणामी डेटासेट में 1 रिकॉर्ड (नाम, क्यूटाइप, टीटीएल, टाइमस्टैम्प) शामिल हैं। यहाँ समग्र टीटीएल वितरण है (x-अक्ष सेकंड में टीटीएल है):
86 (ज्यादातर SOA रिकॉर्ड के लिए) पर मामूली उछाल के अलावा, यह बहुत स्पष्ट है कि TTL कम रेंज में हैं। आइए करीब से देखें:
ठीक है, 1 घंटे से ज़्यादा के TTL सांख्यिकीय रूप से महत्वहीन हैं। तो चलिए 0-3600 रेंज पर ध्यान केंद्रित करते हैं:
अधिकांश TTL 0 से 15 मिनट के बीच होते हैं:
अधिकांश 0 से 5 मिनट तक के हैं:
यह बहुत अच्छा नहीं है.
संचयी वितरण समस्या को और भी अधिक स्पष्ट कर देता है:
आधे DNS प्रत्युत्तरों की TTL 1 मिनट या उससे कम होती है, तथा तीन-चौथाई की TTL 5 मिनट या उससे कम होती है।
लेकिन रुकिए, यह वास्तव में बदतर है। यह आधिकारिक सर्वर से TTL है। हालाँकि, क्लाइंट रिज़ॉल्वर (जैसे राउटर, स्थानीय कैश) अपस्ट्रीम रिज़ॉल्वर से TTL प्राप्त करते हैं, और यह हर सेकंड घटता है।
इस प्रकार, क्लाइंट नया अनुरोध भेजने से पहले प्रत्येक रिकॉर्ड का औसतन मूल TTL का आधा भाग उपयोग कर सकता है।
हो सकता है कि ये बहुत कम TTL केवल असामान्य अनुरोधों को प्रभावित करते हों, न कि लोकप्रिय वेबसाइटों और API को? आइए एक नज़र डालते हैं:
X-अक्ष TTL है, Y-अक्ष क्वेरी लोकप्रियता है।
दुर्भाग्यवश, सर्वाधिक लोकप्रिय क्वेरीज़ का कैश सबसे खराब होता है।
आइये ज़ूम इन करें:
फैसला: यह वाकई बहुत बुरा है। यह पहले से ही बुरा था, और यह और भी बुरा हो गया है। DNS कैशिंग लगभग बेकार हो गई है। चूंकि कम लोग अपने ISP के DNS रिज़ॉल्वर का इस्तेमाल करते हैं (अच्छे कारणों से), इसलिए विलंबता में वृद्धि अधिक ध्यान देने योग्य होती जा रही है।
DNS कैशिंग केवल उस सामग्री के लिए उपयोगी हो गई है, जिसे कोई नहीं देखता।
कृपया यह भी ध्यान रखें कि सॉफ्टवेयर कम टीटीएल की व्याख्या करें।
ऐसा क्यों?
DNS रिकॉर्ड्स को इतने छोटे TTL पर क्यों सेट किया जाता है?
- लीगेसी लोड बैलेंसर्स को डिफ़ॉल्ट सेटिंग्स के साथ छोड़ दिया जाता है।
- ऐसी भ्रांतियां हैं कि DNS लोड संतुलन TTL पर निर्भर करता है (यह सच नहीं है - नेटस्केप नेविगेटर के बाद से, क्लाइंट RR सेट से एक यादृच्छिक IP पता चुनते हैं और यदि वे कनेक्ट नहीं कर पाते हैं तो पारदर्शी रूप से दूसरा प्रयास करते हैं)
- प्रशासक परिवर्तन तुरंत लागू करना चाहते हैं, ताकि योजना बनाना आसान हो।
- DNS सर्वर या लोड बैलेंसर का प्रशासक अपना कार्य उपयोगकर्ताओं द्वारा अनुरोधित कॉन्फ़िगरेशन को कुशलतापूर्वक लागू करने के रूप में देखता है, न कि साइटों और सेवाओं के संचालन को गति देने के रूप में।
- कम टीटीएल मन को शांति देता है।
- लोग शुरू में परीक्षण के लिए कम TTL निर्धारित करते हैं और फिर उसे बदलना भूल जाते हैं।
मैंने "फेलओवर" को शामिल नहीं किया क्योंकि यह कम और कम प्रासंगिक होता जा रहा है। यदि आपको उपयोगकर्ताओं को किसी अन्य नेटवर्क पर रीडायरेक्ट करने की आवश्यकता है, तो केवल एक त्रुटि पृष्ठ प्रदर्शित करने के लिए जब बाकी सब कुछ टूटा हुआ है, तो 1 मिनट से अधिक की देरी संभवतः स्वीकार्य है।
इसके अतिरिक्त, एक मिनट के TTL का मतलब है कि यदि आधिकारिक DNS सर्वर 1 मिनट से अधिक समय तक अवरुद्ध हैं, तो कोई भी अन्य व्यक्ति आश्रित सेवाओं तक नहीं पहुँच पाएगा। और यदि कारण कॉन्फ़िगरेशन त्रुटि या हैक है, तो अतिरेक मदद नहीं करेगा। दूसरी ओर, उचित TTL के साथ, कई क्लाइंट पिछले कॉन्फ़िगरेशन का उपयोग करना जारी रखेंगे और कभी ध्यान नहीं देंगे।
कम TTL का दोष मुख्यतः CDN सेवाओं और लोड बैलेंसरों का है, विशेष रूप से तब जब वे CNAME को कम TTL और रिकॉर्ड को समान रूप से कम (लेकिन स्वतंत्र) TTL के साथ संयोजित करते हैं:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
हर बार जब CNAME या A रिकॉर्ड में से कोई भी समाप्त होता है, तो एक नया अनुरोध भेजना पड़ता है। दोनों का TTL 30 सेकंड है, लेकिन वे समान नहीं हैं। वास्तविक औसत TTL 15 सेकंड होगा।
लेकिन रुकिए! यह और भी बुरा हो जाता है। कुछ रिज़ॉल्वर दो लिंक्ड लो TTL के साथ इस स्थिति में बहुत खराब व्यवहार करते हैं:
$ ड्रिल raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
लेवल3 रिज़ॉल्वर संभवतः BIND पर चल रहा है। यदि आप यह क्वेरी भेजते रहेंगे, तो यह हमेशा 1 का TTL लौटाएगा। अनिवार्य रूप से, raw.githubusercontent.com कभी कैश नहीं किया गया.
यहाँ एक बहुत लोकप्रिय डोमेन के साथ इस स्थिति का एक और उदाहरण दिया गया है:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
कम से कम तीन CNAME रिकॉर्ड। ओह। एक का TTL ठीक-ठाक है, लेकिन यह पूरी तरह से बेकार है। अन्य CNAME का आरंभिक TTL 60 सेकंड का है, लेकिन डोमेन के लिए akamai.net अधिकतम TTL 20 सेकंड है और इनमें से कोई भी चरण में नहीं है।
उन डोमेन के बारे में क्या जो लगातार एप्पल डिवाइसों का सर्वेक्षण करते हैं?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
फ़ायरफ़ॉक्स जैसी ही समस्या है और लेवल 1 रिज़ॉल्वर का उपयोग करते समय TTL अधिकांश समय 3 सेकंड पर अटक जाता है।
ड्रॉपबॉक्स?
$ ड्रिल client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ ड्रिल client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
रिकॉर्डिंग के समय safebrowsing.googleapis.com फेसबुक डोमेन की तरह ही 60 सेकंड का TTL मान। और फिर, क्लाइंट के दृष्टिकोण से, ये मान आधे हो जाते हैं।
न्यूनतम टीटीएल निर्धारित करने के बारे में आपका क्या विचार है?
नाम, अनुरोध प्रकार, TTL, तथा मूलतः संग्रहीत टाइमस्टैम्प का उपयोग करते हुए, मैंने एक स्क्रिप्ट लिखी, जिसमें कैशिंग रिज़ॉल्वर से गुजरने वाले 1,5 मिलियन अनुरोधों का अनुकरण किया गया, ताकि समाप्त हो चुकी कैश प्रविष्टि के कारण भेजे गए अतिरिक्त अनुरोधों की मात्रा का अनुमान लगाया जा सके।
47,4% अनुरोध मौजूदा रिकॉर्ड की समाप्ति के बाद किए गए थे। यह अनुचित रूप से उच्च है।
यदि न्यूनतम TTL निर्धारित कर दिया जाए तो कैशिंग पर क्या प्रभाव पड़ेगा?
X-अक्ष न्यूनतम TTL मान है। इस मान से ऊपर कच्चे TTL वाले रिकॉर्ड प्रभावित नहीं होते हैं।
Y अक्ष उस क्लाइंट से प्राप्त अनुरोधों का प्रतिशत है, जिसमें पहले से ही कैश्ड प्रविष्टि है, लेकिन उसकी समय-सीमा समाप्त हो गई है और वह नया अनुरोध कर रहा है।
न्यूनतम TTL को 47 मिनट पर सेट करने से "अतिरिक्त" अनुरोधों की संख्या 36% से घटकर 5% हो जाती है। न्यूनतम TTL को 15 मिनट पर सेट करने से इन अनुरोधों की संख्या 29% तक कम हो जाती है। 1 घंटे का न्यूनतम TTL उन्हें 17% तक कम कर देता है। एक महत्वपूर्ण अंतर!
सर्वर साइड पर कुछ भी न बदलने के बजाय क्लाइंट DNS कैश (राउटर, स्थानीय रिज़ॉल्वर) में न्यूनतम TTL सेट करने के बारे में आपका क्या विचार है?
न्यूनतम TTL को 47 मिनट पर सेट करने पर आवश्यक अनुरोधों की संख्या 34% से घटकर 5% हो जाती है, न्यूनतम 25 मिनट पर 15% और न्यूनतम 13 घंटे पर 1% हो जाती है। शायद 40 मिनट इष्टतम है।
इस न्यूनतम परिवर्तन का प्रभाव बहुत बड़ा है।
निहितार्थ क्या हैं?
निश्चित रूप से, आप किसी सेवा को किसी नए क्लाउड प्रदाता, किसी नए सर्वर, किसी नए नेटवर्क पर माइग्रेट कर सकते हैं, और ग्राहकों को नवीनतम DNS रिकॉर्ड का उपयोग करने की आवश्यकता होती है। और एक छोटा सा TTL उस संक्रमण को सुचारू और निर्बाध बनाने में मदद करता है। लेकिन जब आप किसी नए इंफ्रास्ट्रक्चर पर माइग्रेट करते हैं, तो कोई भी यह उम्मीद नहीं करता है कि ग्राहक 1 मिनट, 5 मिनट या 15 मिनट के भीतर नए DNS रिकॉर्ड पर माइग्रेट हो जाएंगे। न्यूनतम TTL को 40 मिनट के बजाय 5 मिनट पर सेट करने से उपयोगकर्ताओं को सेवा तक पहुँचने से नहीं रोका जाएगा।
हालाँकि, इससे विलंबता में उल्लेखनीय कमी आएगी तथा अनावश्यक अनुरोधों से बचकर गोपनीयता और विश्वसनीयता में सुधार होगा।
बेशक, RFC का कहना है कि TTL को सख्ती से लागू किया जाना चाहिए। लेकिन वास्तविकता यह है कि DNS सिस्टम बहुत अक्षम हो गया है।
यदि आप आधिकारिक DNS सर्वर के साथ काम कर रहे हैं, तो कृपया अपने TTL की जाँच करें। क्या आपको वाकई इतने कम मानों की ज़रूरत है?
बेशक, DNS रिकॉर्ड्स के लिए छोटे TTL सेट करने के अच्छे कारण हैं। लेकिन 75% DNS ट्रैफ़िक के लिए नहीं, जिसमें मुश्किल से कोई बदलाव होता है।
और अगर किसी कारण से आपको DNS के लिए कम TTL का उपयोग करने की ज़रूरत है, तो यह भी सुनिश्चित करें कि आपकी साइट पर कैशिंग सक्षम नहीं है। उन्हीं कारणों से।
यदि आपके पास स्थानीय DNS कैश चल रहा है, जैसे , जो आपको न्यूनतम TTL सेट करने की अनुमति देता है, इस फ़ंक्शन का उपयोग करें। यह सामान्य है। कुछ भी बुरा नहीं होगा। न्यूनतम TTL को 40 मिनट (2400 सेकंड) और 1 घंटे के बीच कहीं सेट करें। एक उचित सीमा।
स्रोत: www.habr.com
