छिटो ब्राउजिङको लागि कम DNS विलम्बता एक प्रमुख कारक हो। यसलाई कम गर्न, DNS सर्भरहरू सावधानीपूर्वक चयन गर्नु महत्त्वपूर्ण छ र बेनामी रिलेहरूतर तपाईंले गर्नुपर्ने पहिलो कुरा भनेको बेकारका प्रश्नहरूबाट छुटकारा पाउनु हो।

यसैकारण DNS लाई मूल रूपमा उच्च क्यास गर्न मिल्ने प्रोटोकलको रूपमा डिजाइन गरिएको थियो। जोन प्रशासकहरूले व्यक्तिगत रेकर्डहरूको लागि लाइभ गर्न समय (TTL) सेट गर्छन्, र रिजल्भरहरूले अनावश्यक ट्राफिकबाट बच्न मेमोरीमा रेकर्डहरू भण्डारण गर्दा यो जानकारी प्रयोग गर्छन्।

के क्यासिङ प्रभावकारी छ? केही वर्ष पहिले, मेरो सानो अनुसन्धानले यो उत्तम छैन भनेर देखाएको थियो। अहिलेको अवस्था हेरौं।

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

परिणामस्वरूप डेटासेटमा १,५८३,५७९ रेकर्डहरू छन् (नाम, qtype, TTL, टाइमस्ट्याम्प)। यहाँ समग्र TTL वितरण छ (x-अक्ष सेकेन्डमा TTL हो):

८६,४०० मा थोरै वृद्धि (प्रायः SOA रेकर्डहरूको लागि) बाहेक, यो स्पष्ट छ कि TTL हरू कम दायरामा छन्। नजिकबाट हेरौं:

ठीक छ, १ घण्टाभन्दा बढीको TTL हरू तथ्याङ्कीय रूपमा नगण्य छन्। त्यसो भए ०-३६०० दायरामा ध्यान केन्द्रित गरौं:

धेरैजसो TTL हरू ० देखि १५ मिनेटका बीचमा हुन्छन्:

धेरैजसो ० देखि ५ मिनेटसम्मका छन्:

यो धेरै राम्रो होइन।

संचयी वितरणले समस्यालाई अझ स्पष्ट बनाउँछ:

आधा DNS प्रतिक्रियाहरूको TTL १ मिनेट वा कम हुन्छ, र तीन-चौथाईको TTL ५ मिनेट वा कम हुन्छ।

तर पर्खनुहोस्, यो वास्तवमा झनै खराब छ। यो आधिकारिक सर्भरहरूबाट TTL हो। यद्यपि, क्लाइन्ट रिजल्भरहरू (जस्तै राउटरहरू, स्थानीय क्यासहरू) ले अपस्ट्रीम रिजल्भरहरूबाट TTL प्राप्त गर्छन्, र यो प्रत्येक सेकेन्डमा घट्छ।

यसरी, ग्राहकले नयाँ अनुरोध पठाउनु अघि प्रत्येक रेकर्डलाई औसतमा, मूल TTL को आधाको लागि प्रयोग गर्न सक्छ।

सायद यी धेरै कम TTL हरूले असामान्य अनुरोधहरूलाई मात्र असर गर्छन् र लोकप्रिय वेबसाइटहरू र API हरूलाई होइन? एक नजर राखौं:

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

दुर्भाग्यवश, सबैभन्दा लोकप्रिय प्रश्नहरू पनि सबैभन्दा खराब क्यास गरिएका हुन्छन्।

जुम इन गरौं:

फैसला: यो साँच्चै नराम्रो छ। यो पहिले नै नराम्रो थियो, र यो झन् खराब हुँदै गएको छ। DNS क्यासिङ लगभग बेकार भएको छ। कम मानिसहरूले आफ्नो ISP को DNS रिजल्भर प्रयोग गर्दा (राम्रो कारणले गर्दा), विलम्बतामा वृद्धि बढी देखिन थालेको छ।

DNS क्यासिङ केवल त्यस्ता सामग्रीको लागि उपयोगी भएको छ जुन कसैले पनि भ्रमण गर्दैन।

कृपया यो पनि ध्यान दिनुहोस् कि सफ्टवेयरले विभिन्न तरिकामा कम TTL हरूको व्याख्या गर्नुहोस्।

किन त्यसो

DNS रेकर्डहरू किन यति सानो TTL मा सेट गरिन्छ?

• लिगेसी लोड ब्यालेन्सरहरू पूर्वनिर्धारित सेटिङहरूसँग बाँकी छन्।
• DNS लोड ब्यालेन्सिङ TTL मा निर्भर गर्दछ भन्ने भ्रमहरू छन् (यो सत्य होइन - नेटस्केप नेभिगेटरको रूपमा, क्लाइन्टहरूले RR सेटबाट अनियमित IP ठेगाना छान्छन् र यदि तिनीहरू जडान गर्न सक्दैनन् भने पारदर्शी रूपमा अर्को प्रयास गर्छन्)
• प्रशासकहरू परिवर्तनहरू तुरुन्तै लागू गर्न चाहन्छन्, त्यसैले योजना बनाउन सजिलो हुन्छ।
• DNS सर्भर वा लोड ब्यालेन्सरको प्रशासकले आफ्नो कामलाई प्रयोगकर्ताहरूले अनुरोध गरेको कन्फिगरेसनलाई कुशलतापूर्वक तैनाथ गर्ने र साइटहरू र सेवाहरूको सञ्चालनलाई गति दिने होइन भनेर देख्छ।
• कम TTL ले मनको शान्ति दिन्छ।
• मानिसहरूले सुरुमा परीक्षणको लागि कम TTL सेट गर्छन् र त्यसपछि तिनीहरूलाई परिवर्तन गर्न बिर्सन्छन्।

मैले "फेइलओभर" समावेश गरिनँ किनभने यो कम र कम सान्दर्भिक हुँदै गइरहेको छ। यदि तपाईंले सबै कुरा बिग्रिएको बेला त्रुटि पृष्ठ प्रदर्शन गर्न प्रयोगकर्ताहरूलाई अर्को नेटवर्कमा रिडिरेक्ट गर्न आवश्यक छ भने, १ मिनेट भन्दा बढीको ढिलाइ सम्भवतः स्वीकार्य छ।

थप रूपमा, एक मिनेटको TTL को अर्थ यदि आधिकारिक DNS सर्भरहरू १ मिनेट भन्दा बढीको लागि ब्लक गरिएको छ भने, अरू कसैले पनि आश्रित सेवाहरू पहुँच गर्न सक्षम हुनेछैन। र यदि कारण कन्फिगरेसन त्रुटि वा ह्याक हो भने रिडन्डन्सीले मद्दत गर्दैन। अर्कोतर्फ, उचित 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 छ, तर तिनीहरू उस्तै छैनन्। वास्तविक औसत TTL १५ सेकेन्ड हुनेछ।

तर पर्खनुहोस्! यो झन् खराब हुँदै जान्छ। केही समाधानकर्ताहरूले दुई लिङ्क गरिएका कम TTL हरूको साथ यस अवस्थामा धेरै नराम्रो व्यवहार गर्छन्:

$ ड्रिल raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. CNAME मा १. github.map.fastly.net. github.map.fastly.net. १. A १५१.१०१.१६.१३३ मा १.

Level3 रिजल्भर सम्भवतः BIND मा चलिरहेको छ। यदि तपाईंले यो क्वेरी पठाइरहनुभयो भने, यसले सधैं १ को 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 छ, तर डोमेनहरूको लागि। akamai.net अधिकतम TTL २० सेकेन्ड हो र ती मध्ये कुनै पनि चरणमा छैनन्।

एप्पल उपकरणहरूलाई निरन्तर सर्वेक्षण गर्ने डोमेनहरूको बारेमा के हुन्छ?

$ 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

Level1 रिजल्भर प्रयोग गर्दा धेरैजसो समय Firefox र TTL जस्तै समस्या १ सेकेन्डमा अड्किनेछ।

ड्रपबक्स?

$ ड्रिल client.dropbox.com @8.8.8.8 client.dropbox.com. ७ IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. ५९ IN A १६२.१२५.६७.३ $ ड्रिल client.dropbox.com @४.२.२ client.dropbox.com. १ IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. १ IN A १६२.१२५.६४.३

रेकर्डिङमा safebrowsing.googleapis.com फेसबुक डोमेन जस्तै ६० सेकेन्डको TTL मान। अनि फेरि, ग्राहकको दृष्टिकोणबाट, यी मानहरू आधा घटाइएका छन्।

न्यूनतम TTL कसरी सेट गर्ने?

नाम, अनुरोध प्रकार, TTL, र मूल रूपमा भण्डारण गरिएको टाइमस्ट्याम्प प्रयोग गरेर, मैले म्याद सकिएको क्यास प्रविष्टिको कारण पठाइएका अतिरिक्त अनुरोधहरूको मात्रा अनुमान गर्न क्यासिङ रिजल्भर मार्फत जाने १५ लाख अनुरोधहरूको नक्कल गर्न स्क्रिप्ट लेखें।

४७.४% अनुरोधहरू अवस्थित रेकर्डको म्याद सकिएपछि गरिएका थिए। यो अनुचित रूपमा उच्च हो।

न्यूनतम TTL सेट गरिएमा क्यासिङमा कस्तो प्रभाव पर्नेछ?

X-अक्ष भनेको न्यूनतम TTL मान हो। यो मानभन्दा माथि कच्चा TTL भएका रेकर्डहरू प्रभावित हुँदैनन्।

Y अक्ष भनेको पहिले नै क्यास गरिएको प्रविष्टि भएको तर म्याद सकिएको र नयाँ अनुरोध गरिरहेको क्लाइन्टबाट आएका अनुरोधहरूको प्रतिशत हो।

न्यूनतम TTL लाई ५ मिनेटमा सेट गर्नाले "अतिरिक्त" अनुरोधहरूको अंश ४७% बाट ३६% मा घट्छ। न्यूनतम TTL लाई १५ मिनेटमा सेट गर्नाले यी अनुरोधहरूको संख्या २९% मा घट्छ। न्यूनतम १ घण्टाको TTL ले तिनीहरूलाई १७% मा घटाउँछ। एउटा महत्त्वपूर्ण भिन्नता!

सर्भर साइडमा केहि पनि परिवर्तन नगरी, क्लाइन्ट DNS क्यासहरू (राउटरहरू, स्थानीय रिजल्भरहरू) मा न्यूनतम TTL हरू सेट गर्ने बारे के गर्ने?

न्यूनतम TTL ५ मिनेटमा सेट गर्दा आवश्यक अनुरोधहरूको संख्या ४७% बाट ३४% मा, न्यूनतम १५ मिनेटमा २५% मा र न्यूनतम १ घण्टामा १३% मा घट्छ। सायद ४० मिनेट इष्टतम हो।

यो न्यूनतम परिवर्तनको प्रभाव ठूलो छ।

परिणामहरू के हुन्?

अवश्य पनि, तपाईंले सेवालाई नयाँ क्लाउड प्रदायक, नयाँ सर्भर, नयाँ नेटवर्कमा स्थानान्तरण गर्न सक्नुहुन्छ, र ग्राहकहरूलाई नवीनतम DNS रेकर्डहरू प्रयोग गर्न आवश्यक पर्दछ। र पर्याप्त सानो TTL ले त्यो संक्रमणलाई सहज र निर्बाध बनाउन मद्दत गर्दछ। तर जब तपाईं नयाँ पूर्वाधारमा स्थानान्तरण गर्नुहुन्छ, कसैले पनि ग्राहकहरूले १ मिनेट, ५ मिनेट, वा १५ मिनेट भित्र नयाँ DNS रेकर्डहरूमा स्थानान्तरण गर्ने अपेक्षा गर्दैन। न्यूनतम TTL लाई ५ मिनेटको सट्टा ४० मिनेटमा सेट गर्नाले प्रयोगकर्ताहरूलाई सेवा पहुँच गर्नबाट रोकिने छैन।

यद्यपि, यसले विलम्बतालाई उल्लेखनीय रूपमा कम गर्नेछ र अनावश्यक अनुरोधहरू बेवास्ता गरेर गोपनीयता र विश्वसनीयतामा सुधार गर्नेछ।

पक्कै पनि, RFC हरूले TTL हरूलाई कडाइका साथ लागू गर्नुपर्छ भन्छन्। तर वास्तविकता यो हो कि DNS प्रणाली धेरै अक्षम भएको छ।

यदि तपाईं आधिकारिक DNS सर्भरहरूसँग काम गर्दै हुनुहुन्छ भने, कृपया आफ्नो TTL हरू जाँच गर्नुहोस्। के तपाईंलाई साँच्चै यति हास्यास्पद रूपमा कम मानहरू चाहिन्छ?

अवश्य पनि, DNS रेकर्डहरूको लागि साना TTL हरू सेट गर्नुका राम्रा कारणहरू छन्। तर ७५% DNS ट्राफिकको लागि होइन जुन मुश्किलले परिवर्तन हुन्छ।

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

यदि तपाईंसँग स्थानीय DNS क्यास चलिरहेको छ भने, जस्तै dnscrypt-proxy, जसले तपाईंलाई न्यूनतम TTL सेट गर्न अनुमति दिन्छ, यो प्रकार्य प्रयोग गर्नुहोस्। यो सामान्य हो। केहि पनि नराम्रो हुनेछैन। न्यूनतम TTL लाई ४० मिनेट (२४०० सेकेन्ड) र १ घण्टाको बीचमा सेट गर्नुहोस्। उचित दायरा।

स्रोत: www.habr.com