DNS
مراقبة DNS
أنه يتم حله، وأن الإجابة هي بالضبط ما تتوقعه.
جربه الآن
فحص واحد، من مكان واحد، الآن، ولا يتم حفظ أي شيء. المراقب يتحقق من كل موقع نعمل فيه ويؤكد الفشل من قارتين أخريين قبل أن يتم إيقاظ أي شخص، وهو ما لا يمكن أن يظهره نظرة واحدة.
ما الغرض منه
كل فحص آخر في هذه القائمة يعتمد على DNS، وDNS هو الشيء الوحيد الذي يمكن أن يفشل بينما كل شيء يشير إليه يكون صحيًا تمامًا. نقل منطقة حدث خطأ فيه، لوحة تسجيل قام شخص بتحريرها، تفويض منتهي الصلاحية: الموقع يعمل ولكنه غير قابل للوصول.
الفشل الذي يستحق الدفع مقابله أضيق من ذلك. يمكن للسجل أن يتم حله بسرعة، من كل محلل، ويشير إلى عنوان شخص آخر. لا شيء يتحقق مما إذا كانت إجابات DNS ستراه أبدًا. أعطنا الإجابة التي تتوقعها وسنقوم بفحص ذلك بدلاً من ذلك.
مثل كل فحص هنا، يتم تشغيله من Amsterdam, New York, Sydney and Singapore، ويتم تأكيد الفشل من قارتين أخريين قبل أن يتم إيقاظ أي شخص. كيف يعمل ذلك.
ما يمكنك ضبطه
كل ما هو أدناه موجود في النموذج عند إضافة واحد، على كل خطة.
- سجل
- A، AAAA، MX، TXT، NS، CNAME أو SOA.
- الإجابة المتوقعة
- الفحص الفارغ يتحقق من أن الاسم يتم حله على الإطلاق. عند ملئه، يتحقق من أن الإجابة لا تزال صحيحة، وهو الفشل الذي لا يلتقطه أي شيء آخر.
- مطابقة
- أي منها، أو هذه بالضبط. اختيار هذه بالضبط هو الطريقة الوحيدة لملاحظة إضافة سجل بدلاً من تغييره.
- اسأل هذا المحلل
- حدد خادمك الموثوق الخاص وسترى التغيير فور حدوثه، بدلاً من الانتظار حتى انتهاء صلاحية ذاكرة التخزين المؤقت للمحلل الذي نستخدمه.
الأسئلة
ما أنواع السجلات التي يمكنك مراقبتها؟
A، AAAA، CNAME، MX، TXT، NS وSOA موجودة في النموذج، ويتم قبول CAA، PTR وSRV أيضًا. القائمة أقصر عمدًا من كل ما يمكن أن يحتويه DNS: كل سجل هنا تغييره هو شيء سيلاحظه العميل، وهو النوع الوحيد الذي يستحق التنبيه.
ما الفرق بين NXDOMAIN وSERVFAIL؟
NXDOMAIN تعني أن الاسم غير موجود: خطأ مطبعي، سجل محذوف، أو تفويض انتهت صلاحيته. SERVFAIL تعني أن خوادم الأسماء تم سؤالها ولم يقدم أي منها إجابة قابلة للاستخدام، مما يشير إلى منطقة معطلة أو خوادم غير متصلة. الحالة الثالثة، وجود الاسم بدون سجل من هذا النوع، يتم الإبلاغ عنها بشكل منفصل لأن لكل منها إصلاحات مختلفة.
هل يمكنك إخباري ما إذا كان التغيير قد انتشر؟
جزئيًا، ومن المهم أن نكون دقيقين بشأن ما هو الانتشار: لا شيء ينتشر للخارج، فقط تنتهي صلاحية ذاكرات التخزين المؤقت وفقًا لوتيرتها الخاصة. يتم إجراء الفحوصات من ثلاث قارات، لذا يظهر التغيير الذي وصل إلى واحدة ولم يصل إلى الأخرى كاختلاف. حدد خادمك الموثوق الخاص وسترى التغيير فور حدوثه بدلاً من ذلك.
هل يمكن لهذا اكتشاف اختراق DNS؟
هذا هو الفشل الذي تم تصميمه من أجله. يمكن أن يتم حل سجل بسرعة، من كل محلل، مع TTL صحي، ويشير إلى عنوان شخص آخر؛ لا شيء يسأل فقط ما إذا كان DNS قد أجاب سيرى ذلك. أدخل الإجابة التي تتوقعها وسيفشل السجل الذي يشير إلى أي مكان آخر خلال فترة واحدة.
هل تتحقق من TTL، أو تصدق على DNSSEC؟
لا، ونقول ذلك بدلاً من الإيحاء بخلاف ذلك. TTL هو ما تقوله منطقتك وهذا لا يؤكد عليه، وتوقيعات DNSSEC غير معتمدة. ما يتم التحقق منه هو الإجابة التي تعود وما إذا كانت لا تزال الإجابة التي تتوقعها، وهو الفشل الذي لا يمكن لبقية مراقبتك رؤيته.
ما الذي يفعله التطابق الدقيق ولا يفعله التطابق العام؟
أي منها ينجح عندما تكون القيمة المتوقعة موجودة في الإجابة، وهو ما تريده لاسم خلف مجموعة من العناوين. تفشل هذه بالضبط عندما يتم إضافة أي شيء، والإضافة هي الطريقة التي يصل بها الضرر عادةً: سجل A إضافي أو MX إضافي بجانب سجلك هو اكتشاف تغيير السجل الذي لا يكتشفه أي شيء آخر.
لماذا لا تستخدم dig من خلال سكربت؟
يمكنك، وللتحقق من سجل واحد مرة واحدة فهو الأداة المناسبة. الصعوبة هي أنه لا يوجد شيء مثل الإجابة: ما يعيده المحلل الخاص بك وما يعيده محلل في سيدني يمكن أن يختلف طالما أن TTL، وسكربت على جهاز واحد يسأل محللًا واحدًا يرى واحدة من تلك الإجابات. هذا يسأل من أربع قارات ويمكن توجيهه إلى محلل محدد، وهو ما يحول البحث إلى مقارنة.
يسرسل لي المسجل بريدًا إلكترونيًا عند تغيير سجل. أليس هذا كافيًا؟
احتفظ به، فهو تحقق حقيقي وهو أسرع طريقة لمعرفة أن شخصًا ما في فريقك قد غيّر شيئًا. ما يغطيه هو الحالة التي يتم فيها التغيير عبر المسجل الخاص بك، وهو الذي كنت أقل قلقًا بشأنه. لا يقول شيئًا عندما يتم تغيير سجل في مزود تستخدمه أيضًا، عندما يحدث خطأ في نقل المنطقة، أو عندما يعيد محلل في مكان ما شيئًا لم ينشره مسجلك أبدًا. هذه هي الإخفاقات التي تبدو وكأنها لا توجد مشكلة.