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

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

कैशिंग कुशल है? कुछ साल पहले, मेरे छोटे शोध से पता चला कि यह बिल्कुल सही नहीं था। वर्तमान स्थिति पर एक नज़र डालें।

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

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



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



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



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



0 से 5 मिनट तक का विशाल बहुमत:



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

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



डीएनएस प्रतिक्रियाओं के आधे में, टीटीएल 1 मिनट या उससे कम है, और तीन तिमाहियों में 5 मिनट या उससे कम है।

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

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

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



X अक्ष TTL है, Y अक्ष क्वेरी लोकप्रियता है।

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

ज़ूम इन करें:



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

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

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

ऐसा क्यों?

DNS रिकॉर्ड्स के लिए इतना छोटा TTL सेट क्यों है?

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

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

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

CDN सेवाएं और लोड बैलेंसर्स मोटे तौर पर कम TTL के लिए दोषी हैं, खासकर जब वे CNAME को छोटे TTLs और समान छोटे (लेकिन स्वतंत्र) TTLs के साथ जोड़ते हैं:

  $ ड्रिल raw.githubusercontent.com
 raw.githubusercontent.com।  9 CNAME github.map.fastly.net पर।
 github.map.fastly.net।  20 इन 151.101.128.133
 github.map.fastly.net।  20 इन 151.101.192.133
 github.map.fastly.net।  20 इन 151.101.0.133
 github.map.fastly.net।  20 इन 151.101.64.133 

जब भी कोई CNAME या A रिकॉर्ड समाप्त होता है, तो आपको एक नया अनुरोध भेजना होगा। दोनों में 30 सेकंड का TTL है, लेकिन यह मेल नहीं खाता। वास्तविक औसत TTL 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 

Level3 रिज़ॉल्वर संभवतः BIND पर काम करता है। यदि आप यह अनुरोध भेजते रहते हैं, तो 1 का टीटीएल हमेशा वापस आ जाएगा। अनिवार्य रूप से, raw.githubusercontent.com कभी भी कैश नहीं किया जाता है।

इस तरह की स्थिति का एक और उदाहरण एक बहुत लोकप्रिय डोमेन के साथ है:

  $ ड्रिल डिटेलपोर्ट.फायरफॉक्स डॉट कॉम @ 1.1.1.1
 detectportal.firefox.com।  25 CNAME detectportal.prod.mozaws.net पर।
 detectportal.prod.mozaws.net।  26 CNAME में Detportal.firefox.com-v2.edgesuite.net।
 detectportal.firefox.com-v2.edgesuite.net।  10668 CNAME में a1089.dscd.akamai.net
 a1089.dscd.akamai.net।  10 एक 104.123.50.106 में
 a1089.dscd.akamai.net।  10 एक 104.123.50.88 में 

कम से कम तीन CNAME रिकॉर्ड। ऐ। एक में एक सभ्य टीटीएल है, लेकिन यह पूरी तरह से बेकार है। अन्य CNAME में, प्रारंभिक TTL 60 सेकंड है, लेकिन akamai.net डोमेन के लिए akamai.net अधिकतम TTL 20 सेकंड है, और उनमें से कोई भी चरण में नहीं है।

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

  $ ड्रिल 1-courier.push.apple.com @ 4.2.2.2
 1-courier.push.apple.com।  1253 CNAME में 1.courier-push-apple.com.akadns.net
 1.courier-push-apple.com.akadns.net।  1 CNAME gb-courier-4.push-apple.com.akadns.net पर।
 gb-courier-4.push-apple.com.akadns.net।  1 इन 17.57.146.84
 gb-courier-4.push-apple.com.akadns.net।  1 इन 17.57.146.85 

वही समस्या जो फ़ायरफ़ॉक्स में है, और टीटीएल लेवल 3 रिज़ॉल्वर का उपयोग करते समय अधिकांश समय 1 सेकंड के लिए अटक जाएगी।

ड्रॉपबॉक्स?

  $ ड्रिल client.dropbox.com @ 8.8.8.8
 client.dropbox.com।  7 CNAME client.dropbox-dns.com पर।
 client.dropbox-dns.com।  59 इन ए 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 सेकंड safebrowsing.googleapis.com एक टीटीएल है। और, फिर से, ग्राहक के दृष्टिकोण से, इन मूल्यों को आधा कर दिया जाता है।

एक न्यूनतम टीटीएल स्थापित करने के बारे में कैसे?

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

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

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



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

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

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

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



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

इस न्यूनतम परिवर्तन का प्रभाव बहुत बड़ा है।

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

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

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

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

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

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

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

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