تحويل البحث إلى سؤال دقيق
استخدم Dig لسؤال خادم DNS مسمى عن المالك المحدد ونوع السجل، ثم احتفظ بالسياق الكافي لتفسير الرد. بالنسبة لمصادقة البريد الإلكتروني، نادرًا ما يكون السؤال المركزي هو ما إذا كان النطاق يحتوي على أي مجال أم لا سجلات TXT. يتعلق الأمر بما إذا كانت التبعية التي يستخدمها المرسل أو المدقق موجودة بالاسم الصحيح ويمكن حلها من خلال المسار ذي الصلة.
تستهدف الأمثلة الواردة في هذا الدليل بناء الجملة الموثق لـ ISC BIND 9.20.13 dig. هذا عبارة عن نطاق توثيق مثبت، وليس ادعاءً بأن كل حفر مثبت لديه هذا الإصدار أو أنه الإصدار الأحدث. جميع الأوامر مقترحة لاستعلامات DNS للقراءة فقط أو التحقق من الإصدار المحلي. لم يتم إعدام أي منهم هنا. أسماء example.com وعناوين 192.0.2.0/24 هي عناصر نائبة للوثائق، وليست إعدادًا لمحلل فعال.
ابدأ بالهوية التي يستخدمها البريد الإلكتروني بالفعل
ل SPF، حدد المجال المستخدم في هوية SMTP ذات الصلة بدلاً من استخدام المجال المرئي من المجال تلقائيًا. ل DKIM، خذ مجال التوقيع و محدد من توقيع الرسالة يجمع مالك البحث الرئيسي بين المحدد، _domainkey وتوقيع المجال. لا تخمن محددًا من اسم البائع. RFC 7208 RFC 6376
بحث عن _dmarc.example.com. يمكن فحص سجل السياسة لدى ذلك المالك. إنه ليس في حد ذاته تنفيذًا كاملاً لاكتشاف السياسة أو تنسيق تقييم. احتفظ بهوية الرسالة وسياق اكتشاف السياسة المعمول به عند تسليم النتائج إلى متخصص بريد. تنتمي رؤية DNS ونتائج المصادقة إلى مجالات أدلة ذات صلة ولكن منفصلة. RFC 9989
اكتب ورقة أسئلة مع المالك ونوعها وسبب الاستعلام والسلطة المتوقعة. يمنع هذا الإعداد الصغير قبول الإجابة ذات المظهر الجذاب للنطاق الخاطئ كحل. النقطة الزائدة تجعل أسماء الأمثلة أسماء DNS مطلقة صريحة.
اجعل الاستعلام الأولي قابلاً للتكرار
القيادة المحلية المقترحة حفر -v يسجل إصدار الأداة. للحصول على شكل استعلام متحكم فيه، استخدم حفر -r @ 192.0.2.53 _dmarc.example.com . TXT. ال -r يتجنب الخيار إعدادات الحفر الافتراضية لكل مستخدم، بينما تحدد وسيطة الخادم خادم DNS . استبدل كلا العنصرين النائبين فقط للبحث المعتمد بشكل منفصل. احتفظ بالمخرجات الكاملة قبل عمل مستخلص مضغوط. دليل حفر ISC
سجل وقت UTC وسياق الشبكة المصدر والخادم الذي تم الإبلاغ عنه فعليًا في النتيجة. تجنب البدء بأمر يخفي كل شيء باستثناء الإجابات. قد يكون العرض القصير للإجابة فقط مناسبًا لاحقًا، لكن الدليل الأولي يجب أن يحافظ على أقسام السؤال والحالة والإشارات والإجابة والسلطة، بالإضافة إلى الرسائل المتعلقة بالنقل. هذه التفاصيل تميز الغياب والإحالة والفشل.
الأسئلة المصاحبة المقترحة هي حفر -r @ 192.0.2.53 example.com . TXT و dig -r @ 192.0.2.53 selector1._domainkey.example.com . TXT. هذه أمثلة على بناء الجملة، وليست ادعاء بأن أيًا من الاسمين يحتوي على سجل مصادقة. حدد الأسماء الفعلية من التحقيق المعتمد، ولا تتعامل مطلقًا مع أي استعلام على أنه مخزون مضمون لكل شيء في المنطقة.
قارن الملاحظات العودية والموثوقة
قم أولاً بتحديد الخادم الذي قمت بالاستعلام عنه. يمكن للمحلل العودي إرجاع البيانات المخزنة مؤقتًا؛ يجيب الخادم الرسمي على المناطق التي يخدمها. للمقارنة مع سلطة تم التحقق منها بشكل منفصل، النموذج المقترح هو حفر -r @ 192.0.2.54 _dmarc.example.com . TXT + لا يوجد لعنة. لا يؤدي تعطيل العودية إلى جعل الخادم التعسفي موثوقًا. تحقق من الرد وأدلة التفويض بدلاً من الوثوق بعنوان IP المختار وحده. RFC 1034
إذا اختلفت النتائج العودية والموثوقة، فاحتفظ بكليهما. قارن الأسماء والأنواع والقيم وحالة الاستجابة والطوابع الزمنية قبل إلقاء اللوم على الانتشار. يعد انخفاض مدة البقاء المخزنة مؤقتًا مفيدًا ولكنه ليس موعدًا نهائيًا عالميًا لانتهاء الصلاحية لكل مراقب. يتبع إدخال ذاكرة التخزين المؤقت السلبي أيضًا قواعده الخاصة. RFC 2308
اقرأ الجواب هيكليا. يمكن أن تنتمي عدة سلاسل أحرف مقتبسة إلى سجل مورد TXT واحد؛ العديد من سجلات موارد TXT لها حالة مختلفة. لا تقم بتسوية كلا النموذجين في سلسلة واحدة مفصولة بمسافات. احتفظ بحدود السجلات قبل أن يقوم متخصص البريد بتقييم بناء جملة نظام التعرف على هوية SPF أو DKIM . أ CNAME يقدم اسمًا آخر للتحقيق بدلاً من إثبات توفر المفتاح النهائي أو نص السياسة. RFC 1035
تتبع التفويض فقط عندما يكون هذا هو السؤال
الاستعلام المقترح حفر -r + تتبع example.com . ن.س يتبع الإحالات من الجذر. يرسل استعلامات شبكة متعددة، لذا قم بالموافقة على نطاق التشخيص وفقًا لذلك. لا تؤدي إضافة وسيطة خادم إلى إبقاء التتبع بأكمله مقتصراً على محلل البيانات هذا. يقوم التتبع بالتحقيق في التفويض من شبكة المشغل؛ ولا يعيد إنتاج كل قرار يتخذه مستقبل البريد الإلكتروني عن بعد. دليل حفر ISC
عند مراجعة التتبع، حدد آخر إحالة ناجحة والخوادم التي تم الاتصال بها والمكان الذي توقف فيه الحل. إن انتهاء المهلة في مرحلة ما لا يعد إذنًا بالتحرير خوادم الأسماء. قارن النتائج مع مخزون المسجل ومالك DNS ، ثم قم بتعيين التحقيق التالي إلى المالك المناسب. تجنب تحويل تتبع واحد غير مكتمل إلى توصية ترحيل.
اجعل مطالبات الفشل والتحقق ضيقة
يحتاج NXDOMAIN ، والاستجابة الناجحة بدون البيانات المطلوبة، و SERVFAIL إلى خطوات تالية مختلفة. لا تترجم الثلاثة إلى سجلات مصادقة مفقودة. في حالة الاشتباه في النقل، يقترح +برنامج التعاون الفني يمكن أن تساعد المقارنة في فصل المسارات، لكن النجاح في عملية نقل واحدة لا يثبت أن كل جهاز استقبال يمكنه تحليل السجل. RFC 1035 RFC 7766
الحفر +dnssec طلبات الخيار DNSSEC مادة؛ إن وجودها ليس نتيجة التحقق من صحة التشفير المستقلة. احتفظ باستنتاجات التحقق من الصحة مرتبطة بسلوك المحلل المناسب والأدلة الموثوقة. قم بإنهاء التحقيق ببيان موجز عن الخادم الذي أجاب على أي سؤال ومتى وما الذي لا يزال غير مؤكد. لا تزال النصوص الرسمية والتكرارية ذات الطابع الزمني المطلوبة لهذه المقالة مفقودة؛ هذه الأوامر المقترحة ليست بدائل لها.