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

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

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

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

नतिजा डेटा सेटमा 1 रेकर्डहरू (नाम, qtype, TTL, टाइमस्ट्याम्प) हुन्छन्। यहाँ समग्र TTL वितरण छ (X-axis सेकेन्डमा TTL हो):

86 मा सानो टक्कर बाहेक (अधिकतर SOA रेकर्डहरूको लागि), यो स्पष्ट छ कि TTL हरू कम दायरामा छन्। नजिकबाट हेरौं:

ठीक छ, 1 घण्टा भन्दा बढी TTLहरू सांख्यिकीय रूपमा महत्त्वपूर्ण छैनन्। त्यसपछि दायरा 0-3600 मा फोकस गरौं:

धेरै जसो TTL 0 देखि 15 मिनेट सम्मका हुन्छन्:

विशाल बहुमत 0 देखि 5 मिनेट सम्म हो:

यो धेरै राम्रो छैन।

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

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

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

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

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

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

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

जुम इन गरौं:

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

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

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

किन त्यसो

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

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

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

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

CDN सेवाहरू र लोड ब्यालेन्सरहरू धेरै हदसम्म कम TTLs को लागि दोषी छन्, विशेष गरी जब तिनीहरूले 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 रेकर्डहरूको म्याद समाप्त हुन्छ, नयाँ अनुरोध पठाउनुपर्छ। दुबैसँग 30 सेकेन्ड TTL छ, तर यो समान छैन। वास्तविक औसत TTL 15 सेकेन्ड हुनेछ।

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

$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com। 1 मा CNAME github.map.fastly.net। github.map.fastly.net। 1 IN A 151.101.16.133

Level3 रिजोल्भर सम्भवतः 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 हुन्छ, तर डोमेनका लागि 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

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

ड्रपबक्स?

$ drill 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 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com। 1 CNAME client.dropbox-dns.com मा। client.dropbox-dns.com। 1 IN A 162.125.64.3

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

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

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

47,4% अनुरोधहरू अवस्थित रेकर्डको म्याद सकिएपछि बनाइएका थिए। यो अव्यावहारिक रूपमा उच्च छ।

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

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

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

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

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

आवश्यक अनुरोधहरूको संख्या न्यूनतम 47 मिनेटको TTL सँग 34% बाट 5%, न्यूनतम 25 मिनेटमा 15%, र न्यूनतम 13 घण्टाको साथ 1% मा झर्छ। सायद 40 मिनेट इष्टतम छ।

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

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

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

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

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

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

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

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

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

स्रोत: www.habr.com