گھٽ DNS ويڪرائي تيز رفتار انٽرنيٽ برائوزنگ لاء اهم آهي. ان کي گھٽ ڪرڻ لاء، اھو ضروري آھي ته احتياط سان چونڊيو DNS سرورز ۽ . پر پهريون قدم بيڪار سوالن کان نجات حاصل ڪرڻ آهي.
اهو ئي سبب آهي ته DNS اصل ۾ هڪ انتهائي ڪيش قابل پروٽوڪول جي طور تي ٺهيل هئي. زون جي منتظمين انفرادي داخلائن لاءِ رهڻ جو وقت مقرر ڪيو (TTL)، ۽ حل ڪندڙ هن معلومات کي استعمال ڪندا آهن جڏهن ميموري ۾ داخلا محفوظ ڪري رهيا آهن غير ضروري ٽرئفڪ کان بچڻ لاءِ.
ڇا ڪيشنگ اثرائتو آهي؟ ڪجھ سال اڳ، منهنجي ننڍڙي تحقيق ڏيکاري ٿي ته اهو مڪمل نه هو. اچو ته موجوده صورتحال تي هڪ نظر وجهون.
معلومات گڏ ڪرڻ لاءِ مون پيچ ڪيو جواب لاء TTL قدر بچائڻ لاء. اهو بيان ڪيو ويو آهي گهٽ ۾ گهٽ TTL ان جي رڪارڊ جي هر ايندڙ درخواست لاءِ. هي حقيقي ٽرئفڪ جي TTL ورڇ جو هڪ سٺو جائزو ڏئي ٿو، ۽ انفرادي درخواستن جي مقبوليت کي به حساب ۾ رکي ٿو. سرور جو پيچ ٿيل نسخو ڪيترن ئي ڪلاڪن تائين ڪم ڪيو.
نتيجو ڊيٽا سيٽ تي مشتمل آهي 1 ريڪارڊ (نالو، qtype، TTL، timestamp). هتي مجموعي طور تي TTL تقسيم آهي (X-axis سيڪنڊن ۾ TTL آهي):
86 (اڪثر ڪري SOA ريڪارڊز لاءِ) تي هڪ معمولي ٽمپ کان علاوه، اهو بلڪل واضح آهي ته TTLs گهٽ رينج ۾ آهن. اچو ته هڪ ويجهي نظر وٺو:
ٺيڪ آهي، TTLs 1 ڪلاڪ کان وڌيڪ شمارياتي لحاظ کان اهم نه آهن. ان کان پوء اچو ته رينج 0-3600 تي ڌيان ڏيو:
گهڻيون TTLs 0 کان 15 منٽن تائين آهن:
وڏي اڪثريت 0 کان 5 منٽن تائين آهن:
اهو تمام سٺو ناهي.
مجموعي تقسيم مسئلو اڃا به وڌيڪ واضح ڪري ٿو:
اڌ DNS جوابن ۾ TTL 1 منٽ يا ان کان گهٽ آهي، ۽ ٽن چوٿين ۾ 5 منٽ يا گهٽ جو TTL آهي.
پر انتظار ڪريو، اهو اصل ۾ بدترين آهي. آخرڪار، هي مستند سرورز کان TTL آهي. بهرحال، ڪلائنٽ حل ڪندڙ (مثال طور روٽر، مقامي ڪيش) اپ اسٽريم حل ڪندڙن کان TTL وصول ڪن ٿا، ۽ اهو هر سيڪنڊ ۾ گھٽجي ٿو.
تنهن ڪري ڪلائنٽ اصل ۾ هر داخلا استعمال ڪري سگهي ٿو، سراسري طور تي، نئين درخواست موڪلڻ کان اڳ اڌ اصل TTL.
ٿي سگهي ٿو اهي تمام گهٽ TTLs صرف غير معمولي درخواستن تي لاڳو ٿين ٿيون ۽ نه مشهور ويب سائيٽون ۽ APIs؟ اچو ته هڪ نظر وٺو:
X محور TTL آهي، Y محور سوال مقبوليت آهي.
بدقسمتي سان، سڀ کان وڌيڪ مشهور سوال پڻ ڪيش ڪرڻ لاء بدترين آهن.
اچو ته وڏو ڪريون:
فيصلو: اهو واقعي خراب آهي. اهو اڳ ۾ ئي خراب هو، پر اهو اڃا به خراب ٿي ويو. DNS ڪيشنگ عملي طور تي بيڪار ٿي چڪي آهي. جيئن ته گهٽ ماڻهو استعمال ڪندا آهن انهن جي ISP جي DNS حل ڪندڙ (سٺن سببن لاء)، ويڪرائي ۾ اضافو وڌيڪ قابل ذڪر ٿيندو.
DNS ڪيشنگ صرف ان مواد لاءِ ڪارآمد ٿي چڪي آهي جنهن کي ڪو به دورو نٿو ڪري.
مهرباني ڪري پڻ نوٽ ڪريو ته سافٽ ويئر ٿي سگهي ٿو گھٽ TTLs جي وضاحت ڪريو.
ائين ڇو
ڇو ته ڊي اين ايس رڪارڊ اهڙي گهٽ TTL تي مقرر ڪيا ويا آهن؟
- وراثت لوڊ بيلنسرز ڊفالٽ سيٽنگن سان ڇڏي ويا.
- اهڙا افسانا آهن ته DNS لوڊ بيلنس جو دارومدار TTL تي آهي (اها سچ ناهي - نيٽ اسڪيپ نيويگيٽر جي ڏينهن کان وٺي، ڪلائنٽ RRs جي هڪ سيٽ مان هڪ بي ترتيب IP پتو چونڊيو آهي ۽ شفاف طور تي ٻي ڪوشش ڪئي آهي جيڪڏهن اهي ڳنڍي نٿا سگهن)
- منتظمين تبديلين کي فوري طور تي لاڳو ڪرڻ چاھيو ٿا، تنھنڪري اھو پلان ڪرڻ آسان آھي.
- DNS سرور جو منتظم يا لوڊ بيلنسر پنهنجي ڪم کي موثر طريقي سان ترتيب ڏيڻ جي طور تي ڏسي ٿو جيڪو صارف درخواست ڪري ٿو، ۽ سائيٽن ۽ خدمتن کي تيز نه ڪرڻ.
- گھٽ TTLs توهان کي دماغ جو سڪون ڏين ٿا.
- ماڻهو شروعاتي طور تي ٽيسٽ لاءِ گهٽ TTL مقرر ڪندا آهن ۽ پوءِ انهن کي تبديل ڪرڻ وساريندا آهن.
مون لسٽ ۾ "ناڪامي" شامل نه ڪيو ڇو ته اهو گهٽ ۽ گهٽ لاڳاپيل ٿيندو پيو وڃي. جيڪڏهن توهان کي ضرورت آهي ته صارفين کي ڪنهن ٻئي نيٽ ورڪ ڏانهن ريڊائريڪٽ ڪرڻ لاءِ صرف هڪ غلطي واري صفحي کي ظاهر ڪرڻ لاءِ جڏهن ته سڀ ڪجهه ڀڄي ويو آهي، 1 منٽ کان وڌيڪ دير ممڪن آهي قابل قبول آهي.
اضافي طور تي، هڪ منٽ TTL جو مطلب آهي ته جيڪڏهن مستند DNS سرورز 1 منٽ کان وڌيڪ بلاڪ ڪيا ويا آهن، ٻيو ڪو به انحصار ڪيل خدمتن تائين رسائي حاصل ڪرڻ جي قابل نه هوندو. ۽ لاچاري مدد نه ڪندي جيڪڏهن سبب هڪ ترتيب جي غلطي يا هيڪ آهي. ٻئي طرف، معقول TTLs سان، ڪيترائي گراهڪ اڳئين ترتيب کي استعمال ڪرڻ جاري رکندا ۽ ڪڏھن به نوٽيس نه ڪندا.
سي ڊي اين جون خدمتون ۽ لوڊ بيلنس وارا گهڻو ڪري گهٽ TTLs لاءِ ذميوار آهن، خاص طور تي جڏهن اهي CNAMEs کي گهٽ 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 سيڪنڊن جو ٿيندو.
پر رکو! ان کان به بدتر آهي. ڪجهه حل ڪندڙ هن صورتحال ۾ ٻه لاڳاپيل گهٽ ٽي ٽي ايل سان تمام خراب طريقي سان هلندا آهن:
$ 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 آهي، پر اهو مڪمل طور تي بيڪار آهي. ٻين CNAMEs وٽ 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
ساڳيو مسئلو فائر فاڪس ۽ ٽي ٽي ايل جي طور تي 1 سيڪنڊن تي گهڻو ڪري پڪڙي ويندي جڏهن Level3 حل ڪندڙ استعمال ڪندي.
ڊراپ باڪس؟
$ 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 IN 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 مقرر ڪيو وڃي ته ڪيشنگ تي ڇا اثر پوندو؟
ايڪس محور گھٽ ۾ گھٽ TTL قدر آھي. ذريعن سان گڏ رڪارڊز TTLs هن قيمت کان مٿي متاثر نه آهن.
Y محور ھڪڙي ڪلائنٽ جي درخواستن جو سيڪڙو آھي جيڪو اڳ ۾ ئي ڪيش ٿيل داخلا آھي، پر اھو ختم ٿي چڪو آھي ۽ نئين درخواست ڪري رھيو آھي.
"اضافي" درخواستن جو حصو 47٪ کان 36٪ تائين گھٽجي ويو آھي صرف گھٽ ۾ گھٽ TTL مقرر ڪندي 5 منٽ. 15 منٽن تائين گھٽ ۾ گھٽ TTL مقرر ڪرڻ سان، انھن درخواستن جو تعداد 29٪ تائين گھٽجي ٿو. 1 ڪلاڪ جي گھٽ ۾ گھٽ TTL انھن کي 17٪ تائين گھٽائي ٿو. اهم فرق!
ڪيئن سرور جي پاسي تي ڪجھ به تبديل نه ڪرڻ جي باري ۾، پر ان جي بدران ڪلائنٽ DNS ڪيچز ۾ گھٽ ۾ گھٽ TTL سيٽنگ (راؤٽر، مقامي حل ڪندڙ)؟
گهربل درخواستن جو تعداد گھٽ ۾ گھٽ 47 منٽن جي TTL سان 34% کان 5% تائين، گھٽ ۾ گھٽ 25 منٽ سان 15% تائين، ۽ گھٽ ۾ گھٽ 13 ڪلاڪ سان 1% تائين. شايد 40 منٽ بهتر آهي.
هن ننڍڙي تبديلي جو اثر تمام وڏو آهي.
ان جا نتيجا ڪهڙا آهن؟
يقينا، خدمت کي منتقل ڪري سگھجي ٿو نئين بادل فراهم ڪندڙ، نئين سرور، نئين نيٽ ورڪ، صارفين کي جديد DNS رڪارڊ استعمال ڪرڻ جي ضرورت آهي. ۽ هڪ تمام ننڍڙو TTL مدد ڪري ٿو اهڙي منتقلي کي آساني سان ۽ ناقابل اعتبار سان. پر نئين انفراسٽرڪچر جي منتقلي سان، ڪو به گراهڪن کي 1 منٽ، 5 منٽ، يا 15 منٽن اندر نئين ڊي اين ايس ريڪارڊ ڏانهن لڏڻ جي اميد نٿو رکي. گھٽ ۾ گھٽ TTL کي 40 منٽن جي بدران 5 منٽ ڪرڻ سان صارفين کي سروس تائين رسائي کان روڪي نه سگھندو.
جڏهن ته، اهو خاص طور تي دير سان گهٽائي ڇڏيندو ۽ غير ضروري درخواستن کان پاسو ڪندي رازداري ۽ اعتبار کي بهتر بڻائيندو.
يقينا، آر ايف سي جو چوڻ آهي ته TTL کي سختي سان عمل ڪيو وڃي. پر حقيقت اها آهي ته ڊي اين ايس سسٽم تمام غير موثر ٿي چڪو آهي.
جيڪڏھن توھان مستند DNS سرورز سان ڪم ڪري رھيا آھيو، مھرباني ڪري پنھنجا TTLs چيڪ ڪريو. ڇا توهان واقعي اهڙي مضحکہ خیز گهٽ قدر جي ضرورت آهي؟
يقينن، DNS رڪارڊز لاءِ ننڍڙا ٽي ٽي ايل سيٽ ڪرڻ جا سٺا سبب آهن. پر DNS ٽرئفڪ جي 75٪ لاءِ نه جيڪا حقيقت ۾ بدليل رهي ٿي.
۽ جيڪڏهن ڪجهه سببن لاءِ توهان کي واقعي DNS لاءِ گهٽ TTLs استعمال ڪرڻ جي ضرورت آهي، ساڳئي وقت پڪ ڪريو ته توهان جي سائيٽ تي ڪيشنگ فعال نه آهي. ساڳئي سببن لاء.
جيڪڏهن توهان وٽ مقامي DNS ڪيش هلندڙ آهي، جهڙوڪ جيڪو توهان کي گهٽ ۾ گهٽ TTL سيٽ ڪرڻ جي اجازت ڏئي ٿو، هن فنڪشن کي استعمال ڪريو. هي ٺيڪ آهي. ڪجھ به خراب نه ٿيندو. گھٽ ۾ گھٽ TTL مقرر ڪريو تقريبن 40 منٽ (2400 سيڪنڊ) ۽ 1 ڪلاڪ. بلڪل معقول حد.
جو ذريعو: www.habr.com