دليل كامل لإعداد DNS — الفرق بين A Record و CNAME والإعدادات العملية

ملخص أساسي

• A Record: ربط النطاق مباشرةً بعنوان IP (الأكثر أساسية)
• CNAME: ربط النطاق باسم مستعار لنطاق آخر (يستخدم غالبًا في النطاقات الفرعية)
• MX Record: تحديد خادم استلام البريد الإلكتروني
• TTL: مدة بقاء سجل التخزين المؤقت (كلما كانت أقصر، كلما تم تطبيق التغييرات بسرعة أكبر)

إذا أردنا وصف DNS في جملة واحدة

DNS (نظام أسماء النطاقات) هو دليل الهاتف للإنترنت الذي يقوم بتحويل أسماء النطاقات القابلة للقراءة من قبل البشر (مثل: millionscode.com) إلى عناوين IP التي تفهمها الحواسيب (مثل: 104.21.32.55).

عند إدخال عنوان URL في المتصفح، يتم استعلام خادم DNS بـ "ما هو عنوان IP لهذا النطاق؟"، ثم يتم الاتصال بالخادم الفعلي باستخدام عنوان IP المستلم. تتم هذه العملية عادةً في غضون عشرات المللي ثانية.

تنظيم كامل لأنواع سجلات DNS

A Record — الربط المباشر للنطاق بعنوان IP

A Record هو أبسط سجل DNS. يقوم بربط اسم النطاق بعنوان IPv4 (عنوان مكون من 4 أرقام) مباشرةً.

مثال على الاستخدام:

millionscode.com → 104.21.32.55

متى يتم استخدامه؟

• عند ربط النطاق بخادم VPS أو خادم مخصص
• عند ربط النطاق الجذري (example.com) بالخادم
• عند تحديد IP مباشرةً دون استخدام Cloudflare Pages

طريقة الإعداد على Cloudflare:

1. 1لوحة تحكم Cloudflare → DNS → إضافة سجل
2. 2النوع: A
3. 3الاسم: @ (النطاق الجذري) أو النطاق الفرعي المطلوب
4. 4عنوان IPv4: إدخال IP الخادم
5. 5حالة الوكيل: يفضل Proxied (سحابة برتقالية)
6. 6TTL: Auto (إدارة تلقائية عند استخدام Proxied)

CNAME Record — إعداد النطاق كاسم مستعار لنطاق آخر

CNAME هو سجل اسم مستعار (alias) يقوم بتحويل نطاق إلى نطاق آخر. يشير إلى اسم نطاق آخر وليس عنوان IP.

مثال على الاستخدام:

www.millionscode.com → millionscode.com
blog.millionscode.com → millionscode.pages.dev

متى يتم استخدامه؟

• عند ربط النطاق الفرعي www بالنطاق الجذري
• عند ربط نطاق مخصص بخدمات PaaS مثل Cloudflare Pages وVercel وNetlify
• عند ربط النطاق الفرعي بخدمات CDN

قاعدة مهمة: لا يمكن استخدام CNAME في النطاق الجذري (@) في DNS القياسي. يتجاوز Cloudflare هذا القيد من خلال ميزة CNAME Flattening.

MX Record — تحديد خادم استلام البريد الإلكتروني

MX (Mail Exchange) Record يحدد أي خادم بريد إلكتروني سيعالج الرسائل المستلمة على النطاق.

مثال على الاستخدام:

millionscode.com MX → mx1.emailprovider.com (الأولوية: 10)
millionscode.com MX → mx2.emailprovider.com (الأولوية: 20)

كلما كانت قيمة الأولوية أقل، كلما تم استخدامها أولاً. إذا تعطل الخادم الأول، يتم التحويل تلقائيًا إلى الخادم الثاني.

TXT Record — المصادقة والإعدادات المعتمدة على النص

TXT Record هو سجل عام يضيف معلومات نصية إلى النطاق. يُستخدم عادةً في المصادقة على الملكية، SPF، DKIM.

حالات الاستخدام الشائعة:

• مصادقة Google Search Console: google-site-verification=XXXXX
• مصادقة Naver Search Advisor: naver-site-verification=XXXXX
• سجل SPF: مصادقة خادم الإرسال لمنع البريد العشوائي
• DKIM: توقيع رقمي لمنع التلاعب بالبريد الإلكتروني

في الممارسة العملية: إعداد DNS على Cloudflare (خطوة بخطوة)

الخطوة 1: تغيير خادم الأسماء

قم بتغيير خادم الأسماء في الجهة التي قمت بشراء النطاق منها (مثل Gabia أو Whois) إلى خوادم Cloudflare.

استبدال خادم الأسماء القديم → خادم أسماء Cloudflare
ns1.cloudflare.com (مثال — تحقق من لوحة تحكم Cloudflare)
ns2.cloudflare.com

قد يستغرق تغيير خادم الأسماء حتى 24 ساعة للانتشار. عادةً ما يتم الانتهاء في غضون 1-2 ساعة.

الخطوة 2: إضافة سجلات DNS

قم بإضافة السجلات اللازمة في لوحة تحكم Cloudflare. يمكنك التحقق من حالة إعداد DNS الحالي لنطاقك باستخدام أداة DNS Lookup.

الخطوة 3: إعداد SSL/TLS

عند إعداد Cloudflare → SSL/TLS → قم بتعيين الوضع إلى Full (Strict)، سيتم تطبيق HTTPS تلقائيًا. لا حاجة لشراء شهادة SSL منفصلة.

دليل إعداد TTL

TTL (Time To Live) هو الوقت الذي يحتفظ فيه سجل DNS في التخزين المؤقت.

نصيحة: إذا كنت تخطط لتغيير DNS، قم بتقليل TTL إلى 300 ثانية قبل 24 ساعة. ستنتشر التغييرات بسرعة بعد ذلك.

الأخطاء الشائعة وطرق الحل

الخطأ 1: عدم اتصال www

هذا يحدث عندما يتم إعداد النطاق الجذري (@) فقط وتم تفويت CNAME لـ www. تأكد من إضافة سجل CNAME www → @.

الخطأ 2: عدم استلام البريد الإلكتروني

غالبًا ما يكون سبب ذلك هو عدم وجود سجل MX. اتبع دليل إعداد سجل MX لمزود خدمة البريد الإلكتروني بدقة.

الخطأ 3: خطأ في شهادة SSL

يحدث هذا عند تشغيل Cloudflare Proxy (سحابة برتقالية) ولكن لا توجد شهادة SSL على الخادم الأصلي. قم بتغيير وضع SSL/TLS مؤقتًا من Full (Strict) إلى Flexible، أو قم بتثبيت SSL على الخادم الأصلي.

الأسئلة الشائعة (FAQ)

Q1. أيهما يجب أن أستخدم، A Record أم CNAME؟

A: إذا كان عنوان IP للخادم ثابتًا، استخدم A Record. إذا كنت تتصل بـ PaaS (مثل Vercel أو CF Pages) أو إذا كان IP قد يتغير، استخدم CNAME. غالبًا ما يكون CNAME مريحًا للنطاقات الفرعية.

Q2. كم من الوقت يجب أن أنتظر بعد تغيير DNS؟

A: يعتمد ذلك على إعداد TTL، ولكن عادةً ما يتراوح بين 5 دقائق إلى 24 ساعة. إذا قمت بتقليل TTL إلى 300 ثانية مسبقًا، ستنتشر التغييرات في غضون 5 دقائق.

Q3. هل يجب أن أشغل Cloudflare Proxy (السحابة البرتقالية)؟

A: ليس إلزاميًا، ولكن يُوصى بذلك. عند تشغيل Proxy، ستحصل على فوائد مثل الحماية من DDoS، تخزين CDN المؤقت، وتطبيق SSL تلقائيًا.

Q4. هل يمكنني إعداد CNAME على النطاق الجذري؟

A: لا يمكن ذلك في DNS القياسي، ولكن Cloudflare يوفر CNAME Flattening ليعطي تأثير CNAME على النطاق الجذري.

Q5. هل يؤدي إعداد سجلات DNS بشكل خاطئ إلى تعطل الموقع؟

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

Q6. كيف يمكنني التحقق من إعداد DNS الحالي لنطاقي؟

A: يمكنك إدخال النطاق في أداة DNS Lookup للتحقق من سجلات A/CNAME/MX/TXT الحالية على الفور.

💡 رؤى عملية

تتوقف العديد من المدونات عند القول "A هو IP، وCNAME هو اسم مستعار"، ولكن السبب الحقيقي الذي يؤدي إلى تعطل الموقع في الممارسة العملية مختلف. بناءً على تجربتي في تشغيل millionscode.com عبر Cloudflare Pages، فإن النقطة الأكثر شيوعًا التي يرتكبها المستخدمون الكوريون هي تغيير خوادم الأسماء في Gabia أو Whois، ولكن بعد 24 ساعة لا يزال التغيير غير مفعل. هذا غالبًا ما يكون بسبب مشكلة التخزين المؤقت في الجهة المسجلة، حيث أن المتوسط في Gabia هو 1-2 ساعة، وإذا تأخرت أكثر من 6 ساعات، فإن التواصل مع الجهة المسجلة مباشرةً يكون أسرع. النقطة الثانية الأكثر شيوعًا التي يتم تفويتها هي عند ربط CNAME بالنطاق الجذري، فإن جميع الطرق بخلاف CNAME Flattening من Cloudflare تعتبر انتهاكًا لمعايير DNS القياسية، حيث تختلف طرق التحايل حسب البائع مثل سجل Alias في AWS Route 53 وANAME في Vercel. مرة، أثناء الانتقال من Cloudflare إلى DNS آخر، تم إلغاء Flattening مما أدى إلى تعطل النطاق الجذري لمدة 30 دقيقة، ولكن بفضل خفض TTL مسبقًا إلى 300 ثانية، تمكنت من استعادة الخدمة على الفور. لا توضح الأدلة العامة تغيير TTL، ولكن في الممارسة العملية، فإن خفض TTL قبل 24-48 ساعة من تغيير DNS هو إجراء ضروري يشبه التأمين. أخيرًا، إذا كنت تدير موقعًا في كوريا، فإن روبوت Naver يثق في TXT المصادقة أكثر من العلامات الوصفية، لذا يجب تسجيل Search Console وNaver Search Advisor باستخدام طريقة سجل TXT لتقليل فرص فقدان الفهرسة.