يعد زمن الوصول المنخفض لنظام DNS أمرًا أساسيًا لتصفح الإنترنت السريع. لتقليل ذلك، من المهم تحديد خوادم DNS و . لكن الخطوة الأولى هي التخلص من الاستعلامات غير المفيدة.
ولهذا السبب تم تصميم DNS في الأصل كبروتوكول قابل للتخزين المؤقت بدرجة كبيرة. يقوم مسؤولو المنطقة بتعيين وقت البقاء (TTL) للإدخالات الفردية، وتستخدم وحدات الحل هذه المعلومات عند تخزين الإدخالات في الذاكرة لتجنب حركة المرور غير الضرورية.
هل التخزين المؤقت فعال؟ قبل عامين، أظهر بحثي البسيط أن الأمر لم يكن مثاليًا. دعونا نلقي نظرة على الوضع الحالي.
لجمع المعلومات أنا مصححة لحفظ قيمة TTL للاستجابة. يتم تعريفه على أنه الحد الأدنى لـ TTL لسجلاته لكل طلب وارد. وهذا يعطي نظرة عامة جيدة على توزيع TTL لحركة المرور الحقيقية، ويأخذ في الاعتبار أيضًا شعبية الطلبات الفردية. عملت النسخة المصححة من الخادم لعدة ساعات.
تتكون مجموعة البيانات الناتجة من 1 سجلًا (الاسم، qtype، TTL، الطابع الزمني). فيما يلي توزيع TTL الإجمالي (المحور السيني هو TTL بالثواني):
بصرف النظر عن الارتفاع الطفيف عند 86 (معظمه لسجلات SOA)، فمن الواضح جدًا أن TTLs تقع في النطاق المنخفض. دعونا نلقي نظرة فاحصة:
حسنًا، مدة البقاء (TTL) التي تزيد عن ساعة واحدة ليست ذات دلالة إحصائية. ثم دعونا نركز على النطاق 1−0:
معظم TTLs تتراوح من 0 إلى 15 دقيقة:
الغالبية العظمى من 0 إلى 5 دقائق:
انها ليست جيدة جدا.
التوزيع التراكمي يجعل المشكلة أكثر وضوحا:
نصف استجابات DNS لها مدة البقاء (TTL) دقيقة واحدة أو أقل، وثلاثة أرباعها لها مدة البقاء (TTL) تبلغ 1 دقائق أو أقل.
لكن مهلا، الأمر أسوأ في الواقع. بعد كل شيء، هذا هو TTL من خوادم موثوقة. ومع ذلك، تتلقى وحدات حل العميل (مثل أجهزة التوجيه وذاكرة التخزين المؤقت المحلية) TTL من وحدات الحل الأولية، وتتناقص كل ثانية.
لذلك يمكن للعميل بالفعل استخدام كل إدخال مقابل نصف مدة البقاء الأصلية في المتوسط قبل إرسال طلب جديد.
ربما تنطبق TTLs المنخفضة جدًا هذه فقط على الطلبات غير العادية وليس على مواقع الويب وواجهات برمجة التطبيقات الشائعة؟ دعونا نلقي نظرة:
المحور X هو TTL والمحور Y هو شعبية الاستعلام.
ولسوء الحظ، فإن الاستعلامات الأكثر شيوعًا هي أيضًا الأسوأ في التخزين المؤقت.
دعونا تكبير:
الحكم: إنه أمر سيء حقًا. لقد كان الأمر سيئًا بالفعل من قبل، لكنه أصبح أسوأ. أصبح التخزين المؤقت لـ DNS عديم الفائدة تقريبًا. مع انخفاض عدد الأشخاص الذين يستخدمون محلل DNS الخاص بمزود خدمة الإنترنت (لأسباب وجيهة)، تصبح الزيادة في زمن الوصول أكثر وضوحًا.
أصبح التخزين المؤقت لنظام أسماء النطاقات (DNS) مفيدًا فقط للمحتوى الذي لا يزوره أحد.
يرجى أيضًا ملاحظة أن البرنامج قد تفسير TTLs المنخفضة.
لماذا؟
لماذا يتم ضبط سجلات DNS على TTL المنخفض؟
- تم ترك موازنات التحميل القديمة بالإعدادات الافتراضية.
- هناك خرافات مفادها أن موازنة تحميل DNS تعتمد على TTL (هذا غير صحيح - منذ أيام Netscape Navigator، اختار العملاء عنوان IP عشوائيًا من مجموعة من سجلات RR وحاولوا تجربة عنوان آخر بشفافية إذا لم يتمكنوا من الاتصال)
- يريد المسؤولون تطبيق التغييرات على الفور، لذلك يكون التخطيط أسهل.
- يرى مسؤول خادم DNS أو موازن التحميل أن مهمته تتمثل في نشر التكوين الذي يطلبه المستخدمون بكفاءة، وليس تسريع المواقع والخدمات.
- تمنحك TTLs المنخفضة راحة البال.
- يقوم الأشخاص في البداية بتعيين TTLs منخفضة للاختبار ثم ينسون تغييرها.
لم أقم بتضمين "تجاوز الفشل" في القائمة لأنه أصبح أقل أهمية. إذا كنت بحاجة إلى إعادة توجيه المستخدمين إلى شبكة أخرى فقط لعرض صفحة خطأ عند تعطل كل شيء آخر، فمن المحتمل أن يكون التأخير لأكثر من دقيقة واحدة مقبولاً.
بالإضافة إلى ذلك، يعني TTL لمدة دقيقة واحدة أنه إذا تم حظر خوادم DNS الموثوقة لأكثر من دقيقة واحدة، فلن يتمكن أي شخص آخر من الوصول إلى الخدمات التابعة. ولن يساعد التكرار إذا كان السبب هو خطأ في التكوين أو الاختراق. من ناحية أخرى، مع TTLs المعقولة، سيستمر العديد من العملاء في استخدام التكوين السابق ولن يلاحظوا أي شيء أبدًا.
خدمات CDN وموازنات التحميل هي المسؤولة إلى حد كبير عن انخفاض TTLs، خاصة عندما تجمع بين CNAMEs و TTLs منخفضة والسجلات ذات TTLs منخفضة (ولكنها مستقلة):
$ 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 لمدة 30 ثانية، لكنه ليس هو نفسه. سيكون متوسط TTL الفعلي 15 ثانية.
لكن انتظر! بل إنه أسوأ. تتصرف بعض وحدات الحل بشكل سيء للغاية في هذا الموقف مع اثنين من TTLs المنخفضتين المرتبطتين:
$ حفر الخام.githubusercontent.com @4.2.2.2 Raw.githubusercontent.com. 1 في CNAME github.map.fastly.net. github.map.fastly.net. 1 في 151.101.16.133
من المحتمل أن يعمل محلل Level3 على BIND. إذا واصلت إرسال هذا الطلب، فسيتم دائمًا إرجاع TTL بقيمة 1. بشكل أساسي، 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 الأخرى على مدة أولية لمدة 60 ثانية، ولكن للمجالات akamai.net الحد الأقصى لـ TTL هو 20 ثانية ولا يوجد أي منها في الطور.
ماذا عن النطاقات التي تستطلع آراء أجهزة Apple باستمرار؟
$ 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.
بصندوق الإسقاط؟
$ الحفر client.dropbox.com @8.8.8.8 client.dropbox.com. 7 في CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 في 162.125.67.3 $ الحفر client.dropbox.com @4.2.2.2 client.dropbox.com. 1 في CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 في 162.125.64.3
عند التسجيل safebrowsing.googleapis.com قيمة TTL هي 60 ثانية، مثل نطاقات Facebook. ومرة أخرى، من وجهة نظر العميل، يتم تخفيض هذه القيم إلى النصف.
ماذا عن تحديد الحد الأدنى لـ TTL؟
باستخدام الاسم ونوع الطلب وTTL والطابع الزمني المخزن في الأصل، قمت بكتابة برنامج نصي لمحاكاة 1,5 مليون طلب يمر عبر محلل التخزين المؤقت لتقدير حجم الطلبات غير الضرورية المرسلة بسبب إدخال ذاكرة التخزين المؤقت منتهية الصلاحية.
تم تقديم 47,4% من الطلبات بعد انتهاء صلاحية السجل الموجود. وهذا مرتفع بشكل غير معقول.
ما هو التأثير على التخزين المؤقت إذا تم تعيين الحد الأدنى لـ TTL؟
المحور X هو الحد الأدنى لقيم TTL. ولا تتأثر السجلات ذات TTLs المصدر الأعلى من هذه القيمة.
المحور Y هو النسبة المئوية للطلبات الواردة من العميل الذي لديه بالفعل إدخال مخبأ، ولكن انتهت صلاحيته ويقوم بتقديم طلب جديد.
يتم تقليل حصة الطلبات "الإضافية" من 47% إلى 36% بمجرد تحديد الحد الأدنى لـ TTL إلى 5 دقائق. ومن خلال تعيين الحد الأدنى لـ TTL على 15 دقيقة، ينخفض عدد هذه الطلبات إلى 29%. الحد الأدنى من TTL لمدة ساعة واحدة يقللها إلى 1%. فرق واضح!
ماذا عن عدم تغيير أي شيء على جانب الخادم، ولكن بدلاً من ذلك تعيين الحد الأدنى لـ TTL في ذاكرة التخزين المؤقت لـ DNS الخاصة بالعميل (أجهزة التوجيه، وأجهزة الحل المحلية)؟
انخفض عدد الطلبات المطلوبة من 47% إلى 34% بحد أدنى لمدة 5 دقائق، إلى 25% بحد أدنى 15 دقيقة، وإلى 13% بحد أدنى 1 ساعة. ربما 40 دقيقة هي الأمثل.
تأثير هذا التغيير الصغير هائل.
ما هي العواقب؟
بالطبع، يمكن نقل الخدمة إلى مزود سحابي جديد، أو خادم جديد، أو شبكة جديدة، مما يتطلب من العملاء استخدام أحدث سجلات DNS. ويساعد TTL الصغير إلى حد ما على إجراء مثل هذا الانتقال بسلاسة وبشكل غير محسوس. ولكن مع الانتقال إلى البنية التحتية الجديدة، لا يتوقع أحد أن ينتقل العملاء إلى سجلات DNS الجديدة خلال دقيقة واحدة أو 1 دقائق أو 5 دقيقة. لن يؤدي تعيين الحد الأدنى لـ TTL إلى 15 دقيقة بدلاً من 40 دقائق إلى منع المستخدمين من الوصول إلى الخدمة.
ومع ذلك، سيؤدي هذا إلى تقليل زمن الوصول بشكل كبير وتحسين الخصوصية والموثوقية عن طريق تجنب الطلبات غير الضرورية.
وبطبيعة الحال، تقول RFCs أنه يجب اتباع TTL بدقة. ولكن الحقيقة هي أن نظام DNS أصبح غير فعال للغاية.
إذا كنت تعمل مع خوادم DNS موثوقة، فيرجى التحقق من TTLs الخاصة بك. هل تحتاج حقًا إلى مثل هذه القيم المنخفضة بشكل يبعث على السخرية؟
بالطبع، هناك أسباب وجيهة لتعيين TTLs صغيرة لسجلات DNS. ولكن ليس بالنسبة لـ 75% من حركة مرور DNS التي تظل دون تغيير تقريبًا.
وإذا كنت بحاجة حقًا لسبب ما إلى استخدام TTLs منخفضة لـ DNS، فتأكد في الوقت نفسه من عدم تمكين التخزين المؤقت على موقعك. لنفس الأسباب.
إذا كان لديك ذاكرة تخزين مؤقت DNS محلية قيد التشغيل، مثل الذي يسمح لك بتعيين الحد الأدنى من TTLs، استخدم هذه الوظيفة. هذا جيد. لن يحدث شيء سيء. اضبط الحد الأدنى لـ TTL على 40 دقيقة تقريبًا (2400 ثانية) وساعة واحدة. نطاق معقول تمامًا.
المصدر: www.habr.com