سلامة إعدادات DNS للشبكات الصغيرة
تصف سجلات DNS الخدمات التي تنشرها والنطاقات التي ترسل البريد منها، وقد تبقى هذه الأوصاف بعد تغيّر الواقع. فسجل يشير إلى عنوان لم تعد تسيطر عليه قد يوجّه الزوار إلى طرف آخر، وسياسة بريد لا تُراجع قد تترك مجالًا لانتحال اسمك. في الشبكة الصغيرة، يتمثل معظم العمل في إبقاء الإجابات المنشورة صحيحة، وجعل كل سجل يعبّر بدقة عن غرضه.
SPF ببساطة
يحدد Sender Policy Framework، أو SPF، المضيفين المسموح لهم باستخدام نطاقك في غلاف SMTP. يفحص المستقبل سجل النطاق الوارد في MAIL FROM، أي عنوان الإرجاع في غلاف الرسالة، وقد يفحص هوية HELO أو EHLO بصورة مستقلة. توصي RFC 7208 بفحص HELO أولًا عندما تُفحَص الهويتان. وقد تُعامَل رسالة المضيف غير المصرّح له باعتبارها مريبة.
لا يصادق SPF على ترويسة From التي يراها القارئ في تطبيق البريد. تربط محاذاة النطاقات ضمن DMARC نتيجة SPF بنطاق From، ولذلك فإن السماح لمضيفيك بالإرسال ليس القصة كلها.
يُنشر SPF كسجل TXT لنطاق. قد يكون عند النطاق الذي ترسل منه، أو عند نطاق فرعي مخصص لغلاف البريد بدل النطاق الظاهر للمستخدم. ومن آلياته ip4 وip6 وa وmx وinclude وall. اجعل القائمة واضحة ومختصرة. يُسمح أثناء التقييم بعشرة بنود كحد أقصى تؤدي إلى استعلامات DNS، بما فيها البنود المتداخلة عبر include وredirect. هذا حد للبنود التي تُقيَّم، لا لعدد حزم DNS المنفردة. وقد تؤدي كثرة تضمينات المزوّدين إلى تجاوزه وظهور خطأ دائم يمنع الحصول على تصريح SPF صالح (RFC 7208).
أنه السياسة بوضوح. تجعل -all المرسل غير المطابق للآليات السابقة يحصل على نتيجة فشل SPF، وقد يرفض المستقبل الرسالة أو يعاملها بوصفها مريبة. ويمكن استخدام redirect لإحالة التقييم إلى سياسة مشتركة تديرها لعدة نطاقات.
اختبر التغيير قبل النشر. قد يؤدي الخطأ إلى رفض بريد شرعي أو فقدان المحاذاة، كما تحتفظ خوادم DNS بالإجابة وفق TTL؛ فلا يكفي إصلاح السجل لزوال الإجابات المخزنة فورًا.
DKIM وسلامة الرسالة
يضيف DomainKeys Identified Mail، أو DKIM، توقيعًا تشفيريًا إلى البريد الصادر. يغطي التوقيع ترويسات مختارة وبصمةً لمحتوى الرسالة. يتحقق المستقبل منه بمفتاح عام منشور تحت اسم محدِّد، مثل selector1._domainkey.example.com.
يطبق DKIM قواعد محددة لتوحيد الصيغة، ولذلك يتحمل بعض تغييرات التنسيق. يفشل التحقق عندما تغيّر التعديلات البيانات المشمولة بعد توحيد صيغتها. لا يحمي التوقيع الترويسات غير الموقعة، وقد يترك حد اختياري لطول المحتوى جزءًا مضافًا خارجه. توضّح RFC 6376 هذه الحدود؛ فلا يصح افتراض أن كل تعديل، مهما كان، يبطل كل توقيع.
يحتاج DKIM إلى تنسيق بين خادم البريد وDNS. يوقّع الخادم بمفتاح خاص يبقى محميًا لديه، وتُنشر نسخته العامة في سجل TXT. جهّز تدوير المفاتيح مسبقًا: انشر محدِّدًا جديدًا، ثم ابدأ التوقيع به، وأبقِ المحدِّد القديم حتى تنتهي حاجة الرسائل الموقعة به إلى التحقق، ثم احذفه.
DMARC طبقة السياسة
يجمع DMARC نتائج المصادقة مع سياسة للنطاق الظاهر في From. تمر الرسالة إذا نجح SPF وكانت هويته محاذية لنطاق From، أو إذا نجح DKIM وكان نطاق توقيعه محاذيًا له. لا يلزم نجاح الاثنين معًا.
إذا لم توفر أي منهما نجاحًا محاذيًا، يفشل DMARC. ولا يثبت ذلك التزوير؛ فقد يتسبب تحويل البريد أو تعديل الرسالة في الفشل أيضًا، ويطبق المستقبل سياسته الخاصة للتعامل معها (RFC 7489).
للمحاذاة نمطان. في النمط المرن يكفي الاشتراك في النطاق التنظيمي؛ مثل محاذاة sub.example.com مع example.com. أما النمط الصارم فيتطلب تطابق النطاقين تمامًا. يناسب النمط المرن عادةً إرسال البريد من نطاقات فرعية.
تأخذ السياسة p= إحدى القيم none أو quarantine أو reject للرسائل الفاشلة. ابدأ بالمراقبة وقراءة التقارير، ثم اختبر الحجر عندما تفهم مصادر الإرسال الشرعية. انتقل إلى الرفض بعد حصر تلك المصادر والتحقيق في حالات الفشل المتبقية. تساعد نسبة التطبيق في التدرج، وتتحكم sp= بسياسة النطاقات الفرعية، التي تتبع السياسة الرئيسية عند غيابها.
تُطلب التقارير داخل السجل نفسه: rua للتقارير المجمّعة، وruf لتقارير فشل الرسائل المنفردة. يعرض التقرير المجمّع عادةً مصادر الإرسال ونتائج المحاذاة، لكن إرساله يعتمد على المستقبل وسياسته. غياب مصدر من التقارير لا يثبت أنه لم يرسل. اقرأها بوصفها بيانات تشغيلية، فقد تكشف مضيفين يرسلون باسم نطاقك دون اختيارك.
DNSSEC وسلسلة الثقة
يضيف DNSSEC توقيعات إلى بيانات DNS ليتحقق المحلّل من مصدر الإجابة وعدم تعديلها. يحتاج إلى دعم مضيف المنطقة لتوقيعها، وإلى نشر سجل DS عبر جهة تسجيل النطاق لربطها بسلسلة الثقة. غياب أحد الجانبين يمنع اكتمال السلسلة.
صيانة المفاتيح والتوقيعات عمل مستمر. إذا انتهت التوقيعات دون تجديد، تفشل الإجابات لدى المحلّلات التي تتحقق من DNSSEC. ضع مواعيد الصيانة في جدول التشغيل، مع الانتباه إلى أن DNSSEC يحمي إجابة DNS، لا الخدمة التي تشير إليها؛ فقد يشير سجل صحيح التوقيع إلى خادم به مشكلة.
نظافة السجلات
احذف سجلات الخدمات المتوقفة. فقد يوجّه عنوان قديم الحركة إلى من أصبح يملك ذلك العنوان.
تحدد TTL مدة تخزين الإجابة. القيم القصيرة تزيد الاستعلامات إلى الخوادم الموثوقة لأن المحلّلات تعيد السؤال أسرع، والطويلة تقللها لكنها تؤخر انتشار التغيير. اخترها وفق وتيرة تغيّر السجل.
تعيش سجلات PTR في مناطق عكسية منفصلة عن منطقتك الأمامية: in-addr.arpa لـ IPv4 وip6.arpa لـ IPv6. يتحكم فيها عادةً صاحب تخصيص عنوان IP، وغالبًا يكون مزوّد الاستضافة في حالة البريد. تطلب RFC 1912 توافق سجلات PTR وA، وتوصي بتوفير PTR للعناوين القابلة للوصول؛ وتفحص أنظمة بريد كثيرة هذا التوافق عند استقبال البريد (RFC 1912).
قائمة تحقق
- انشر سجل SPF واحدًا للنطاق المستخدم في الإرسال، عند النطاق الرئيسي أو نطاق غلاف البريد الفرعي، وأنهِ السياسة بوضوح.
- التزم بحد عشرة بنود تستدعي DNS، مع احتساب البنود المتداخلة.
- وقّع البريد بـ DKIM، وانشر المفتاح، ولا تحذف المحدِّد القديم قبل انتهاء الحاجة إلى التحقق من رسائله.
- ابدأ DMARC بالمراقبة، واقرأ التقارير، ثم انتقل إلى الحجر والرفض بعد فهم الإرسال الشرعي.
- فعّل DNSSEC عندما يدعمه المضيف والمسجّل، وخطّط لصيانة المفاتيح والتوقيعات.
- احذف السجلات غير المستخدمة واضبط TTL وفق احتياجات التغيير.
- حافظ على توافق الأسماء الأمامية والعكسية لعناوين إرسال البريد.