वेगवान इंटरनेट ब्राउझिंगसाठी कमी 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 फक्त असामान्य विनंत्यांवर लागू होतात आणि लोकप्रिय वेबसाइट आणि API वर लागू होत नाहीत? चला एक नजर टाकूया:

X अक्ष TTL आहे आणि Y अक्ष ही क्वेरी लोकप्रियता आहे.

दुर्दैवाने, सर्वात लोकप्रिय क्वेरी देखील कॅशे करण्यासाठी सर्वात वाईट आहेत.

चला झूम वाढवू:

निर्णय: हे खरोखर वाईट आहे. हे आधीच वाईट होते, परंतु ते आणखी वाईट झाले. DNS कॅशिंग अक्षरशः निरुपयोगी झाले आहे. कमी लोक त्यांच्या ISP चे DNS रिझोल्व्हर वापरतात (चांगल्या कारणांसाठी), लेटन्सीमध्ये वाढ अधिक लक्षणीय होते.

DNS कॅशिंग केवळ अशा सामग्रीसाठी उपयुक्त झाले आहे ज्यास कोणी भेट देत नाही.

कृपया हे देखील लक्षात घ्या की सॉफ्टवेअर शकते वेगळ्या पद्धतीने कमी टीटीएलचा अर्थ लावा.

असे का

DNS रेकॉर्ड इतक्या कमी TTL वर का सेट केले जातात?

लेगसी लोड बॅलन्सर डीफॉल्ट सेटिंग्जसह सोडले होते.
डीएनएस लोड बॅलन्सिंग TTL वर अवलंबून असते अशी मिथकं आहेत (हे खरे नाही - नेटस्केप नेव्हिगेटरच्या दिवसांपासून, क्लायंटने RR च्या सेटमधून एक यादृच्छिक IP पत्ता निवडला आहे आणि ते कनेक्ट करू शकत नसल्यास पारदर्शकपणे दुसरा प्रयत्न केला आहे)
प्रशासकांना बदल त्वरित लागू करायचे आहेत, त्यामुळे योजना करणे सोपे आहे.
DNS सर्व्हर किंवा लोड बॅलन्सरचा प्रशासक त्याचे कार्य वापरकर्त्यांनी विनंती केलेले कॉन्फिगरेशन कार्यक्षमतेने उपयोजित करणे आणि साइट आणि सेवांचा वेग वाढवत नाही हे पाहतो.
कमी टीटीएल तुम्हाला मनःशांती देतात.
लोक सुरुवातीला चाचणीसाठी कमी TTL सेट करतात आणि नंतर ते बदलण्यास विसरतात.

मी सूचीमध्ये "फेलओव्हर" समाविष्ट केले नाही कारण ते कमी आणि कमी प्रासंगिक होत आहे. बाकी सर्व काही तुटलेले असताना एरर पेज दाखवण्यासाठी तुम्हाला वापरकर्त्यांना दुसर्‍या नेटवर्कवर पुनर्निर्देशित करायचे असल्यास, 1 मिनिटापेक्षा जास्त विलंब स्वीकार्य आहे.

याव्यतिरिक्त, एक-मिनिट TTL म्हणजे अधिकृत DNS सर्व्हर 1 मिनिटापेक्षा जास्त काळ अवरोधित केले असल्यास, इतर कोणीही अवलंबून सेवांमध्ये प्रवेश करू शकणार नाही. आणि कारण कॉन्फिगरेशन एरर किंवा हॅक असल्यास रिडंडंसी मदत करणार नाही. दुसरीकडे, वाजवी TTL सह, बरेच क्लायंट मागील कॉन्फिगरेशन वापरणे सुरू ठेवतील आणि कधीही काहीही लक्षात घेणार नाहीत.

कमी TTL साठी CDN सेवा आणि लोड बॅलन्सर मुख्यत्वे दोषी आहेत, विशेषत: जेव्हा ते कमी TTL सह CNAME आणि तितकेच कमी (परंतु स्वतंत्र) 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 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 रेकॉर्ड. अय. एखाद्याकडे सभ्य टीटीएल आहे, परंतु ते पूर्णपणे निरुपयोगी आहे. इतर CNAME मध्ये 60 सेकंदांचा प्रारंभिक 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 अक्ष म्हणजे क्लायंटच्या विनंत्यांची टक्केवारी आहे जिच्याकडे आधीच कॅशे केलेली एंट्री आहे, परंतु ती कालबाह्य झाली आहे आणि नवीन विनंती करत आहे.

फक्त किमान TTL 47 मिनिटांवर सेट करून "अतिरिक्त" विनंत्यांचा हिस्सा 36% वरून 5% पर्यंत कमी केला जातो. किमान TTL 15 मिनिटांवर सेट करून, या विनंत्यांची संख्या 29% पर्यंत घसरते. 1 तासाचा किमान TTL त्यांना 17% पर्यंत कमी करतो. लक्षणीय फरक!

सर्व्हरच्या बाजूला काहीही न बदलता, त्याऐवजी क्लायंट डीएनएस कॅशेमध्ये (राउटर, स्थानिक रिझॉल्व्हर्स) किमान टीटीएल सेट करण्याबद्दल कसे?

किमान 47 मिनिटांच्या TTL सह आवश्यक विनंत्यांची संख्या 34% वरून 5%, किमान 25 मिनिटांसह 15% आणि किमान 13 तासासह 1% पर्यंत घसरते. कदाचित 40 मिनिटे इष्टतम आहे.

या छोट्या बदलाचा प्रभाव प्रचंड आहे.

परिणाम काय आहेत?

अर्थात, सेवा नवीन क्लाउड प्रदाता, नवीन सर्व्हर, नवीन नेटवर्कवर हलविली जाऊ शकते, ज्यासाठी क्लायंटला नवीनतम DNS रेकॉर्ड वापरणे आवश्यक आहे. आणि बर्‍यापैकी लहान टीटीएल असे संक्रमण सहजतेने आणि अस्पष्टपणे करण्यास मदत करते. परंतु नवीन इन्फ्रास्ट्रक्चरच्या संक्रमणासह, क्लायंट 1 मिनिट, 5 मिनिटे किंवा 15 मिनिटांत नवीन DNS रेकॉर्डमध्ये स्थलांतरित होतील अशी कोणीही अपेक्षा करत नाही. किमान TTL 40 मिनिटांऐवजी 5 मिनिटांवर सेट केल्याने वापरकर्त्यांना सेवेत प्रवेश करण्यापासून प्रतिबंधित होणार नाही.

तथापि, यामुळे विलंबता लक्षणीयरीत्या कमी होईल आणि अनावश्यक विनंत्या टाळून गोपनीयता आणि विश्वासार्हता सुधारेल.

अर्थात, आरएफसी म्हणतात की टीटीएलचे काटेकोरपणे पालन केले पाहिजे. परंतु वास्तविकता अशी आहे की डीएनएस प्रणाली खूपच अकार्यक्षम झाली आहे.

तुम्ही अधिकृत DNS सर्व्हरसह काम करत असल्यास, कृपया तुमचे TTL तपासा. तुम्हाला खरोखरच अशा हास्यास्पद कमी मूल्यांची गरज आहे का?

अर्थात, DNS रेकॉर्डसाठी लहान TTL सेट करण्याची चांगली कारणे आहेत. परंतु DNS रहदारीच्या 75% साठी नाही जे अक्षरशः अपरिवर्तित राहते.

आणि काही कारणास्तव तुम्हाला खरोखरच DNS साठी कमी TTL वापरण्याची आवश्यकता असल्यास, त्याच वेळी तुमच्या साइटवर कॅशिंग सक्षम नाही याची खात्री करा. त्याच कारणांसाठी.

तुमच्याकडे स्थानिक DNS कॅशे चालू असल्यास, जसे dnscrypt-प्रॉक्सीजे तुम्हाला किमान TTL सेट करण्याची परवानगी देते, हे फंक्शन वापरा. हे ठीक आहे. काहीही वाईट होणार नाही. किमान TTL अंदाजे 40 मिनिटे (2400 सेकंद) आणि 1 तासावर सेट करा. अगदी वाजवी श्रेणी.

स्त्रोत: www.habr.com

DNS साठी हास्यास्पदपणे कमी TTL वापरणे थांबवा

असे का

किमान TTL सेट करण्याबद्दल कसे?

परिणाम काय आहेत?