مقدمة

لفهم كيف يحدد DNS نوع سجل الاستعلام المناسب: شرح سجلات A وAAAA وCNAME وMX وTXT، يجب أولاً تصحيح فكرة شائعة: نظام أسماء النطاقات لا يخمّن تلقائياً نوع المعلومة المطلوبة من اسم النطاق وحده. بدلاً من ذلك، يرسل العميل، مثل المتصفح أو خادم البريد أو أداة التحقق، استعلام DNS يتضمن اسماً ونوع سجل محدداً. فإذا احتاج المتصفح عنوان خادم لموقع ويب، فإنه يطلب عادة سجلات A وAAAA؛ وإذا أراد خادم بريد معرفة وجهة الرسائل لنطاق معين، فإنه يطلب سجل MX؛ أما خدمات التحقق من الملكية والبريد الموثق، فتعتمد غالباً على سجلات TXT.

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

بنية استعلام DNS: من يختار النوع ولماذا؟

يتألف استعلام DNS من عناصر رئيسية، أهمها QNAME وهو الاسم المطلوب، وQTYPE وهو نوع السجل، وQCLASS وهو الصنف الذي يكون عادة IN، أي الإنترنت. لذلك فإن الاستعلام عن www.example.com ليس كافياً وحده؛ إذ يجب أن يحدد العميل ما إذا كان يريد عنوان IPv4، أو عنوان IPv6، أو خادماً للبريد، أو نص تحقق، أو غير ذلك.

على سبيل المثال، قد يرسل المتصفح استعلامين متقاربين زمنياً للاسم نفسه: أحدهما من النوع A والآخر من النوع AAAA. الهدف هو اكتشاف العناوين المتاحة عبر IPv4 وIPv6 معاً، ثم اختيار مسار الاتصال الملائم وفق إعدادات نظام التشغيل والشبكة. هذه الآلية مهمة في البيئات ثنائية المكدس، حيث يتوفر البروتوكولان في الوقت نفسه.

أما خادم البريد فلا يبدأ غالباً بسؤال DNS عن سجل A للنطاق المقصود. عند إرسال رسالة إلى user@example.com، يستخرج النطاق example.com ثم يطلب سجل MX له. تعيد سجلات MX أسماء خوادم البريد مع قيم أولوية، وبعد ذلك فقط يستعلم الخادم عن سجلات A أو AAAA لأسماء تلك الخوادم كي يحصل على عناوين الاتصال الفعلية.

; استعلامات توضيحية باستخدام dig
dig A www.example.com
dig AAAA www.example.com
dig MX example.com
dig TXT example.com

قد يستخدم بعض العملاء النوع ANY نظرياً لطلب أنواع متعددة من البيانات، لكنه ليس وسيلة موثوقة لاكتشاف جميع سجلات النطاق. فكثير من خوادم DNS الموثوقة والمحللات العودية تقيد هذا النوع أو تعطي إجابات محدودة لأسباب تتعلق بالأداء والحد من إساءة الاستخدام. لذلك يجب دائماً طلب نوع السجل المطلوب صراحة.

سجلا A وAAAA: ترجمة الاسم إلى عنوان شبكة

سجل A هو السجل التقليدي الذي يربط اسم مضيف بعنوان IPv4، مثل 192.0.2.10. عندما يريد عميل الوصول إلى خادم ويب أو واجهة برمجية أو خدمة أخرى عبر IPv4، يطلب سجل A للاسم المستهدف. ويمكن أن يحتوي الاسم الواحد على أكثر من سجل A، وهو أسلوب يستخدم في توزيع الحمل البسيط أو توفير التكرار بين عدة خوادم.

www.example.com.  3600  IN  A     192.0.2.10
api.example.com.  3600  IN  A     192.0.2.20

أما سجل AAAA، ويُقرأ أحياناً «كواد-أ»، فيؤدي الوظيفة نفسها ولكن لعناوين IPv6 ذات الطول 128 بت، مثل 2001:db8::10. لا يعني وجود سجل A أن سجل AAAA سيوجد تلقائياً، ولا العكس؛ فهما سجلان مستقلان. عند دعم الخادم والشبكة لـIPv6، من الممارسات الجيدة نشر السجلين معاً كي يستطيع العملاء الوصول إلى الخدمة عبر البروتوكول الذي تدعمه شبكتهم بكفاءة.

www.example.com.  3600  IN  A     192.0.2.10
www.example.com.  3600  IN  AAAA  2001:db8::10

يعتمد المتصفح الحديث عادة آليات مثل «العينان السعيدتان» لتجنب تأخر المستخدم عند فشل أحد البروتوكولين أو بطئه. فهو قد يبدأ محاولات اتصال عبر IPv6 وIPv4 بطريقة متقاربة ومدروسة ثم يعتمد المسار الأسرع القابل للاستخدام. ولهذا يجب اختبار أن عنوان AAAA يشير إلى خادم يعمل فعلاً؛ إذ إن نشر عنوان IPv6 غير صالح قد يؤدي إلى بطء ظاهر أو فشل لدى بعض المستخدمين.

كما يجب التمييز بين اسم النطاق الجذر واسم المضيف. ففي ملفات المناطق، يشير الرمز @ غالباً إلى النطاق نفسه. لذلك يمكن إنشاء سجل A للنطاق الجذر مثل example.com، وسجل آخر مستقل للاسم www.example.com. ولا توجد قاعدة تلزم أن يشيرا إلى العنوان نفسه، رغم أن ذلك شائع في المواقع التقليدية.

سجل CNAME: الاسم المستعار وسلسلة الحل

سجل CNAME، أو الاسم القانوني، لا يعيد عنوان IP مباشرة، بل يربط اسماً باسم نطاق آخر هو الاسم الحقيقي أو القانوني. فإذا كان www.example.com اسماً مستعاراً لـsite.hosting-provider.net، فإن محلل DNS يحصل أولاً على جواب CNAME، ثم يتابع الاستعلام للحصول على سجل A أو AAAA للاسم الهدف.

www.example.com.  3600  IN  CNAME  site.hosting-provider.net.

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

لكن لسجل CNAME قواعد مهمة. لا يجوز، في منطقة DNS التقليدية، أن يحمل الاسم نفسه سجلاً من نوع CNAME وسجلات أخرى مثل A أو MX أو TXT؛ لأن CNAME يعني أن الاسم بأكمله اسم مستعار وليس كياناً مستقلاً يملك بيانات DNS إضافية. لذلك لا يمكن عادة وضع CNAME عند النطاق الجذر، لأن هذا الجذر يحتاج سجلات أساسية أخرى، مثل SOA وNS. تقدم بعض مزودي DNS حلولاً خاصة تسمى أحياناً تسطيح CNAME أو سجلات اصطناعية، لكنها ليست CNAME معيارياً على مستوى بروتوكول DNS.

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

سجل MX: توجيه البريد الإلكتروني بحسب الأولوية

سجل MX اختصار لعبارة Mail Exchanger، ووظيفته تحديد خوادم البريد التي تستقبل الرسائل الواردة لنطاق معين. لا يشير سجل MX إلى عنوان IP، بل إلى اسم مضيف كامل. ويحتوي كذلك على رقم أولوية؛ وكلما كانت القيمة أقل، كانت الأولوية أعلى.

example.com.  3600  IN  MX  10 mail1.example.com.
example.com.  3600  IN  MX  20 mail2.example.com.

mail1.example.com.  3600  IN  A     192.0.2.30
mail1.example.com.  3600  IN  AAAA  2001:db8::30
mail2.example.com.  3600  IN  A     192.0.2.31

في هذا المثال، يحاول خادم البريد المرسل الاتصال بـmail1.example.com أولاً لأنه يحمل أولوية 10. إذا تعذر الاتصال به، ينتقل إلى الخادم ذي الأولوية 20. ويمكن كذلك وضع عدة سجلات MX بالقيمة نفسها لتحقيق توزيع نسبي للحمل أو التوافر، مع أن السلوك الدقيق للاختيار قد يختلف بين تطبيقات خوادم البريد.

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

إذا لم يجد خادم البريد سجلات MX لنطاق ما، فقد يلجأ وفق قواعد SMTP إلى محاولة التسليم إلى سجل A أو AAAA للنطاق نفسه. لكن هذا السلوك الاحتياطي لا يعني أن إعداد البريد مكتمل أو آمن؛ إذ يجب نشر سجلات MX واضحة عند تشغيل بريد وارد حقيقي، ثم استكمالها بسجلات TXT الخاصة بسياسات المصادقة.

سجل TXT: بيانات مرنة للتحقق والسياسات الأمنية

سجل TXT يحمل نصاً، لكنه أصبح عنصراً محورياً في تشغيل النطاقات الحديثة. لا يملك TXT معنى وظيفياً واحداً ثابتاً مثل A أو MX؛ بل تفسر قيمته الخدمة التي طلبته. ولهذا تستخدمه منصات الاستضافة لإثبات ملكية النطاق، وتستخدمه خدمات البريد لنشر سياسات SPF وDKIM وDMARC، كما تستعمله بعض التطبيقات في التهيئة أو اكتشاف الخدمات.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.mailprovider.com -all"
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

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

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

اختيار السجل الصحيح وتشخيص أخطاء الإعداد

يعتمد اختيار نوع السجل على الغرض من الاتصال لا على اسم النطاق وحده. إن كان الهدف فتح موقع أو استدعاء واجهة برمجية، فالمطلوب عادة A وAAAA. وإن كان المطلوب ربط اسم فرعي بخدمة خارجية تتغير عناوينها، فقد يكون CNAME هو الخيار الأنسب. وعند استقبال البريد يجب استخدام MX، بينما تستخدم TXT لإثبات الملكية ونشر إعدادات الحماية والسياسات النصية.

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

يمكن فحص السجلات من سطر الأوامر ومقارنة الإجابة بالخادم الموثوق عند الحاجة. يفيد الخيار +short في عرض القيمة المختصرة، بينما يظهر الخيار +trace مسار التفويض من الجذر حتى خادم النطاق.

dig +short A www.example.com
dig +short AAAA www.example.com
dig +short MX example.com
dig +short TXT _dmarc.example.com
dig +trace www.example.com

ومن الأخطاء الشائعة: وضع عنوان IPv4 في سجل AAAA، أو كتابة هدف CNAME دون النقطة النهائية في ملف منطقة يدوي فتضاف لاحقة النطاق بصورة غير مقصودة، أو إنشاء MX يشير إلى اسم لا يملك A ولا AAAA، أو ترك سجل AAAA يشير إلى خادم غير متاح. ويجب أيضاً التحقق من عدم وجود تعارض بين سجلات CNAME وTXT عند إعداد التحقق لخدمة خارجية على الاسم نفسه.

خاتمة

لا يحدد DNS نوع السجل من تلقاء نفسه، بل يحدده العميل من خلال نوع الاستعلام الذي يتناسب مع المهمة المطلوبة. فسجلا A وAAAA يقدمان عناوين الاتصال عبر IPv4 وIPv6، وسجل CNAME ينشئ اسماً مستعاراً يتبعه المحلل إلى هدفه، وسجل MX يوجه البريد إلى خوادم الاستقبال ذات الأولوية، بينما يوفر TXT مساحة مرنة للتحقق والسياسات الأمنية. إن اختيار النوع الصحيح، واحترام قيود CNAME وMX، وضبط TTL، واختبار الإجابات بأدوات مثل dig، كلها ممارسات تضمن بنية DNS موثوقة وقابلة للتوسع وآمنة.