کم DNS تاخیر تیز انٹرنیٹ براؤزنگ کی کلید ہے۔ اسے کم سے کم کرنے کے لیے، DNS سرورز کو احتیاط سے منتخب کرنا ضروری ہے۔ . لیکن پہلا قدم بیکار سوالات سے چھٹکارا حاصل کرنا ہے۔
یہی وجہ ہے کہ DNS کو اصل میں ایک انتہائی قابل ذخیرہ پروٹوکول کے طور پر ڈیزائن کیا گیا تھا۔ زون کے منتظمین انفرادی اندراجات کے لیے ایک ٹائم ٹو لائیو (TTL) مقرر کرتے ہیں، اور حل کرنے والے اس معلومات کو استعمال کرتے ہیں جب اندراجات کو میموری میں محفوظ کرتے ہیں تاکہ غیر ضروری ٹریفک سے بچا جا سکے۔
کیا کیشنگ مؤثر ہے؟ کچھ سال پہلے، میری چھوٹی سی تحقیق نے ظاہر کیا کہ یہ کامل نہیں تھا۔ آئیے موجودہ حالات پر ایک نظر ڈالتے ہیں۔
معلومات جمع کرنے کے لیے میں نے پیچ کیا۔ جواب کے لیے TTL قدر کو بچانے کے لیے۔ اس کی تعریف ہر آنے والی درخواست کے لیے اس کے ریکارڈز کے کم از کم TTL کے طور پر کی گئی ہے۔ یہ حقیقی ٹریفک کی TTL تقسیم کا ایک اچھا جائزہ پیش کرتا ہے، اور انفرادی درخواستوں کی مقبولیت کو بھی مدنظر رکھتا ہے۔ سرور کا پیچ شدہ ورژن کئی گھنٹوں تک کام کرتا رہا۔
نتیجے میں آنے والا ڈیٹا سیٹ 1 ریکارڈز (نام، کیو ٹائپ، ٹی ٹی ایل، ٹائم اسٹیمپ) پر مشتمل ہے۔ یہاں TTL کی مجموعی تقسیم ہے (X-axis سیکنڈ میں TTL ہے):
86 پر ایک معمولی ٹکرانے کے علاوہ (زیادہ تر SOA ریکارڈز کے لیے)، یہ بالکل واضح ہے کہ TTLs کم رینج میں ہیں۔ آئیے ایک قریبی نظر ڈالیں:
ٹھیک ہے، 1 گھنٹے سے زیادہ کے TTL اعداد و شمار کے لحاظ سے اہم نہیں ہیں۔ پھر آئیے 0-3600 کی حد پر توجہ مرکوز کریں:
زیادہ تر TTLs 0 سے 15 منٹ تک ہیں:
اکثریت 0 سے 5 منٹ تک ہے:
یہ بہت اچھا نہیں ہے۔
مجموعی تقسیم مسئلہ کو اور بھی واضح کرتی ہے:
آدھے DNS جوابات کا TTL 1 منٹ یا اس سے کم ہے، اور تین چوتھائی میں 5 منٹ یا اس سے کم کا TTL ہے۔
لیکن انتظار کرو، یہ اصل میں بدتر ہے. سب کے بعد، یہ مستند سرورز سے TTL ہے. تاہم، کلائنٹ ریزولورز (جیسے راؤٹرز، لوکل کیچز) اپ اسٹریم ریزولورز سے TTL وصول کرتے ہیں، اور یہ ہر سیکنڈ میں کم ہوتا ہے۔
لہذا کلائنٹ نئی درخواست بھیجنے سے پہلے ہر اندراج کو اوسطاً نصف اصل TTL کے لیے استعمال کر سکتا ہے۔
ہوسکتا ہے کہ یہ بہت کم TTLs صرف غیر معمولی درخواستوں پر لاگو ہوں نہ کہ مقبول ویب سائٹس اور APIs پر؟ آئیے ایک نظر ڈالتے ہیں:
X محور TTL ہے، Y محور استفسار کی مقبولیت ہے۔
بدقسمتی سے، سب سے زیادہ مقبول سوالات بھی کیش کے لیے بدترین ہیں۔
آئیے زوم ان کریں:
فیصلہ: یہ واقعی برا ہے۔ یہ پہلے ہی خراب تھا، لیکن یہ اور بھی خراب ہو گیا۔ DNS کیشنگ عملی طور پر بیکار ہو گئی ہے۔ چونکہ بہت کم لوگ اپنے ISP کا DNS ریزولور استعمال کرتے ہیں (اچھی وجوہات کی بناء پر)، تاخیر میں اضافہ زیادہ نمایاں ہو جاتا ہے۔
DNS کیشنگ صرف اس مواد کے لیے مفید ہو گئی ہے جس پر کوئی نہیں جاتا ہے۔
براہ کرم یہ بھی نوٹ کریں کہ سافٹ ویئر ہوسکتا ہے۔ کم ٹی ٹی ایل کی تشریح کریں۔
کیوں؟
DNS ریکارڈ اتنے کم TTL پر کیوں سیٹ کیے گئے ہیں؟
- لیگیسی لوڈ بیلنسرز پہلے سے طے شدہ ترتیبات کے ساتھ رہ گئے تھے۔
- ایسی خرافات ہیں کہ DNS لوڈ بیلنسنگ TTL پر منحصر ہے (یہ سچ نہیں ہے - Netscape Navigator کے دنوں سے، کلائنٹس نے RRs کے سیٹ سے ایک بے ترتیب IP ایڈریس کا انتخاب کیا ہے اور اگر وہ رابطہ نہیں کر سکتے تو شفاف طریقے سے دوسرا آزمایا ہے)
- منتظمین تبدیلیاں فوری طور پر لاگو کرنا چاہتے ہیں، اس لیے منصوبہ بندی کرنا آسان ہے۔
- DNS سرور یا لوڈ بیلنسر کا ایڈمنسٹریٹر اپنے کام کو مؤثر طریقے سے کنفیگریشن کی تعیناتی کے طور پر دیکھتا ہے جس کی صارفین درخواست کرتے ہیں، اور سائٹس اور سروسز کو تیز نہیں کرتے۔
- کم ٹی ٹی ایل آپ کو ذہنی سکون فراہم کرتے ہیں۔
- لوگ ابتدائی طور پر جانچ کے لیے کم ٹی ٹی ایل سیٹ کرتے ہیں اور پھر انہیں تبدیل کرنا بھول جاتے ہیں۔
میں نے "فیل اوور" کو فہرست میں شامل نہیں کیا کیونکہ یہ کم سے کم متعلقہ ہوتا جا رہا ہے۔ اگر آپ کو صارفین کو کسی دوسرے نیٹ ورک پر ری ڈائریکٹ کرنے کی ضرورت ہوتی ہے تو صرف غلطی کا صفحہ ظاہر کرنے کے لیے جب باقی سب کچھ ٹوٹ جاتا ہے، تو 1 منٹ سے زیادہ کی تاخیر شاید قابل قبول ہے۔
مزید برآں، ایک منٹ کے TTL کا مطلب ہے کہ اگر مستند DNS سرورز کو 1 منٹ سے زیادہ کے لیے بلاک کر دیا جاتا ہے، تو کوئی اور انحصار خدمات تک رسائی حاصل نہیں کر سکے گا۔ اور اگر وجہ کنفیگریشن کی خرابی یا ہیک ہے تو فالتو پن مدد نہیں کرے گا۔ دوسری طرف، معقول TTLs کے ساتھ، بہت سے کلائنٹس پچھلی ترتیب کو استعمال کرتے رہیں گے اور کبھی کسی چیز کا نوٹس نہیں لیں گے۔
کم TTLs کے لیے CDN سروسز اور لوڈ بیلنس زیادہ تر ذمہ دار ہیں، خاص طور پر جب وہ CNAMEs کو کم TTLs اور ریکارڈز کو یکساں طور پر کم (لیکن آزاد) 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
لیول 3 حل کرنے والا شاید 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
Firefox اور TTL جیسا ہی مسئلہ Level1 ریزولور کا استعمال کرتے وقت زیادہ تر 3 سیکنڈ پر پھنس جائے گا۔
ڈراپ باکس؟
$dill 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، اور اصل میں ذخیرہ شدہ ٹائم اسٹیمپ کا استعمال کرتے ہوئے، میں نے کیشنگ ریزولور سے گزرنے والی 1,5 ملین درخواستوں کو نقل کرنے کے لیے ایک اسکرپٹ لکھا تاکہ کیش انٹری کی میعاد ختم ہونے کی وجہ سے بھیجی گئی غیر ضروری درخواستوں کے حجم کا اندازہ لگایا جا سکے۔
47,4% درخواستیں موجودہ ریکارڈ کی میعاد ختم ہونے کے بعد کی گئیں۔ یہ غیر معقول حد تک زیادہ ہے۔
اگر کم از کم TTL سیٹ کیا جائے تو کیشنگ پر کیا اثر پڑے گا؟
X محور کم از کم TTL قدریں ہیں۔ اس قدر سے اوپر کے ماخذ TTL والے ریکارڈز متاثر نہیں ہوتے ہیں۔
Y محور ایک کلائنٹ کی طرف سے درخواستوں کا فیصد ہے جس کے پاس پہلے سے کیش شدہ اندراج ہے، لیکن اس کی میعاد ختم ہو چکی ہے اور وہ نئی درخواست کر رہا ہے۔
"اضافی" درخواستوں کا حصہ صرف کم از کم TTL کو 47 منٹ پر سیٹ کر کے 36% سے کم کر کے 5% کر دیا جاتا ہے۔ کم از کم TTL کو 15 منٹ پر سیٹ کرنے سے، ان درخواستوں کی تعداد 29% تک گر جاتی ہے۔ 1 گھنٹے کا کم از کم TTL انہیں 17% تک کم کر دیتا ہے۔ اہم فرق!
سرور سائیڈ پر کسی بھی چیز کو تبدیل نہ کرنے، بلکہ کلائنٹ DNS کیچز (روٹرز، لوکل ریزولورز) میں کم از کم ٹی ٹی ایل سیٹ کرنے کے بارے میں کیا خیال ہے؟
مطلوبہ درخواستوں کی تعداد کم از کم 47 منٹ کے TTL کے ساتھ 34% سے 5%، کم از کم 25 منٹ کے ساتھ 15%، اور کم از کم 13 گھنٹے کے ساتھ 1% تک گر جاتی ہے۔ شاید 40 منٹ بہترین ہے۔
اس چھوٹی سی تبدیلی کا اثر بہت زیادہ ہے۔
اس کے نتائج کیا ہیں؟
بلاشبہ، سروس کو نئے کلاؤڈ فراہم کنندہ، نئے سرور، نئے نیٹ ورک پر منتقل کیا جا سکتا ہے، جس کے لیے کلائنٹس کو جدید ترین DNS ریکارڈ استعمال کرنے کی ضرورت ہوتی ہے۔ اور کافی چھوٹا ٹی ٹی ایل اس طرح کی منتقلی کو آسانی سے اور غیر محسوس طریقے سے کرنے میں مدد کرتا ہے۔ لیکن نئے انفراسٹرکچر میں منتقلی کے ساتھ، کوئی بھی کلائنٹس سے 1 منٹ، 5 منٹ، یا 15 منٹ کے اندر نئے DNS ریکارڈز پر منتقل ہونے کی توقع نہیں کرتا ہے۔ کم از کم TTL کو 40 منٹ کے بجائے 5 منٹ پر سیٹ کرنے سے صارفین کو سروس تک رسائی حاصل کرنے سے نہیں روکا جائے گا۔
تاہم، یہ تاخیر کو نمایاں طور پر کم کرے گا اور غیر ضروری درخواستوں سے گریز کرکے رازداری اور وشوسنییتا کو بہتر بنائے گا۔
بلاشبہ، RFCs کا کہنا ہے کہ TTL کی سختی سے پیروی کی جانی چاہیے۔ لیکن حقیقت یہ ہے کہ ڈی این ایس سسٹم بہت ناکارہ ہو چکا ہے۔
اگر آپ مستند DNS سرورز کے ساتھ کام کر رہے ہیں، تو براہ کرم اپنے TTLs کو چیک کریں۔ کیا آپ کو واقعی ایسی مضحکہ خیز کم اقدار کی ضرورت ہے؟
بلاشبہ، DNS ریکارڈز کے لیے چھوٹے ٹی ٹی ایل سیٹ کرنے کی اچھی وجوہات ہیں۔ لیکن DNS ٹریفک کے 75% کے لیے نہیں جو عملی طور پر کوئی تبدیلی نہیں ہے۔
اور اگر کسی وجہ سے آپ کو واقعی DNS کے لیے کم TTL استعمال کرنے کی ضرورت ہے، تو ساتھ ہی یہ بھی یقینی بنائیں کہ آپ کی سائٹ پر کیشنگ فعال نہیں ہے۔ انہی وجوہات کی بنا پر۔
اگر آپ کے پاس مقامی DNS کیش چل رہا ہے، جیسے جو آپ کو کم از کم ٹی ٹی ایل سیٹ کرنے کی اجازت دیتا ہے، اس فنکشن کو استعمال کریں۔ یہ ٹھیک ہے. کچھ برا نہیں ہو گا۔ کم از کم TTL کو تقریباً 40 منٹ (2400 سیکنڈ) اور 1 گھنٹہ پر سیٹ کریں۔ کافی معقول حد۔
ماخذ: www.habr.com