يعد زمن انتقال DNS المنخفض عاملاً رئيسياً للتصفح السريع للإنترنت. لتقليل ذلك ، من المهم تحديد خوادم DNS والترحيل المجهول بعناية. ولكن أول شيء فعله هو التخلص من الاستفسارات عديمة الفائدة.

هذا هو السبب في أن DNS تم إنشاؤه في الأصل كبروتوكول مخبأ للغاية. يقوم مسؤولو المنطقة بتعيين عمر (TTL) للسجلات الفردية ، ويستخدم المحللون هذه المعلومات عند تخزين السجلات في الذاكرة لتجنب حركة المرور غير الضرورية.

هل التخزين المؤقت فعال؟ قبل بضع سنوات ، أظهر بحثي الصغير أنه لم يكن مثاليًا. ألقِ نظرة على الوضع الحالي.

لجمع المعلومات ، قمت بتصحيح " خادم DNS المشفر" لتخزين قيمة TTL للاستجابة. يتم تعريفه على أنه الحد الأدنى من TTL لإدخالاته لكل طلب وارد. هذا يعطي لمحة عامة جيدة عن توزيع حركة المرور الحقيقية TTL ، ويأخذ في الاعتبار أيضا شعبية الطلبات الفردية. عملت النسخة المصححة من الخادم لعدة ساعات.

تتكون مجموعة البيانات الناتجة من 1،583،579 سجل (الاسم ، النوع ، TTL ، الطابع الزمني). هنا التوزيع العام لـ TTL (المحور X هو TTL بالثواني):



بصرف النظر عن التل الصغير على 86،400 (بشكل رئيسي لسجلات الخدمية) ، فمن الواضح جدا أن TTLs في النطاق المنخفض. دعنا نلقي نظرة فاحصة:



حسنا ، TTLs أكثر من 1 ساعة ليست ذات دلالة إحصائية. ثم ركز على النطاق من 0 إلى 3600:



معظم TTL من 0 إلى 15 دقيقة:



الغالبية العظمى من 0 إلى 5 دقائق:



هذا ليس جيد جدا

التوزيع التراكمي يجعل المشكلة أكثر وضوحًا:



في نصف ردود DNS ، TTL دقيقة واحدة أو أقل ، وفي ثلاثة أرباع 5 دقائق أو أقل.

ولكن مهلا ، إنه بالفعل أسوأ. بعد كل شيء ، هذا هو TTL من خوادم موثوقة. ومع ذلك ، تتلقى أدوات حل العميل (على سبيل المثال ، أجهزة التوجيه ، ذاكرات التخزين المؤقت المحلية) TTLs من أدوات حل أعلى ، وتنخفض كل ثانية.

وبالتالي ، يمكن للعميل بالفعل استخدام كل سجل ، في المتوسط ​​، لنصف TTL الأصلي ، وبعد ذلك سوف يرسل طلبًا جديدًا.

ربما تتعلق TTLs المنخفضة للغاية بالطلبات غير العادية فقط ، وليس المواقع الشعبية وواجهات برمجة التطبيقات؟ لنرى:



المحور X هو TTL ، والمحور Y هو شعبية الاستعلام.

لسوء الحظ ، فإن أكثر الاستعلامات شيوعًا يتم تخزينها في الذاكرة المخبئية.

تكبير:



الحكم: كل شيء سيء حقا. كان الوضع سيئًا من قبل ، لكنه أصبح أسوأ. أصبح التخزين المؤقت DNS عديمة الفائدة تقريبًا. نظرًا لأن عددًا أقل من الناس يستخدمون محلل DNS الخاص بـ ISP (لسبب وجيه) ، فإن الزيادة في زمن الانتقال يصبح أكثر وضوحًا.

أصبح التخزين المؤقت لنظام أسماء النطاقات مفيدًا فقط للمحتوى الذي لا يزوره أحد.

لاحظ أيضًا أن البرنامج قد يفسر TTLs المنخفض بشكل مختلف .

لماذا هذا

لماذا يتم تعيين TTL صغير لسجلات DNS؟

• يتم ترك موازنات التحميل القديمة بالإعدادات الافتراضية.
  
• هناك أساطير تعتمد موازنة تحميل DNS على TTL (هذا ليس كذلك - نظرًا لأن Netscape Navigator ، يختار العملاء عنوان IP عشوائيًا من مجموعة RR ويحاولون بشفافية استخدام عنوان آخر إذا لم يتمكنوا من الاتصال)
  
• يرغب المسؤولون في تطبيق التغييرات فورًا ، لأنه من السهل التخطيط.
  
• يرى مسؤول خادم DNS أو موازن التحميل أن مهمته هي نشر التكوين الذي يطلبه المستخدمون بشكل فعال ، بدلاً من تسريع المواقع والخدمات.
  
• انخفاض TTL تعطي راحة البال.
  
• قام الأشخاص في البداية بتعيين TTLs منخفضة للاختبار ثم ينسوا تغييرها.

لم أدرج "تجاوز الفشل" في القائمة ، لأن هذا أقل أهمية. إذا كنت بحاجة إلى إعادة توجيه المستخدمين إلى شبكة أخرى فقط لعرض صفحة الخطأ ، وعندما يكون كل شيء آخر قد انتهى ، فمن المحتمل أن يكون تأخير أكثر من دقيقة مقبولًا.

بالإضافة إلى ذلك ، يعني TTL دقيقة أنه إذا تم حظر خوادم DNS الموثوقة لأكثر من دقيقة واحدة ، فلا يمكن لأي شخص آخر الوصول إلى الخدمات التابعة. والتكرار لن يساعد إذا كان السبب هو خطأ في التكوين أو الاختراق. من ناحية أخرى ، مع TTLs معقولة ، سيستمر العديد من العملاء في استخدام التكوين السابق ولن يلاحظوا أي شيء أبدًا.

بالنسبة إلى TTLs المنخفضة ، يجب إلقاء اللوم على خدمات CDN وموازنات التحميل إلى حد كبير ، لا سيما عند دمج CNAME مع TTLs الصغيرة والسجلات مع TTLs الصغيرة (ولكن المستقلة):

  حفر $ raw.githubusercontent.com
 raw.githubusercontent.com.  9 في 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 المرتبطين:

  حفر $ raw.githubusercontent.com @ 4.2.2.2
 raw.githubusercontent.com.  1 في CNAME github.map.fastly.net.
 github.map.fastly.net.  1 في A 151.101.16.133 

يعمل محلل المستوى 3 على الأرجح في BIND. إذا raw.githubusercontent.com إرسال هذا الطلب ، فسيتم دائمًا إرجاع 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 في CNAME detectportal.firefox.com-v2.edgesuite.net.
 detectportal.firefox.com-v2.edgesuite.net.  10668 في 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 الأخرى ، يبلغ TTL الأولي 60 ثانية ، لكن بالنسبة لنطاقات akamai.net الحد الأقصى TTL 20 ثانية ، ولا يوجد أي منها في المرحلة.

ماذا عن المجالات التي تستطلع أجهزة Apple باستمرار؟

  حفر $ 1-courier.push.apple.com @ 4.2.2.2
 1-courier.push.apple.com.  1253 في CNAME 1.courier-push-apple.com.akadns.net.
 1.courier-push-apple.com.akadns.net.  1 في CNAME gb-courier-4.push-apple.com.akadns.net.
 gb-courier-4.push-apple.com.akadns.net.  1 في A 17.57.146.84
 gb-courier-4.push-apple.com.akadns.net.  1 في A 17.57.146.85 

نفس المشكلة التي يواجهها Firefox ، وسوف تتعثر TTL لمدة ثانية واحدة معظم الوقت عند استخدام محلل المستوى 3.

دروببوإكس؟

  حفر $ 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

 حفر $ client.dropbox.com @ 4.2.2.2
 client.dropbox.com.  1 في CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  1 في A 162.125.64.3 

safebrowsing.googleapis.com TTL من 60 ثانية ، تمامًا مثل نطاقات Facebook. ومرة أخرى ، من وجهة نظر العميل ، يتم تخفيض هذه القيم إلى النصف.

ماذا عن وضع حد أدنى TTL؟

باستخدام الاسم ونوع الطلب و TTL والطابع الزمني المحفوظ في الأصل ، كتبت برنامجًا نصيًا لمحاكاة 1.5 مليون طلب يمر من خلال محلل تخزين مؤقت لتقدير مقدار الطلبات الإضافية المرسلة بسبب إدخال ذاكرة التخزين المؤقت منتهية الصلاحية.

تم تقديم 47.4٪ من الطلبات بعد انتهاء صلاحية السجل الحالي. هذا هو ارتفاع غير معقول.

ماذا سيكون التأثير على التخزين المؤقت إذا تم تعيين الحد الأدنى TTL؟



محور X هو الحد الأدنى لقيمة TTL. لا تتأثر السجلات ذات TTL المصدر فوق هذه القيمة.

المحور ص - النسبة المئوية للطلبات المقدمة من العميل الذي لديه بالفعل سجل مخبأ ، ولكن انتهت صلاحيته ويقدم طلبًا جديدًا.

يتم تقليل النسبة المئوية للطلبات "الإضافية" من 47٪ إلى 36٪ من خلال تحديد الحد الأدنى لنسبة TTL في 5 دقائق. عند ضبط الحد الأدنى للنسبة المئوية للخطأ (TTL) خلال 15 دقيقة ، يتم تقليل عدد هذه الطلبات إلى 29٪. الحد الأدنى من TTL من 1 ساعة يقلل منهم إلى 17 ٪. الفرق الكبير!

ماذا عن عدم تغيير أي شيء على جانب الخادم ، ولكن بدلاً من ذلك تعيين الحد الأدنى TTL في ذاكرة التخزين المؤقت DNS العميل (أجهزة التوجيه ، محللات المحلية)؟



يتم تقليل عدد الطلبات المطلوبة من 47 ٪ إلى 34 ٪ عندما يتم تعيين الحد الأدنى TTL إلى 5 دقائق ، إلى 25 ٪ مع حد أدنى 15 دقيقة و 13 ٪ مع ما لا يقل عن 1 ساعة. ربما القيمة المثلى هي 40 دقيقة.

تأثير هذا التغيير ضئيل للغاية.

ما هي الآثار؟

بالطبع ، يمكن نقل الخدمة إلى مزود سحابة جديد ، خادم جديد ، شبكة جديدة ، مما يتطلب من العملاء استخدام أحدث سجلات DNS. و TTL صغير بما فيه الكفاية يساعد بسلاسة وسلاسة إجراء مثل هذا الانتقال. ولكن مع الانتقال إلى بنية تحتية جديدة ، لا يتوقع أحد أن يتحول العملاء إلى سجلات DNS الجديدة خلال دقيقة واحدة أو 5 دقائق أو 15 دقيقة. إن تحديد عمر 40 دقيقة كحد أدنى بدلاً من 5 دقائق لن يمنع المستخدمين من الوصول إلى الخدمة.

ومع ذلك ، فإن هذا سوف يقلل بشكل كبير من الكمون ويزيد من السرية والموثوقية ، وتجنب الطلبات غير الضرورية.

بطبيعة الحال ، يقول RFCs أنك بحاجة إلى فرض TTL بدقة. ولكن الحقيقة هي أن نظام DNS أصبح غير فعال للغاية.

إذا كنت تعمل مع خوادم DNS موثوقة ، يرجى التحقق من TTL الخاص بك. هل حقا بحاجة الى مثل هذه القيم المنخفضة يبعث على السخرية؟

بالطبع ، هناك أسباب وجيهة لوضع TTLs صغيرة لسجلات DNS. لكن ليس لـ 75٪ من حركة مرور DNS ، والتي لم تتغير فعليًا.

وإذا كنت تحتاج حقًا إلى استخدام TTL منخفض لنظام أسماء النطاقات لسبب ما ، فتأكد في الوقت نفسه من عدم تمكين التخزين المؤقت على موقعك. لنفس الأسباب.

إذا كان لديك ذاكرة تخزين مؤقت DNS محلية ، مثل dnscrypt-proxy ، والتي تسمح لك بتعيين الحد الأدنى من TTL ، استخدم هذه الوظيفة. هذا طبيعي. لن يحدث شيء سيء. اضبط الحد الأدنى لنسبة TTL بين 40 دقيقة تقريبًا (2400 ثانية) وساعة واحدة. تماما مجموعة معقولة.