Defaults.Exposed › الإصلاحات › سجلات CAA

كيف تُصلح سجلات CAA

سجل CAA تعليمة قصيرة في إعدادات نطاقك تُسمّي شركات الشهادات المسموح لها بإصدار شهادة 'القفل' الأمنية لموقعك. ومع تفعيله، لا تستطيع أي شركة أخرى أن تُنشئ بهدوء شهادة صالحة باسمك.

الخلاصة لعملك: بدون سجل CAA، يمكن لأي من مئات شركات الشهادات حول العالم تقريباً إصدار شهادة قفل حقيقية وموثوقة بالكامل لنطاقك — مُتيحةً لمحتال إقامة نسخة مطابقة لموقعك تبدو 'آمنة' بلا عيب لحصاد عمليات تسجيل دخول عملائك وتفاصيل بطاقاتهم، دون أي شيء على الشاشة يحذّرهم.

ماذا قد يكلّفك هذا

يحصل محتال على شهادة حقيقية لنسخة من موقعك، فتُظهِر القفل الأخضر وHTTPS — لا يرى عملاؤك أي خطأ، يكتبون كلمات مرورهم وأرقام بطاقاتهم، ولا تعلم بالأمر إلا حين تبدأ عمليات ردّ المبالغ والمكالمات الغاضبة.
يُصاد عملاؤك عبر نسخة مطابقة تماماً لصفحة تسجيل الدخول لديك؛ والتبعات — المبالغ المعادة، وعبء الدعم، والضرر بالسمعة — تقع على علامتك التجارية رغم أن موقعك الحقيقي لم يُمَسّ أبداً.
يُجري فريق الأمن أو المشتريات لدى عميل محتمل فحصاً سريعاً على نطاقك قبل التوقيع، فلا يجد حماية CAA، فيخفض تقييمك بهدوء كـ 'ضعيف في الأساسيات' — مُعرّضاً صفقة للخطر بسبب إعداد يستغرق خمس دقائق لإضافته.
تُخترَق إحدى شركات الشهادات في العالم (وقد حدث هذا مراراً — DigiNotar، Comodo، Symantec)، ولأنك لم تقل أبداً من يُسمَح له بالتصرّف نيابة عنك، يكون نطاقك معرّضاً لأيّها يتبيّن أنه الحلقة الأضعف.

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

سجلات CAA، بكلمات بسيطة

لكل موقع آمن شهادة — الشيء الكامن وراء القفل في المتصفح و”https” في مقدمة عنوانك. وتُوزَّع تلك الشهادات من قِبل شركات متخصّصة تُسمّى جهات الشهادات (CAs): أسماء مثل Let’s Encrypt وDigiCert وSectigo وGoogle Trust Services. وحين يرى متصفحك شهادة صالحة، يُظهِر القفل ويُخبر عميلك بأن الاتصال حقيقي وآمن.

إليك الجزء الذي لم يُخبَر به معظم أصحاب الأعمال يوماً: افتراضياً، يُسمَح لمئات من جهات الشهادات هذه حول العالم لكلٍّ منها بإصدار شهادة لنطاقك أنت — سواء سمعت بها يوماً أم لا. وسجل CAA (تخويل جهة الشهادات) ملاحظة من سطر واحد تضيفها إلى إعدادات DNS لنطاقك تقول، في جوهرها، “يُسمَح لـ هؤلاء المزوّدين فقط بإصدار شهادات لي.” وكل جهة شهادات مشروعة مُلزَمة بقواعد الصناعة بفحص تلك الملاحظة قبل الإصدار — وبالرفض إن لم تكن مدرَجة في قائمتك.

إنه الفرق بين باب أمامي غير مقفل يستطيع أي أحد المرور منه، وباب لا يحمل مفتاحه إلا من اخترتهم. ولا يكلّف شيئاً لإضافته.

ما قد يكلّفك هذا

الخطر الذي يُغلقه سجل CAA هو الانتحال المقنع. فحين يستطيع محتال الحصول على شهادة حقيقية لنسخة من موقعك، تختفي علامات التحذير المعتادة — لا قفل مكسور، لا شريط “غير آمن”، لا خطأ شهادة. كل شيء يبدو صحيحاً، وهو بالضبط ما يجعله خطيراً.

المزيّف الذي لا عيب فيه. يسجّل محتال عنواناً مشابهاً (أو يخترق مساراً إلى عملائك)، ويحصل على شهادة حقيقية، ويقيم نسخة مطابقة لصفحة تسجيل الدخول أو الدفع لديك — بالقفل وكل شيء. يُدخِل العملاء كلمات مرورهم وأرقام بطاقاتهم كالمعتاد. وأول ما تسمعه موجة من عمليات ردّ المبالغ، وبلاغات الاحتيال، والمكالمات الغاضبة.
حملة التصيّد باسمك. يرسل المهاجمون رسائل “يرجى تأكيد حسابك” تربط بنسختهم المُشهَّدة من موقعك. ولأن الصفحة تبدو آمنة تماماً، يقع المزيد من الناس. والتنظيف — إخطار العملاء، والمبالغ المعادة، وساعات الدعم، والشرح العام المحرج — يقع كله عليك، رغم أن خوادمك الحقيقية لم تُمَسّ أبداً.
الصفقة التي تتعثّر على قائمة تحقق. يمسح فريق الأمن أو المشتريات لدى عميل أكبر نطاقك قبل التوقيع. ويظهر “لا سجل CAA” كبند أحمر أو كهرماني بجانب اسمك. إنه أمر صغير تقنياً، لكنه يُقرأ على أنه “لا يغطّي الأساسيات”، وقد يُبطئ أو يُغرق عقداً كنت ستفوز به لولا ذلك.
مأخوذ على حين غرّة باختراق غيرك. تُخترَق جهة شهادات لم تتعامل معها يوماً — وهذا ليس افتراضياً؛ فقد تعرّضت DigiNotar وComodo وSymantec جميعها لحوادث خطيرة. ولأنك لم تقيّد أبداً من يُسمَح له بالتصرّف نيابة عنك، يستطيع المهاجم الحصول على شهادة صالحة لنطاقك عبر تلك الجهة الضعيفة. وكان سجل CAA سيرفضهم.
النقطة العمياء للشهادات العامة الاستخدام. حتى الأنشطة التجارية الحذرة بشأن موقعها الرئيسي تنسى غالباً النطاقات الفرعية. فبدون قاعدة issuewild، يحصل مهاجم قادر على الحصول على شهادة عامة الاستخدام فعلياً على مفتاح لـ كل نطاق فرعي ستملكه يوماً دفعة واحدة.

لا شيء من هذا يتطلب هجوماً متطوّراً على خوادمك. إنها تستغلّ حقيقة أنه، دون سجل CAA، يكون نظام الشهادات الأوسع ببساطة مفرطاً في الثقة نيابة عنك.

ما هو فعلاً، وكيف يبدو “الجيد”

يعيش سجل CAA في DNS الخاص بنطاقك — الإعدادات نفسها التي توجّه نطاقك إلى موقعك وبريدك. ولكل سجل ثلاثة أجزاء: علم (flag)، ووسم (tag)، وقيمة (value). والوسوم التي تهمّ هي:

issue — يُسمّي جهة شهادات مسموح لها بإصدار شهادات عادية لنطاقك. ويمكن أن يكون لديك عدة، واحد لكل مزوّد تستخدمه مشروعاً.
issuewild — يتحكم في الشهادات العامة الاستخدام (شهادة واحدة تغطّي كل نطاق فرعي، مثل *.example.com). وإن لم تستخدم العامة الاستخدام، فالإعداد الموصى به يحجبها كلياً.
iodef — عنوان اتصال اختياري ستُخطَر عليه إن رفضت جهة شهادات طلباً بسبب سياسة CAA لديك. هذا تحذيرك المبكر بأن أحدهم حاول.

كيف يبدو “الجيد”: سجل issue (أو issuewild) واحد على الأقل موجود، يُسمّي المزوّد (المزوّدين) الذي تستخدمه فعلاً، مع تقييد الشهادات العامة الاستخدام إلى مزوّد مُسمّى أو حجبها. ذلك هو الحدّ الذي يقيسه هذا الفحص — فهو يبحث عن سجلات CAA لنطاقك عبر عدة مُحلِّلات مستقلة ويجتاز حين يجد سياسة issue أو issuewild حقيقية في مكانها. والنطاق الذي لا سجلات CAA له إطلاقاً يُعامَل كالباب المفتوح الذي هو عليه.

هل يؤثر هذا في درجتي؟ نعم. سجل CAA المفقود بند مُقيَّم ويُعلَّم بخطورة متوسطة — إنه ثغرة حقيقية، لا مجرد أمر مستحبّ، لأنه يترك مسار انتحال حقيقياً مفتوحاً. وإضافة السجل تُغلق الثغرة وتمحو النتيجة.

كيفية الإصلاح (مجاناً، ~5 دقائق)

سلّم هذا القسم لمن يدير نطاقك أو موقعك — الإصلاح مجاني. إنه تغيير DNS صغير، لا إعادة بناء. نحن نتقاضى رسوماً فقط إن أردت لاحقاً أن نواصل مراقبة بقاء السجل في مكانه؛ وإضافته لا تكلّف شيئاً.

الخطوة 1 — اعرف أي جهة شهادات تستخدمها فعلاً. هذه الخطوة الوحيدة التي يستحق ضبطها بدقة، لأن إدراج المزوّد الخطأ قد يحجب تجديدك التالي. الحالات الشائعة:

Let’s Encrypt — يستخدمه كثير من المضيفين ولوحات التحكم (cPanel، Plesk) ← letsencrypt.org
Cloudflare (إن أصدرت شهادتك الطرفية) ← letsencrypt.org، digicert.com، comodoca.com، pki.goog، وssl.com (تستخدم Cloudflare عدة جهات شهادات خلفية؛ أدرِج التي تعرضها لوحتها، أو مجموعتها الكاملة، فلا تنكسر التجديدات أبداً)
Google Workspace / Google Trust Services ← pki.goog
DigiCert ← digicert.com
Sectigo / Comodo ← sectigo.com (وcomodoca.com)
Microsoft 365 / Azure — تستخدم Microsoft عادة DigiCert للشهادات المُدارة ← digicert.com (تأكد في بوابتك)

إن لم تكن متأكداً، فانظر في شهادتك الحالية في المتصفح (انقر القفل ← تفاصيل الشهادة ← “Issued by”) لمعرفة من أصدرها.

الخطوة 2 — سجّل الدخول إلى مزوّد DNS الخاص بك. هذا حيثما توجد سجلات نطاقك — عادة مُسجِّلك، أو مضيف الويب الخاص بك، أو Cloudflare. اعثر على قسم سجلات DNS واختر إضافة سجل جديد من نوع CAA (تسمّيه بعض الواجهات نوع 257).

الخطوة 3 — أضِف سجل issue لكل مزوّد تستخدمه. لـ Let’s Encrypt مثلاً:

example.com.   CAA   0 issue "letsencrypt.org"

أضِف سطر issue واحداً لكل مزوّد مشروع. وتمنحك معظم لوحات DNS خانات منفصلة للعلم (0)، والوسم (issue)، والقيمة (نطاق جهة الشهادات) فلا تكتب السطر كله يدوياً.

الخطوة 4 — تحكّم في الشهادات العامة الاستخدام. إن كنت لا تستخدم العامة الاستخدام، فاحجبها صراحةً فلا يستطيع أحد الحصول على واحدة بهدوء:

example.com.   CAA   0 issuewild ";"

وإن كنت تستخدم العامة الاستخدام، فسمِّ المزوّد بدلاً من ذلك: 0 issuewild "letsencrypt.org".

الخطوة 5 — (موصى به) أضِف عنوان إخطار. لتُخبَر كلما رفضت جهة شهادات محاولة — تحذيرك المبكر بأن أحدهم حاول:

example.com.   CAA   0 iodef "mailto:[email protected]"

الخطوة 6 — احفظ وتحقّق. شغّل dig CAA example.com (أو استخدم أي أداة بحث DNS عبر الإنترنت) وتأكد من ظهور سجلاتك. وقد تستغرق التغييرات من بضع دقائق إلى بضع ساعات لتنتشر عبر الإنترنت. وتظلّ شهادتك الحالية وكل التجديدات تعمل طوال ذلك — فـ CAA يحكم الإصدار الجديد فقط.

ملاحظات منصة سريعة: على Cloudflare، DNS ← Records ← Add record ← النوع CAA. على Google Workspace، تدير DNS لدى مُسجِّلك (أو Cloud DNS إن استخدمته) — أضِف سجلات CAA هناك بـ pki.goog. على Microsoft 365، لا يُضبَط CAA في مركز إدارة M365؛ أضِفه حيثما يُستضاف DNS الخاص بنطاقك، مُدرِجاً جهة شهاداتك المُدارة (عادة DigiCert). على المضيفين الشائعين (GoDaddy، Namecheap، Blacknight، إلخ)، إنه في لوحة DNS نفسها حيث توجد سجلات A وMX.

الأخطاء الشائعة

إدراج جهة الشهادات الخطأ — أو نسيان واحدة. أكبر خطر واقعي ليس الأمن، بل حجب تجديداتك أنت. فإذا كنت تستخدم أكثر من مُصدِر (مثلاً واحد للموقع الرئيسي وآخر خلف Cloudflare)، فأدرِجها جميعاً. وعند الشكّ، أدرِج بضعة تثق بها بدلاً من قليل جداً.
ضبط issue وتجاهل العامة الاستخدام. النطاق الذي يقيّد الشهادات العادية لكنه لا يقول شيئاً عن العامة الاستخدام لا يزال يترك المسار العام الاستخدام الأقوى مفتوحاً. اضبط issuewild دائماً أيضاً — إمّا إلى مزوّدك أو إلى ";" لحجبه.
وضع CAA على الاسم الخطأ. يُقرأ CAA من قِبل جهة الشهادات للاسم بالضبط الذي يُشهَّد، صاعداً في الشجرة. وضبطه عند قمة نطاقك (الـ “apex”، مثل example.com) هو الخطوة الصحيحة — فهو يغطّي النطاقات الفرعية افتراضياً ما لم يضبط نطاق فرعي سجله الخاص.
افتراض أن منصتك فعلتها أصلاً. Cloudflare وGoogle وMicrosoft تدير الشهادات لكنها لا تضيف سجلات CAA لك. وما لم تضفها، فنطاقك لا يزال مفتوحاً.
معاملته كأمر يُفعَل مرة واحدة دون مراقبة. قد يُسقِط ترحيل DNS لاحق، أو تغيير مُسجِّل، أو “ترتيب” للسجلات حماية CAA لديك بصمت. ويستحق التأكد من بقائها بعد أي تغيير DNS.

الطبقة التقنية (سلّم هذا للشخص التقني لديك)

CAA معرَّف في RFC 8659 ومفروض بموجب المتطلبات الأساسية لمنتدى CA/Browser — فكل جهة شهادات موثوقة علناً مُلزَمة بفحص CAA وقت الإصدار. وتأخذ السجلات شكل <flags> <tag> <value>، بالوسوم issue وissuewild وiodef. وسياسة issue أو issuewild غير الفارغة هي ما يُرضي هذا الفحص؛ ووجود iodef وحده لا يفعل (فهو إبلاغ، لا تخويل).

خطّ أساس متين عند الـ apex:

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

ملاحظات للمنفّذ:

تسلّق شجرة CAA: تقيّم جهات الشهادات CAA من الاسم المؤهَّل بالكامل المطلوب صعوداً إلى الـ apex، متوقّفةً عند أول اسم يحمل سجل CAA مضبوطاً. فالسجل عند الـ apex يحمي بالتالي كل النطاقات الفرعية ما لم ينشر نطاق فرعي سجله الخاص، وهو ما يمكنه — مفيد إن استخدم نطاق فرعي محدّد مُصدِراً مختلفاً.
القيمة ; في issuewild تعني “لا يجوز لأي جهة شهادات إصدار شهادات عامة الاستخدام” — رفض صريح. استخدمها كلما لم تكن العامة الاستخدام جزءاً من إعدادك.
العلم 0 هو علم حرج-المُصدِر؛ و0 (غير حرج) صحيح للاستخدام العادي. تجنّب ضبط البتّ الحرج ما لم تفهمه تماماً، إذ قد يتسبّب وسم حرج مُساء فهمه في رفض جهات الشهادات المتوافقة للإصدار.
مُصدِرون متعدّدون: يُسمَح بعدة سجلات issue وهي تراكمية — أدرِج كل جهة شهادات مشروعة في حزمتك (بما في ذلك جهات الشهادات الخلفية التي يستخدمها مزوّد CDN/الحافة لديك) لمنع إخفاقات التجديد.
التحقق: dig CAA example.com +short، أو تحقّق عبر أدوات اختبار CAA لمنتدى CA/Browser. ويستعلم هذا الفحص نفسه عن CAA عبر عدة مُحلِّلات مستقلة (DNS المحلي، ثم Google وCloudflare وQuad9 DNS-over-HTTPS كاحتياط) ويقبل أول جواب موثوق، فلا يُنتج انقطاع مُحلِّل واحد نتيجة “لا CAA” زائفة.
اقتران DNSSEC: يُخبر CAA جهات الشهادات من يجوز له الإصدار؛ وDNSSEC يمنع تزوير جواب CAA نفسه أثناء النقل. إنهما متكاملان — وللنطاقات عالية القيمة، شغّل كليهما.

أعدّه على مُضيفك

خطوة بخطوة لدى المزوّدين الشائعين:

الأسئلة الشائعة

لستُ شخصاً تقنياً — هل يمكنني التعامل مع هذا بنفسي؟

لستَ بحاجة لفهم التفصيل، لكن الإصلاح تغيير صغير داخل إعدادات DNS لنطاقك، فمن الأفضل تسليمه لمن يدير موقعك أو نطاقك. أرسِل لهم قسم 'كيفية الإصلاح' أدناه — إنه تغيير من خمس دقائق دون تكلفة. نحن نتقاضى رسوماً فقط إن أردت لاحقاً أن نواصل مراقبة بقاء السجل في مكانه؛ والإصلاح نفسه مجاني دائماً.

هل سيُعطّل إضافة هذا موقعي أو شهادتي؟

لا — طالما أنك تُدرِج مزوّد الشهادات الذي تستخدمه فعلاً، يظلّ كل شيء يعمل تماماً كما قبل. سجل CAA لا يمسّ أو يستبدل شهادتك الحالية؛ بل يحكم فقط من يُسمَح له بإنشاء شهادات جديدة. والطريقة الوحيدة لإحداث متاعب هي ترك مزوّدك الحقيقي خارج القائمة، ما قد يحجب تجديدك التلقائي التالي — والخطوات أدناه مكتوبة تحديداً لتجنّب ذلك.

إن كانت الشهادات تُصدَر تلقائياً هذه الأيام، فلماذا ما زلت أحتاج هذا؟

الشهادات التلقائية جيدة ومريحة — المشكلة أن النظام مفتوح للجميع افتراضياً، بما في ذلك من يتظاهر بأنه أنت. وسجل CAA ببساطة يُسمّي من يُسمَح له، مُحوِّلاً باباً مفتوحاً إلى باب بقفلك الخاص. وهو يعمل إلى جانب الإصدار التلقائي، لا ضدّه.

هل يؤثر هذا في ترتيب Google أو درجتي في هذا التقرير؟

يؤثر في درجتك الأمنية هنا — فسجل CAA المفقود بند مُقيَّم، يُعلَّم كثغرة متوسطة الخطورة، لأنه يترك مسار انتحال حقيقياً مفتوحاً. وهو ليس عامل ترتيب مباشر لدى Google، لكن الانتحال والتصيّد اللذين يمنعهما هما بالضبط نوع الحوادث التي تضرّ الثقة والحركة. وعلى أي حال إنه فوز سريع مجاني.

ما الفرق بين 'issue' و'issuewild'؟

سجل 'issue' يتحكم في الشهادات العادية لنطاقك ونطاقاته الفرعية. وسجل 'issuewild' يتحكم في الشهادات العامة الاستخدام (wildcard) — الشهادة الواحدة التي تغطّي كل نطاق فرعي ممكن دفعة واحدة (مثل *.example.com). والشهادات العامة الاستخدام أقوى وبالتالي أخطر في الأيدي الخطأ، فمن الممارسة الجيدة التحكم بها بشكل منفصل: إن لم تستخدمها، فاحجبها صراحةً.

نحن نستخدم Cloudflare / Google Workspace / Microsoft 365 — هل يغطّي ذلك هذا أصلاً؟

ليس تلقائياً. تدير تلك المنصات شهاداتك لك، لكن ما لم تكن قد أضفت سجلات CAA صراحةً، فإن نطاقك لا يزال يخبر العالم 'يجوز لأي جهة الإصدار'. والبشرى أن الإصلاح هو تغيير DNS البسيط نفسه على جميعها، وحيثما تُصدِر Cloudflare أو مضيفك شهادتك، تُدرِج ببساطة ذلك المزوّد. وملاحظات المنصة في قسم الإصلاح أدناه تغطّي الحالات الشائعة.