شرح سجلات CAA في DNS: تحكّم في جهات الإصدار المسموح لها بإصدار شهادات نطاقك

افتراضياً، يحق لأي جهة إصدار شهادات موثوقة علناً أن تصدر شهادة TLS لنطاقك بعد التحقق من أنك تتحكم فيه. وسجل CAA (Certification Authority Authorization) في DNS يحصر هذه القائمة في الجهات التي تستخدمها فعلاً، فلا يؤدي خطأ في التحقق لدى جهة أخرى إلى إصدار شهادة صالحة باسم نطاقك.

يُعرّف CAA في المعيار RFC 8659، مع قيود اختيارية على الحساب وطريقة التحقق في RFC 8657. وتُلزم المتطلبات الأساسية لمنتدى CA/Browser كل جهة إصدار عامة بفحص CAA قبل الإصدار.

كيف تقرأ جهة الإصدار سجل CAA

• غياب أي سجل CAA فوق الاسم يعني عدم وجود قيود: يحق لأي جهة الإصدار.
• الصعود في شجرة الأسماء. بالنسبة للاسم www.shop.example.com تبحث الجهة عن CAA عند هذا الاسم، ثم shop.example.com، ثم example.com، وتتوقف عند أول اسم يحمل سجلات CAA. لذا فالسجل على نطاقك المسجّل يغطي كل النطاقات الفرعية ما لم يكن لأحدها سجل خاص.
• تتبّع سجلات CNAME. إذا كان النطاق الفرعي اسماً بديلاً لاسم مضيف لدى مزود خدمة، فإن سجلات CAA عند الوجهة هي التي تنطبق.
• السجلات تراكمية. إذا ذكر أي سجل issue اسم الجهة، يحق لها الإصدار.
• التوقيت. يجب أن تصدر الجهة الشهادة خلال مدة TTL لسجل CAA أو خلال 8 ساعات من فحصه، أيهما أطول، لذا يسري أي تغيير خلال هذه النافذة تقريباً.

الوسوم الثلاثة التي تحتاجها

لكل سجل علامة (flag) تكون 0 في أغلب الحالات. أما العلامة 128 فتجعل السجل حرجاً، أي أن الجهة التي لا تفهم الوسم يجب أن ترفض الإصدار. والقيمة ";" في issue (دون اسم جهة) تمنع الإصدار، وكذلك تُعامَل القيمة غير الصحيحة الصياغة.

قبل أن تنشر أي سجل

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

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer

اسم جهة الإصدار في الشهادة ليس هو القيمة التي تضعها في CAA؛ فكل جهة توثّق معرّف CAA الخاص بها في وثائق سياساتها، ومعرّف Let's Encrypt هو letsencrypt.org بحسب وثائق CAA لديها.

أمثلة

السماح لـLet's Encrypt فقط، ومنع الشهادات الشاملة، وطلب الإبلاغ عن الطلبات المرفوضة:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

السماح لجهتين (السجلات تراكمية)، مع استبدال ca2.example بالمعرّف الموثق للجهة الثانية:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "ca2.example"

منح نطاق فرعي مستضاف في مكان آخر سياسة خاصة به تتقدم على سياسة النطاق الأصل:

api.example.com.  3600  IN  CAA  0 issue "ca2.example"

التقييد بحساب أو بطريقة تحقق

يضيف RFC 8657 معاملين بعد اسم الجهة. المعامل validationmethods يحدد طرق التحقق من التحكم بالنطاق، وتتعرف Let's Encrypt على http-01 وdns-01 وtls-alpn-01. أما accounturi فيحصر الإصدار في حساب ACME واحد، فلا يستطيع من يسيطر مؤقتاً على خادم الويب أو DNS استخدام حسابه الخاص:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"

تنص المتطلبات الأساسية حالياً على أنه ينبغي للجهات معالجة هذين المعاملين، ويصبح ذلك إلزامياً من 15 مارس 2027. استخدمهما فقط بعد استقرار معرّف حسابك وطريقة التحقق، لأن إعادة إنشاء حساب ACME أو الانتقال من التحقق عبر HTTP إلى DNS سيوقف التجديد حتى تحدّث السجل.

فحص السجلات

dig example.com CAA +short
dig www.example.com CAA +short

الإجابة الفارغة لـwww طبيعية، إذ ستصعد الجهة إلى example.com. ولمعرفة ما ينشره مزود DNS دون أي ذاكرة مؤقتة، اسأل أحد خوادم الأسماء الموثوقة مباشرة:

dig @ns1.your-dns-host.example example.com CAA +norecurse

أخطاء توقف الإصدار

• خوادم DNS تسيء التعامل مع استعلامات CAA. يجب أن يرد خادم الأسماء على نوع الاستعلام غير المعروف أو الفارغ بالرمز NOERROR، أما إذا رد بـNOTIMP أو SERVFAIL فلن تستطيع الجهة معرفة ما إذا كان CAA يسمح لها، وسترفض.
• خلل في DNSSEC. منذ 15 مارس 2026 يجب على الجهات التحقق من DNSSEC في استعلامات CAA، ولا يجوز لها اعتبار خطأ التحقق مثل SERVFAIL إذناً بالإصدار. وتشير Let's Encrypt إلى أن بعض أنظمة التوقيع أنتجت تواقيع خاطئة للإجابات الفارغة تحديداً، وهي ما تعيده معظم استعلامات CAA.
• طرف ثالث منسي. منصة تسويق أو أداة دعم فني تصدر شهادة لنطاق فرعي وجّهته إليها ستفشل عند التجديد ما لم تُدرج جهتها، أو يكن النطاق الفرعي اسماً بديلاً CNAME فتنطبق سجلات CAA لدى المزود.
• الأخطاء الإملائية والعلامة الحرجة. القيمة غير الصحيحة تمنع الإصدار، والعلامة 128 على وسم لا تعرفه الجهة توقفها.

ما الذي ينبغي فعله

• اجرد كل جهة تصدر شهادات لنطاقك ونطاقاته الفرعية قبل إضافة CAA.
• ابدأ بسجل issue بسيط لكل جهة على النطاق المسجّل، مع issuewild ";" إن كنت لا تستخدم الشهادات الشاملة.
• أضف جهة اتصال iodef تقرأ رسائلها فعلاً.
• تحقق بالأمر dig ... CAA مقابل خادم الأسماء الموثوق، ثم اختبر تجديداً.
• فكّر في accounturi وvalidationmethods بعد استقرار إعداد ACME لديك.
• إن كنت توقّع المنطقة بـDNSSEC فراقبها، فأي فشل في التحقق يوقف إصدار الشهادات الآن.

المصادر

• rfc-editor.org/rfc/rfc8659.html
• rfc-editor.org/rfc/rfc8657.html
• letsencrypt.org/docs/caa
• cabforum.org/working-groups/server/baseline-requirements/documents
• github.com/cabforum/servercert/blob/main/docs/BR.md
• manpages.debian.org/trixie/bind9-dnsutils/dig.1.en.html