कम DNS विलंबता तेज़ इंटरनेट ब्राउज़िंग की कुंजी है। इसे कम करने के लिए, DNS सर्वरों का सावधानीपूर्वक चयन करना महत्वपूर्ण है अनाम रिले. लेकिन पहला कदम बेकार के प्रश्नों से छुटकारा पाना है।

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

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

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

परिणामी डेटा सेट में 1 रिकॉर्ड (नाम, क्यूटाइप, टीटीएल, टाइमस्टैम्प) शामिल हैं। यहां समग्र टीटीएल वितरण है (एक्स-अक्ष सेकंड में टीटीएल है):

86 (ज्यादातर एसओए रिकॉर्ड के लिए) पर मामूली उछाल के अलावा, यह बिल्कुल स्पष्ट है कि टीटीएल कम रेंज में हैं। आओ हम इसे नज़दीक से देखें:

ठीक है, 1 घंटे से अधिक के टीटीएल सांख्यिकीय रूप से महत्वपूर्ण नहीं हैं। तो आइए रेंज 0−3600 पर ध्यान केंद्रित करें:

अधिकांश टीटीएल 0 से 15 मिनट तक के होते हैं:

अधिकांश 0 से 5 मिनट तक हैं:

यह बहुत अच्छा नहीं है.

संचयी वितरण समस्या को और भी अधिक स्पष्ट कर देता है:

आधे DNS प्रतिक्रियाओं का TTL 1 मिनट या उससे कम है, और तीन चौथाई का TTL 5 मिनट या उससे कम है।

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

इसलिए ग्राहक वास्तव में नया अनुरोध भेजने से पहले प्रत्येक प्रविष्टि का उपयोग औसतन आधे मूल टीटीएल के लिए कर सकता है।

शायद ये बहुत कम टीटीएल केवल असामान्य अनुरोधों पर लागू होते हैं, लोकप्रिय वेबसाइटों और एपीआई पर नहीं? आइये एक नजर डालते हैं:

एक्स अक्ष टीटीएल है, वाई अक्ष क्वेरी लोकप्रियता है।

दुर्भाग्य से, सबसे लोकप्रिय क्वेरीज़ भी कैश करने के लिए सबसे खराब हैं।

आइए ज़ूम इन करें:

फैसला: यह वाकई बहुत बुरा है. यह पहले भी खराब था, लेकिन यह और भी खराब हो गया। DNS कैशिंग वस्तुतः बेकार हो गई है. चूँकि कम लोग अपने ISP के DNS रिज़ॉल्वर का उपयोग करते हैं (अच्छे कारणों से), विलंबता में वृद्धि अधिक ध्यान देने योग्य हो जाती है।

DNS कैशिंग केवल उस सामग्री के लिए उपयोगी हो गई है जिस पर कोई नहीं जाता।

कृपया यह भी ध्यान दें कि सॉफ़्टवेयर हो सकता है अलग-अलग तरीकों से कम टीटीएल की व्याख्या करें।

ऐसा क्यों?

DNS रिकॉर्ड इतने कम TTL पर क्यों सेट किए गए हैं?

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

मैंने सूची में "फ़ेलओवर" को शामिल नहीं किया क्योंकि यह कम प्रासंगिक होता जा रहा है। यदि आपको केवल एक त्रुटि पृष्ठ प्रदर्शित करने के लिए उपयोगकर्ताओं को किसी अन्य नेटवर्क पर रीडायरेक्ट करने की आवश्यकता है, जबकि बाकी सब कुछ पूरी तरह से टूटा हुआ है, तो 1 मिनट से अधिक की देरी संभवतः स्वीकार्य है।

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

कम टीटीएल के लिए सीडीएन सेवाएं और लोड बैलेंसर काफी हद तक जिम्मेदार हैं, खासकर जब वे सीएनएएमई को कम टीटीएल के साथ जोड़ते हैं और रिकॉर्ड को समान रूप से कम (लेकिन स्वतंत्र) टीटीएल के साथ जोड़ते हैं:

$ 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 रिकॉर्ड समाप्त होता है, तो एक नया अनुरोध भेजा जाना चाहिए। दोनों के पास 30 सेकंड का टीटीएल है, लेकिन यह समान नहीं है। वास्तविक औसत टीटीएल 15 सेकंड होगा।

पर रुको! यह और भी बुरा है. कुछ रिज़ॉल्वर इस स्थिति में दो संबद्ध निम्न टीटीएल के साथ बहुत बुरा व्यवहार करते हैं:

$ ड्रिल raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com। 1 CNAME में github.map.fastly.net। github.map.fastly.net. 1 इन ए 151.101.16.133

लेवल3 रिज़ॉल्वर संभवतः BIND पर चलता है। यदि आप यह अनुरोध भेजना जारी रखते हैं, तो 1 का टीटीएल हमेशा लौटाया जाएगा। अनिवार्य रूप से, 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 रिकॉर्ड. अय. एक के पास अच्छा टीटीएल है, लेकिन यह पूरी तरह से बेकार है। अन्य CNAME में 60 सेकंड का प्रारंभिक TTL होता है, लेकिन डोमेन के लिए akamai.net अधिकतम टीटीएल 20 सेकंड है और उनमें से कोई भी चरण में नहीं है।

उन डोमेन के बारे में क्या जो लगातार Apple उपकरणों को प्रदूषित करते हैं?

$ 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 रिज़ॉल्वर का उपयोग करते समय फ़ायरफ़ॉक्स और टीटीएल जैसी ही समस्या अधिकांश समय 3 सेकंड पर अटकी रहेगी।

ड्रॉपबॉक्स?

$ ड्रिल client.dropbox.com @8.8.8.8 client.dropbox.com। 7 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 CNAME client.dropbox-dns.com में। client.dropbox-dns.com। 1 इन ए 162.125.64.3

रिकॉर्डिंग में safebrowsing.googleapis.com टीटीएल मान फेसबुक डोमेन की तरह 60 सेकंड है। और, फिर से, ग्राहक के दृष्टिकोण से, ये मान आधे हो गए हैं।

न्यूनतम टीटीएल निर्धारित करने के बारे में आपका क्या ख़याल है?

नाम, अनुरोध प्रकार, टीटीएल और मूल रूप से संग्रहीत टाइमस्टैम्प का उपयोग करके, मैंने एक समाप्त कैश प्रविष्टि के कारण भेजे गए अनावश्यक अनुरोधों की मात्रा का अनुमान लगाने के लिए कैशिंग रिज़ॉल्वर से गुजरने वाले 1,5 मिलियन अनुरोधों का अनुकरण करने के लिए एक स्क्रिप्ट लिखी।

47,4% अनुरोध मौजूदा रिकॉर्ड समाप्त होने के बाद किए गए थे। यह अनुचित रूप से अधिक है.

यदि न्यूनतम टीटीएल निर्धारित किया जाता है तो कैशिंग पर क्या प्रभाव पड़ेगा?

एक्स अक्ष न्यूनतम टीटीएल मान है। इस मान से ऊपर स्रोत टीटीएल वाले रिकॉर्ड प्रभावित नहीं होते हैं।

Y अक्ष उस क्लाइंट के अनुरोधों का प्रतिशत है जिसके पास पहले से ही कैश्ड प्रविष्टि है, लेकिन उसकी समय सीमा समाप्त हो गई है और वह एक नया अनुरोध कर रहा है।

न्यूनतम टीटीएल को 47 मिनट पर सेट करने से "अतिरिक्त" अनुरोधों का हिस्सा 36% से घटकर 5% हो जाता है। न्यूनतम टीटीएल को 15 मिनट पर सेट करने से, इन अनुरोधों की संख्या 29% तक कम हो जाती है। 1 घंटे का न्यूनतम टीटीएल उन्हें घटाकर 17% कर देता है। महत्वपूर्ण अंतर!

सर्वर साइड पर कुछ भी न बदलने, बल्कि क्लाइंट डीएनएस कैश (राउटर, स्थानीय रिज़ॉल्वर) में न्यूनतम टीटीएल सेट करने के बारे में क्या ख्याल है?

आवश्यक अनुरोधों की संख्या 47 मिनट के न्यूनतम टीटीएल के साथ 34% से घटकर 5%, न्यूनतम 25 मिनट के साथ 15% और न्यूनतम 13 घंटे के साथ 1% हो जाती है। शायद 40 मिनट इष्टतम है.

इस छोटे से परिवर्तन का प्रभाव बहुत बड़ा है।

निहितार्थ क्या हैं?

बेशक, सेवा को एक नए क्लाउड प्रदाता, नए सर्वर, नए नेटवर्क में ले जाया जा सकता है, जिसके लिए ग्राहकों को नवीनतम DNS रिकॉर्ड का उपयोग करने की आवश्यकता होगी। और एक काफी छोटा टीटीएल ऐसे परिवर्तन को सुचारू रूप से और अदृश्य रूप से करने में मदद करता है। लेकिन नए बुनियादी ढांचे में बदलाव के साथ, कोई भी यह उम्मीद नहीं करता है कि ग्राहक 1 मिनट, 5 मिनट या 15 मिनट के भीतर नए DNS रिकॉर्ड में स्थानांतरित हो जाएंगे। न्यूनतम टीटीएल को 40 मिनट के बजाय 5 मिनट पर सेट करने से उपयोगकर्ताओं को सेवा तक पहुंचने से नहीं रोका जा सकेगा।

हालाँकि, इससे विलंबता में काफी कमी आएगी और अनावश्यक अनुरोधों से बचकर गोपनीयता और विश्वसनीयता में सुधार होगा।

बेशक, आरएफसी का कहना है कि टीटीएल का सख्ती से पालन किया जाना चाहिए। लेकिन वास्तविकता यह है कि डीएनएस प्रणाली बहुत अक्षम हो गई है।

यदि आप आधिकारिक डीएनएस सर्वर के साथ काम कर रहे हैं, तो कृपया अपने टीटीएल की जांच करें। क्या आपको सचमुच ऐसे हास्यास्पद निम्न मूल्यों की आवश्यकता है?

बेशक, डीएनएस रिकॉर्ड के लिए छोटे टीटीएल सेट करने के अच्छे कारण हैं। लेकिन 75% DNS ट्रैफ़िक के लिए नहीं जो वस्तुतः अपरिवर्तित रहता है।

और यदि किसी कारण से आपको वास्तव में DNS के लिए कम टीटीएल का उपयोग करने की आवश्यकता है, तो उसी समय सुनिश्चित करें कि आपकी साइट पर कैशिंग सक्षम नहीं है। उन्हीं कारणों से.

यदि आपके पास स्थानीय DNS कैश चल रहा है, जैसे कि dnscrypt-प्रॉक्सीजो आपको न्यूनतम टीटीएल सेट करने की अनुमति देता है, इस फ़ंक्शन का उपयोग करें। यह ठीक है। कुछ भी बुरा नहीं होगा. न्यूनतम टीटीएल को लगभग 40 मिनट (2400 सेकंड) और 1 घंटे पर सेट करें। काफी उचित रेंज.

स्रोत: www.habr.com