اختبار انقطاع DNS والأبوة في GoDaddy: من هو GoDaddy الخاص بك؟
في حلقة أخرى من اختبار الأبوة موري بوفيتش على تلفزيون انقطاع DNS أمس. بعد أن كتبت للتو عن انقطاع كبير في AT & T DNS في 15 أغسطس ، ها نحن مرة أخرى في 10 سبتمبر 2012 نشهد انقطاع GoDaddy DNS. الملايين من مستخدمي مواقع الويب والبريد الإلكتروني عملية البحث عن DNS تلعب مثل حلقة تلفزيون Maury Povich من اختبار الأبوة بشكل خاطئ. في المرة الأولى التي يكتب فيها زوار موقع GoDaddy عنوان URL الخاص ب GoDaddy في متصفحهم وتعود الإجابة من DNS “هذا ليس GoDaddy الخاص بك”. أو شيء من هذا القبيل.
التعامل مع رفض انقطاع DNS
علاوة على ذلك ، في الشهر الماضي كان انقطاع DNS مع AT&T DNS. لذا ، ما الذي يجب على مالك موقع الويب فعله الآن بعد أن تم الكشف عن مزود DNS “الأب الكبير” الآخر (مرة أخرى) على أنه غير موثوق به تماما؟ أحد الخيارات هو التبديل إلى موفري DNS آخرين والرهان على أن مزود DNS “هذا” محصن بطريقة أو بأخرى ضد تقلبات الإنترنت. أو ، خيار آخر هو التوقف عن خداع نفسك ، والنمو والقيام بشيء واقعي حول حقيقة أن مزودي DNS – مثل كل شيء آخر على الإنترنت – ليسوا مثاليين ولن يكونوا أبدا. السيدات والسادة ، توقعنا غير الجريء تماما هو – سيحدث انقطاع كبير في DNS مرة أخرى قريبا.
احصل على حقيقة حقيقية باستخدام DNS الخاص بك: لا تستخدم مجموعة اختبار DNS ملوثة
أود أن أجادل بأن الخيار الأفضل هو وضع مراقبة موقع الويب باستخدام منهجية مراقبة “غير قائمة على ذاكرة التخزين المؤقت” من شأنها اكتشاف مشكلات DNS (يمكنك الاختبار باستخدام بحث DNS غير المؤقت هنا – مجانا باستخدام Trace Style “DNS”). ملاحظة: لن تكتشف خدمة المراقبة المستندة إلى ذاكرة التخزين المؤقت مشكلات DNS بدقة – فقط طريقة غير مستندة إلى ذاكرة التخزين المؤقت ستفعل ذلك. في نهاية كل اختبار أبوة ، يقول موري بوفيتش “أنت الأب” ، أو “أنت لست الأب”. في الأساس ، إذا كنت تستخدم طريقة ذاكرة التخزين المؤقت لمراقبة العبارة ، فستكون أشبه ب “قد تكون أو لا تكون أبا – لا يمكننا معرفة ذلك”. ليس التلفزيون الجيد ، ولا مراقبة DNS جيدة.
القبول 1: التخطيط لانقطاع DNS في المستقبل
كما كتبت “القيام بمراقبة DNS بشكل صحيح: انقطاع AT & T DNS” ليس من المعروف عموما أن منهجية مراقبة HTTP الاصطناعية الأساسية لمراقبة موقع الويب تأتي في “نكهتين” – لاستخدام منهجية “ذاكرة التخزين المؤقت” أو “غير ذاكرة التخزين المؤقت”. يؤثر اختيار المنهجية من قبل خدمة المراقبة بشكل مباشر على قدرتها على اكتشاف المشكلات على خوادم DNS الثانوية ، مثل انقطاع GoDaddy DNS وانقطاع AT&T DNS. من ناحية ، تعد الطريقة المستندة إلى ذاكرة التخزين المؤقت أبسط بكثير بالنسبة لأعمال المراقبة لتنفيذها وتكلف أقل للإعداد والإدارة. في الواقع ، تستخدم معظم خدمات مراقبة وقت التشغيل “الأساسية” منخفضة التكلفة “طريقة ذاكرة التخزين المؤقت”.
القبول 2: ليس GoDaddy DNS ، وليس لا أحد DNS مثالي
على وجه التحديد ، السبب في أن عدم التخزين المؤقت أكثر فعالية من حيث التكلفة هو أنه عندما تحدث مشكلة مثل انقطاع GoDaddy و AT&T DNS دائما – كما هو الحال عند حدوث أي حالة خطأ في موقع الويب – فإن إجمالي وقت الإصلاح (TTR) هو الذي يحدد الخسارة بسبب تعطل موقع الويب. وبعبارة أخرى ، فإن إجمالي الوقت (1) الذي يستغرقه اكتشاف الخطأ وتشخيصه وإصلاحه كلما كان تأثير الخطأ أسوأ. على العكس من ذلك ، كلما كان حل المراقبة أسرع في تسريع TTR كلما تم تقليل الخسارة (أو تجنبها تماما).
حسنا ، أنا أملك DNS الخاص بي – الآن ماذا؟
اتخذ إجراء لمعالجة انقطاع DNS الخاص بك وقت الإصلاح قبل حدوث انقطاع DNS مرة أخرى:
انظروا كلنا نرتكب أخطاء. الحياة ، وانتشار DNS ، يحدث فقط. دعنا نجري بعض التغييرات الصغيرة ونتفوق على ذلك ، لذلك في المرة القادمة التي يحدث فيها ذلك ، ليس مهرجانا كبيرا للاعتذار على Twitter ويفزع لمستخدمي موقع الويب الخاص بك ، حسنا؟
– طريقة اكتشاف الأخطاء: اختبار موقع ويب غير مؤقت وحل مراقبة DNS يستخدم طريقة غير ذاكرة التخزين المؤقت لنشر استعلامات DNS على طول الطريق إلى خوادم أسماء الجذر مع كل مثيل مراقبة. تقوم خدمة طريقة ذاكرة التخزين المؤقت بتخزين DNS مؤقتا وبالتالي لن تكتشف مشكلة DNS ثانوية على الإطلاق، أو قد يستغرق الأمر أياما أو أسابيع للكشف عن المشكلة.
-تردد المراقبة: استخدم ترددا أسرع للمراقبة غير ذاكرة التخزين المؤقت ، مثل كل 1 دقيقة مقابل مرة واحدة في الساعة. كلما كان حل المراقبة غير المؤقت أسرع في اكتشاف وتنبيه مسؤول متأثر بموقع ويب باستخدام خدمة DNS فاشلة ، كلما كان من الممكن إجراء تبديل أسرع إلى موفر تجاوز فشل DNS.
– إعداد تكرار وقت العمل (TTL): كلما كانت قيمة إعداد تردد وقت البث المباشر (TTL) أصغر الذي يستخدمه مسؤولو DNS لتعيين التخزين المؤقت لنظام أسماء النطاقات إلى خادم DNS ثانوي لاسم المجال من خادم الاسم الموثوق به الأساسي. عادة ما يتم تعيينها إلى 86,400 ثانية (1 يوم) أو أكثر ، في التخطيط للتعافي من الكوارث ، يمكن تعيين TTL مرة واحدة كل 300 ثانية ، ولكن كلما انخفض الإعداد ، زاد الحمل على خادم اسم المجال الموثوق.
-التشخيصات – تأكد من أن خدمة مراقبة موقع الويب الخاص بك توفر تشخيصات عند حدوث خطأ ، مثل مسار تتبع تلقائي في وقت اكتشاف مشكلة DNS. بدون تشخيص كيف ستعرف ما هي المشكلة؟ ملاحظة: لا توفر العديد من خدمات المراقبة الأساسية أي معلومات تشخيصية.
-إصلاح: استمر في مراقبة الحل أثناء حالة الخطأ لتحديد المشكلة بشكل أكبر. أرسل النتائج التي تمت مراقبتها إلى موفر DNS. يمكنك أيضا تشغيل مسارات تتبع DNS اليدوية المجانية غير المخزنة مؤقتا هنا (حدد تتبع النمط “DNS”) للتحقق من المشكلة حسب الحاجة.
-منع: استخدم حل مراقبة يسمح لك بعرض تفاصيل بحث DNS (مثل مراقبة المتصفح الفعلية) من أجل رؤية “الأخطاء الناعمة” مثل اتجاهات التباطؤ والمشكلات المتقطعة ، حتى تتمكن من اتخاذ إجراء قبل أن يصبح “الخطأ الناعم” “خطأ فادحا” مثل العميل الذي يواجه وقت توقف.
الخطوات التالية: “وفي غضون بضعة أشهر سنتابع ونرى كيف هي”
اختبار DNS فوري مجاني غير مؤقت هنا تجريبي مجاني لمدة 30 يوما لمراقبة DNS غير ذاكرة التخزين المؤقت هنا إعداد حساب مراقبة DNS الكامل هنا
(1) وفقا للمنظمات التي شاركت في دراسة أجرتها لجنة الحقيقة والمصالحة، في أيلول/سبتمبر 2011، حددت المنظمات مقدار الوقت الذي تقضيه في استكشاف مشكلات الأداء وإصلاحها باعتباره التحدي الأكبر الذي تواجهه “في المتوسط، على مدى أسبوع عمل كامل من ساعات العمل (46.2 ساعة) التي تقضيها في مواقف غرف الحرب كل شهر”.
