معظم أعطال DNS لا علاقة لها بخادم معطّل، بل بسجل واحد مكتوب خطأ: سجل ثانٍ أضافه مزود بريد جديد فأسقط التحقق من كل الرسائل، أو CNAME في جذر النطاق رفضته اللوحة، أو نقطة ناقصة في آخر اسم حوّلت خادم البريد إلى اسم لا وجود له. هذا مرجع عملي لسجلات : ما يفعله كل سجل، وكيف تكتبه، وأي TTL يناسبه، والخطأ الذي يتكرر معه، وكيف تتحقق منه بـ dig. نطبّق الأمثلة على DNS Console، منصة إليفانتي لإدارة النطاقات ومناطق DNS، والقواعد نفسها تصلح لأي مزود.
01السجل في أربعة حقول
كل سجل في المنطقة أربعة حقول: الاسم، والنوع، وTTL، والقيمة. الاسم إما نفسه، ويُكتب في ملفات المنطقة بالرمز @، وإما اسم فرعي مثل www أو shop. وفي DNS Console تفتح منطقة النطاق فتعدّل سجلاتها في جدول واحد، ولكل نوع حقوله، ويُطبَّق كل حفظ في لحظته على خوادم أسماء إليفانتي.
وانتبه إلى الفرق بين الاسم النسبي و. في صيغة ملف المنطقة، الاسم الذي ينتهي بنقطة يُقرأ كما هو، والاسم الذي لا ينتهي بها يُلحق به اسم النطاق تلقائياً. فإن كتبت قيمة MX على شكل mail.qahwat-rainbow.com دون نقطة، صارت mail.qahwat-rainbow.com.qahwat-rainbow.com. ولوحات الإدارة تختلف في معاملة هذه النقطة، فلا تفترض، وتحقق من القيمة النهائية بعد كل حفظ.
تدعم DNS Console ثلاثة عشر نوعاً من السجلات: A وAAAA وCNAME وALIAS وDNAME وMX وTXT وSRV وNS وPTR وCAA وDS وTLSA. نمرّ هنا على الأنواع التي يحتاجها كل نطاق تقريباً.
02العناوين: A وAAAA وCNAME
سجل A يربط اسماً بعنوان IPv4، وAAAA يربطه بعنوان IPv6. يجوز أن يحمل الاسم الواحد أكثر من سجل A، فتتوزع الطلبات بين العناوين، لكن هذا ليس موازنة حمل حقيقية: DNS لا يعرف أن أحد الخادمين معطّل، ويستمر في إعطاء عنوانه.
أما CNAME فيجعل الاسم مستعاراً لاسم آخر، كأن تشير www إلى الجذر، أو shop إلى منصة متجر خارجية. وله قاعدة صارمة: الاسم الذي يحمل CNAME لا يحمل أي سجل آخر. لذلك لا يجوز CNAME في جذر النطاق، لأن الجذر يحمل دائماً سجلي SOA وNS، وعادةً MX وTXT. فإن طلبت منك منصة خارجية أن توجّه الجذر إلى اسم لديها، فاستخدم سجل ALIAS في DNS Console: يعمل مثل CNAME، لكنه يجيب بعناوين الهدف، فيعيش في الجذر إلى جانب باقي السجلات.
وقاعدة ثانية يكسرها كثيرون: لا تجعل MX ولا NS يشيران إلى اسم يحمل CNAME، ولا إلى عنوان IP. هدفهما اسم له سجل A أو AAAA مباشرة.
03البريد والتحقق: MX وTXT
سجل MX يحدد خوادم البريد التي تستقبل رسائل نطاقك، ولكل منها رقم أولوية: الرقم الأصغر يُجرَّب أولاً، والرقمان المتساويان يتقاسمان الرسائل. فإن كان لديك 10 لخادم رئيسي و20 لخادم احتياطي، فلن تذهب الرسائل إلى الاحتياطي إلا حين يتعذر الوصول إلى الأول.
وسجل TXT نص حر، تستخدمه ثلاثة معايير لأمان البريد، وتستخدمه منصات كثيرة لإثبات ملكيتك للنطاق:
- SPF: في الجذر، يبدأ بـ v=spf1 ويعدد الخوادم المسموح لها بالإرسال باسم نطاقك. للنطاق سجل SPF واحد فقط، ولا يجوز أن تتجاوز آلياته التي تستدعي استعلامات، مثل include وa وmx، عشرة استعلامات.
- DKIM: في اسم مثل sel1._domainkey، يحمل المفتاح العام الذي تتحقق به الخوادم المستقبِلة من توقيع رسائلك. مفتاح RSA بطول 2048 بت يتجاوز 255 حرفاً، فيُقسم إلى عدة سلاسل نصية داخل السجل نفسه، لا إلى سجلين.
- DMARC: في الاسم _dmarc، يحدد ما يفعله المستقبِل برسالة فشلت في التحقق، وأين يرسل التقارير. ابدأ بسياسة p=none مع عنوان للتقارير، ثم انتقل إلى quarantine فـ reject حين تتأكد أن كل مصادر بريدك موقّعة.
- إثبات الملكية: رموز تطلبها منصات مثل Google وMicrosoft، وأحياناً جهات إصدار الشهادات. أضف كل رمز سجلاً مستقلاً، ولا تدمجه في سجل SPF.
ومنذ مطلع 2024 يشترط Gmail وYahoo على كل مرسل أن يجتاز SPF أو DKIM، وعلى من يرسل نحو 5,000 رسالة يومياً أو أكثر أن يملك SPF وDKIM معاً، وسجل DMARC ولو بسياسة p=none. وفي DNS Console قوالب جاهزة تكتب سجلات مزوّد بريدك عنك، فتقل أخطاء الإدخال. أما إعداد البريد وسمعته بالتفصيل، فنشرحهما في مقالات مستقلة على المدونة.
04الخدمات والشهادات والتفويض: SRV وCAA وNS
سجل SRV يدل التطبيقات على الخادم والمنفذ اللذين تعمل عليهما خدمة ما. اسمه يجمع الخدمة والبروتوكول، مثل _submission._tcp لإرسال البريد، وقيمته أربعة أجزاء: الأولوية، والوزن، والمنفذ، والهدف. بهذا يجد برنامج البريد إعداداته وحده حين يكتب المستخدم عنوانه، وتعتمد عليه خدمات الاتصال الصوتي وبعض الألعاب.
وسجل يحدد جهات الإصدار المسموح لها بإصدار شهادات SSL لنطاقك. تفحصه كل جهة إلزامياً قبل الإصدار، فإن لم تجد اسمها رفضت الطلب. أضف سطر issue لكل جهة تستخدمها فعلاً، بما فيها الجهة التي تصدر منها لوحة الاستضافة شهاداتها التلقائية، وسطر iodef ليصلك تنبيه عند كل محاولة مرفوضة. ونفصّل الشهادات وسلسلتها في مقال مستقل على المدونة.
وسجلات NS في الجذر تعلن خوادم الأسماء المسؤولة عن نطاقك، ويجب أن تطابق ما سجّلته لدى جهة التسجيل. وإن أضفت سجلات NS لاسم فرعي مثل lab، فوّضت إدارة ذلك الاسم وما تحته إلى خوادم أخرى، كخوادم فريق التطوير. وإن كان نطاقك مسجلاً لدى جهة أخرى، فإدارته من DNS Console تبدأ بإضافة سجلاته كلها إلى المنصة، ثم وضع خادمي أسماء إليفانتي لدى جهة التسجيل.
أما PTR فيعيش في المنطقة العكسية لعنوان IP، لا في منطقة نطاقك، وتطلبه خوادم البريد لتطابق عنوان المرسل مع اسمه. وفي DNS Console تدير المناطق العكسية وسجلات PTR لعناوين IPv4 وIPv6، شرط أن يفوّض إليك مالك كتلة العناوين منطقتها العكسية؛ وإلا فاطلب السجل من مزود الخادم.
منطقة كاملة لمتجر صغير
هكذا تبدو منطقة متجر قهوة صغير في عمّان بصيغة ملف المنطقة. سجلا SOA وNS للجذر يكتبهما مزود خوادم الأسماء، فلم نكررهما:
# الأسماء التي تنتهي بنقطة كاملة، وغيرها يُلحق به اسم النطاق$ORIGIN qahwat-rainbow.com.@ 3600 IN A 203.0.113.20@ 3600 IN AAAA 2001:db8:20::20www 3600 IN CNAME qahwat-rainbow.com.shop 300 IN A 198.51.100.45@ 3600 IN MX 10 mx1.mailhost.example.@ 3600 IN MX 20 mx2.mailhost.example.@ 3600 IN TXT "v=spf1 include:_spf.mailhost.example ~all"# المفتاح مختصر هنا، والكامل يعطيك إياه مزود البريدsel1._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."_dmarc 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"_submission._tcp 3600 IN SRV 0 1 587 smtp.mailhost.example.@ 86400 IN CAA 0 issue "sectigo.com"@ 86400 IN CAA 0 iodef "mailto:[email protected]"lab 86400 IN NS ns1.devhost.example.
05استراتيجية TTL لكل سجل
TTL يحدد كم تحتفظ المحلّلات بالجواب قبل أن تسأل من جديد، أي كم ينتظر زوارك أي تغيير. لا توجد قيمة واحدة صحيحة: اختر القيمة بحسب احتمال التغيير وكلفة الانتظار.
| السجل أو الحالة | TTL المقترح | السبب |
|---|---|---|
| NS وتفويض الأسماء الفرعية | 86400 | نادراً ما تتغير، والقيمة العالية تقلل الاستعلامات وأثر أي عطل مؤقت |
| A وAAAA وCNAME لموقع مستقر | 3600 | توازن بين سرعة التغيير وعدد الاستعلامات |
| A أثناء نقل خادم أو تبديله | 300 | يتبع الزوار العنوان الجديد خلال دقائق |
| MX | 3600 إلى 14400 | خوادم البريد نادراً ما تتغير، والخادم المرسِل يعيد المحاولة عند الفشل |
| TXT للبريد وإثبات الملكية | 3600 | تعديلات متكررة أثناء الإعداد، ثم تستقر |
| CAA | 3600 إلى 86400 | تقرؤه جهات الإصدار عند الإصدار فقط |
وقبل أي تغيير مخطط، اخفض TTL السجل المعني إلى 300 بمدة لا تقل عن قيمته القديمة، ثم أعده بعد الاستقرار. أما لماذا يحكم TTL القديم مدة الانتظار، ومعه التخزين السلبي وتغيير خوادم الأسماء، فنشرحه في مقال مستقل على المدونة عن انتشار DNS. وبعد كل حفظ في DNS Console، تريك مراقبة الانتشار المحلّلات التي وصلها الجواب الجديد وتلك التي تنتظر انتهاء TTL.
06أخطاء شائعة وكيف تكشفها
- المشكلةبريدك يُرفض أو يذهب إلى البريد المزعج بعد إضافة مزود جديد، وفي الجذر سجلا SPF
- الحلوجود سجلين يجعل نتيجة SPF خطأً دائماً (permerror). ادمجهما في سجل واحد يجمع آليات include للمزودين، وتأكد أن الاستعلامات لا تتجاوز عشرة.
- المشكلةاللوحة ترفض إضافة TXT أو MX إلى اسم، أو يتعطل الاسم بعد الإضافة
- الحلالاسم يحمل CNAME، وCNAME لا يقبل سجلاً آخر بجانبه. انقل السجل الآخر إلى اسم مختلف، أو استبدل CNAME بسجل A، أو بسجل ALIAS في الجذر.
- المشكلةقيمة MX أو CNAME تظهر في dig مضاعفة، مثل mail.qahwat-rainbow.com.qahwat-rainbow.com
- الحلاسم كامل كُتب دون النقطة الأخيرة. اكتبه بالنقطة، أو اكتب الجزء النسبي وحده، بحسب ما تتوقعه اللوحة.
- المشكلةبعض الخوادم المرسِلة لا تسلّم الرسائل، وMX يشير إلى عنوان IP أو إلى اسم عليه CNAME
- الحلاجعل MX يشير إلى اسم خادم له سجل A أو AAAA مباشرة.
- المشكلةتقارير DMARC لا تصل، وأدوات الفحص تقول إن النطاق بلا سياسة
- الحلالسجل في الجذر بدل الاسم _dmarc. انقله إلى _dmarc.
- المشكلةفشل إصدار شهادة أو تجديدها الآلي بعد إضافة CAA
- الحلالجهة التي تصدر شهاداتك غير مذكورة في السجل. أضف سطر issue لها، ثم أعد المحاولة.
وقبل أن تعلن أن كل شيء يعمل، اسأل خوادم أسماء نطاقك مباشرة، دون أي ذاكرة مؤقتة بينك وبينها:
# أول خادم أسماء مسؤول عن نطاقكNS=$(dig +short NS qahwat-rainbow.com | head -n1)dig @$NS qahwat-rainbow.com MX +noall +answer# عدد سجلات SPF: يجب أن يكون الناتج 1dig @$NS qahwat-rainbow.com TXT +short | grep -c "v=spf1"dig @$NS _dmarc.qahwat-rainbow.com TXT +shortdig @$NS sel1._domainkey.qahwat-rainbow.com TXT +shortdig @$NS qahwat-rainbow.com CAA +shortdig @$NS _submission._tcp.qahwat-rainbow.com SRV +short# هدف MX يجب أن يعيد عنواناً مباشرة، لا CNAMEdig mx1.mailhost.example A +noall +answer
ثم افحص الصورة من خارج شبكتك بأداة فحص انتشار DNS في إليفانتي، التي تسأل نقاطاً حول العالم، من دبي والرياض والقاهرة إلى فرانكفورت وطوكيو، وتقارن كل جواب بخوادم الأسماء الرسمية لنطاقك.
07قبل أن تضغط «حفظ»
انسخ المنطقة الحالية قبل أي تعديل كبير، فهي نسختك الوحيدة للرجوع. غيّر شيئاً واحداً في كل مرة، وتحقق منه بـ dig قبل التالي. أبقِ سجل SPF واحداً، ولا تضع CNAME في الجذر، واكتب الأسماء الكاملة بنقطتها حيث تلزم. واجعل TTL ساعة لمعظم السجلات ويوماً لـ NS وCAA، واخفضه قبل أي نقل مخطط.
وإن جمعت نطاقاتك في DNS Console، فالقوالب الجاهزة تكتب سجلات البريد عنك، وتستطيع أن تصنع قالبك وتطبقه على نطاقات كثيرة دفعة واحدة، فلا تتكرر أخطاء الإدخال اليدوي. والمنصة باشتراك سنوي يشمل أنواع السجلات الثلاثة عشر وسجلات PTR ومراقبة الانتشار.
