سجلّات DNS هي «دفتر العناوين» الذي يربط اسم نطاقك بعنوان خادمك وخدماتك. أهمّها: A يربط النطاق بعنوان IPv4، AAAA بعنوان IPv6، CNAME يجعل اسمًا اسمًا مستعارًا لاسم آخر، MX يوجّه البريد، وTXT يخزّن نصوصًا للتحقّق وأمان البريد (SPF/DKIM/DMARC). تعديل أي سجلّ يأخذ وقتًا للانتشار يحدّده الـTTL.
ما هو الـDNS أصلًا؟
الـDNS (نظام أسماء النطاقات) يترجم الأسماء التي يحفظها البشر (مثل example.com) إلى عناوين IP التي تفهمها الأجهزة (مثل 93.184.216.34). بدونه كنّا سنحفظ أرقامًا بدل أسماء، ولتعذّر التنقّل بين ملايين المواقع. يمكنك أن تتخيّل الـDNS كأنه «دليل الهاتف» العملاق للإنترنت: أنت تعرف اسم الشخص، والدليل يعطيك رقمه. الفرق أن هذا الدليل موزّع على ملايين الخوادم حول العالم، ويُحدَّث باستمرار، ويعمل في أجزاء من الثانية.
الفكرة الجوهرية التي يجب أن تستوعبها قبل أي شيء: نطاقك نفسه لا «يحتوي» على موقعك. النطاق مجرّد اسم، والموقع يعيش على خادم له عنوان IP. سجلّات DNS هي الجسر الذي يربط الاسم بالعنوان وبكل الخدمات المرتبطة به (البريد، الشهادات، التحقّق من الملكية). حين تفهم هذه الطبقة، تتوقّف عن «التخمين» في لوحة إدارة النطاق وتبدأ في ضبط كل سجلّ بثقة.
كل نطاق تملكه له مجموعة سجلّات تُحفظ في منطقة DNS (DNS Zone)، وتُدار من خلال خوادم الأسماء (Nameservers) الخاصّة بمزوّدك. هذه السجلّات هي ما تعدّله من لوحة التحكّم لتقول للإنترنت: «هذا النطاق يشير إلى هنا، وبريده يذهب إلى هناك، وشهاداته تصدر من هذه الجهة فقط». عند زيارة موقع، يسأل متصفّحك سلسلة من خوادم DNS حتى يصل إلى خوادم الأسماء المسؤولة عن نطاقك، فتعيد له السجلّ المطلوب.
كيف يُحَل اسم النطاق خطوة بخطوة؟
حين تكتب example.com في المتصفّح وتضغط Enter، تجري سلسلة من الاستعلامات في أجزاء من الثانية. فهم هذه السلسلة يفسّر تقريبًا كل سؤال يخطر ببالك لاحقًا عن «لماذا لا يظهر تغييري» و«لماذا يعمل الموقع عندي ولا يعمل عند صديقي». إليك ما يحدث بالضبط:
-
الفحص المحلّي (Cache المتصفّح والنظام): أول ما يفعله جهازك هو البحث في ذاكرته المؤقّتة. هل سبق وحلّ هذا الاسم قبل قليل؟ إن وُجدت نسخة صالحة (لم ينتهِ TTL)، تُستخدم فورًا دون أي اتصال بالشبكة. يفحص الجهاز أيضًا ملف
hostsالمحلّي الذي يتجاوز DNS تمامًا. -
المحلِّل العَوْدي (Recursive Resolver): إن لم تكن النسخة محلّيًا، يرسل جهازك الاستعلام إلى محلِّل عودي — عادةً تابع لمزوّد الإنترنت لديك، أو محلِّل عام مثل
1.1.1.1من Cloudflare أو8.8.8.8من Google. هذا المحلِّل هو «الوكيل» الذي سيقوم بكل العمل الشاق نيابة عنك. وهو أيضًا يملك Cache خاصًّا به، فإن كان مستخدم آخر على نفس المحلِّل قد طلبexample.comقبل دقائق، يجيبك المحلِّل من ذاكرته مباشرة. -
خادم الجذر (Root Server): إن لم يجد المحلِّل العودي الإجابة في ذاكرته، يبدأ رحلة «من الأعلى». يسأل أحد خوادم الجذر الثلاثة عشر المنطقية (المتكرّرة في مئات المواقع حول العالم): «أين أجد المسؤول عن النطاقات المنتهية بـ
.com؟». لا يعرف خادم الجذر عنوانexample.com، لكنه يعرف من يدير امتداد.com، فيحيلك إلى خوادم الـTLD. -
خادم نطاق المستوى الأعلى (TLD Server): هذا الخادم مسؤول عن امتداد بعينه مثل
.comأو.netأو.sa. يسأله المحلِّل: «من يديرexample.comتحديدًا؟». يردّ خادم الـTLD بعناوين خوادم الأسماء المختصّة (Authoritative Nameservers) المسجّلة لهذا النطاق — وهي الخوادم التي وضعتها في لوحة مسجّل النطاق. -
خادم الأسماء المختصّ (Authoritative Nameserver): هذه هي المحطّة النهائية ومصدر الحقيقة. هذا الخادم يحتفظ بمنطقة DNS الفعلية لنطاقك، وفيها كل سجلّاتك (A، MX، TXT…). يسأله المحلِّل عن السجلّ المطلوب (سجلّ A مثلًا)، فيردّ بالعنوان:
93.184.216.34. -
التخزين المؤقّت ثم الإجابة: يستلم المحلِّل العودي العنوان، يخزّنه في ذاكرته لمدّة تساوي الـTTL، ثم يعيده إلى جهازك. جهازك بدوره يخزّنه محلّيًا، ويفتح اتصالًا بالخادم على ذلك العنوان. الموقع يظهر.
| المرحلة | يسأل من | يحصل على | هل يخزّن النتيجة؟ |
|---|---|---|---|
| Cache المحلّي | ذاكرة الجهاز/المتصفّح | إجابة فورية إن وُجدت | نعم |
| المحلِّل العودي | يقود الرحلة كلها | الإجابة النهائية للعميل | نعم (حسب TTL) |
| خادم الجذر | المحلِّل العودي | إحالة لخادم الـTLD | لا (مرجعية ثابتة) |
| خادم الـTLD | المحلِّل العودي | خوادم الأسماء المختصّة | نعم (TTL للإحالة) |
| الخادم المختصّ | المحلِّل العودي | السجلّ المطلوب فعليًا | نعم (TTL للسجلّ) |
النقطة الحاسمة: كل خطوة فيها تخزين مؤقّت، وهذا بالضبط سبب أن تغييراتك لا تظهر فورًا. أنت غيّرت السجلّ في الخادم المختصّ، لكن ملايين المحلِّلات حول العالم ما تزال تحمل النسخة القديمة حتى ينتهي الـTTL. هذا ما نسمّيه «انتشار DNS»، وسنفصّله لاحقًا.
أهم سجلّات DNS في جدول
قبل التعمّق، إليك خريطة سريعة لأكثر السجلّات تداولًا. كل سطر يجيب على سؤال عملي: ما الذي يربطه هذا السجلّ، وكيف يبدو مثاله، ولماذا تستخدمه.
| السجلّ | يربط | المثال | الاستخدام |
|---|---|---|---|
| A | اسم ← IPv4 | @ → 93.184.216.34 | توجيه النطاق إلى خادمك |
| AAAA | اسم ← IPv6 | @ → 2606:2800:220:1:: | نفس A لكن لعناوين IPv6 |
| CNAME | اسم ← اسم آخر | www → example.com | اسم مستعار/نطاق فرعي |
| MX | البريد ← خادم بريد | @ → mail.example.com (10) | استقبال البريد |
| TXT | نص حر | v=spf1 include:... ~all | تحقّق وأمان البريد |
| NS | النطاق ← خوادم الأسماء | @ → ns1.host.com | من يدير DNS النطاق |
| CAA | النطاق ← مصدّر الشهادات | 0 issue "letsencrypt.org" | من يحقّ له إصدار SSL |
| SRV | خدمة ← مضيف+منفذ | _sip._tcp → 10 5 5060 sip.example.com | تحديد خادم خدمة معيّنة |
| PTR | IP ← اسم | 34.216.184.93.in-addr.arpa → mail.example.com | DNS عكسي (مهم للبريد) |
| SOA | بداية المنطقة | ns1.host.com admin.example.com ... | بيانات إدارة المنطقة |
| ALIAS/ANAME | الجذر ← اسم | @ → app.netlify.app | CNAME مسطّح على الجذر |
شرح كل سجلّ بالتفصيل
سجلّ A و AAAA
سجلّ A هو الأكثر استخدامًا على الإطلاق: يربط نطاقك (أو نطاقًا فرعيًا) بعنوان IPv4 لخادمك. القيمة دائمًا عنوان رقمي على شكل أربع خانات. أمثلة عملية:
@ A 93.184.216.34 ; الجذر example.com يشير لخادمك
blog A 185.199.108.153 ; blog.example.com يشير لخادم آخر
يمكنك أيضًا وضع عدّة سجلّات A لنفس الاسم تشير لعناوين مختلفة، فيوزّع DNS الطلبات بينها (Round-robin) لتوزيع حِمل بدائي. سجلّ AAAA يفعل الشيء نفسه لكن لعناوين IPv6 الأحدث والأطول، ويتعايش مع A دون مشكلة — يفضّل العميل IPv6 إن توفّر، وإلا يسقط إلى IPv4:
@ AAAA 2606:2800:220:1:: ; نسخة IPv6 للجذر
www AAAA 2606:2800:220:1:248:1893:25c8:1946
القاعدة العملية: استخدم A للجذر وللخوادم التي تعرف عنوانها الرقمي الثابت. وإن كان خادمك يدعم IPv6 (وأغلب الاستضافات الحديثة تدعمه)، أضِف AAAA المقابل ليصلك زوّار الشبكات الحديثة بأسرع مسار.
سجلّ CNAME
يجعل اسمًا اسمًا مستعارًا لاسم آخر، بحيث يُحَل الأول بالرجوع إلى الثاني. هذا مفيد جدًّا حين لا تعرف عنوان IP الثابت للوجهة، أو حين تتغيّر عناوينها باستمرار (كما في خدمات الاستضافة السحابية وشبكات التوزيع). أمثلة:
www CNAME example.com. ; www يتبع الجذر
shop CNAME mystore.myshopify.com. ; المتجر مستضاف لدى طرف ثالث
cdn CNAME d111.cloudfront.net. ; نطاق فرعي يتبع CDN
قاعدتان مهمّتان: لا يمكن وضع CNAME على جذر النطاق (@) لأنه يتعارض مع سجلّات إلزامية موجودة على الجذر مثل SOA وNS، ولا يُمزَج CNAME مع أي سجلّ آخر لنفس الاسم. لتجاوز قيد الجذر، طوّر المزوّدون سجلّ ALIAS/ANAME الذي سنشرحه بعد قليل.
سجلّ MX
يوجّه بريد نطاقك إلى خادم البريد الصحيح، ويحمل رقم أولوية (Priority) حيث الرقم الأقل أعلى أولوية. تستخدم عادةً سجلَّين أو أكثر: الأساسي بأولوية منخفضة، واحتياطيًا بأولوية أعلى يُستخدم إن تعطّل الأول:
@ MX 10 mx1.example-mail.com. ; الأساسي
@ MX 20 mx2.example-mail.com. ; الاحتياطي
نقطة شائعة الخطأ: قيمة MX يجب أن تكون اسمًا (hostname) لا عنوان IP، وذلك الاسم يجب أن يكون له سجلّ A/AAAA صالح يحلّه إلى عنوان. بدون MX سليم لن يصل بريد نطاقك إطلاقًا.
سجلّ TXT (المفتاح لأمان البريد)
يخزّن نصوصًا حرّة تستخدمها الخدمات للتحقّق. أشهر استخداماته على الإطلاق هو مصادقة البريد (نفصّلها في قسم مستقل لاحقًا)، إضافةً إلى التحقّق من ملكية النطاق لدى خدمات مثل Google Search Console ومنصّات التسويق:
@ TXT "google-site-verification=abcdef123456"
@ TXT "v=spf1 include:_spf.google.com ~all"
selector1._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
| الاستخدام (داخل TXT) | يفعل |
|---|---|
| SPF | يحدّد الخوادم المسموح لها بالإرسال باسم نطاقك |
| DKIM | توقيع رقمي يثبت أن الرسالة لم تُعدَّل في الطريق |
| DMARC | السياسة عند فشل SPF/DKIM + إلى أين تُرسل التقارير |
| التحقّق من الملكية | يثبت لخدمة خارجية أنك تملك النطاق |
سجلّ NS و CAA
NS يحدّد خوادم الأسماء المختصّة المسؤولة عن نطاقك. هذه السجلّات تُضبط عادةً عند مسجّل النطاق (المستوى الأعلى)، وتُحدَّث عند تغيير مزوّد DNS أو نقل النطاق لمزوّد جديد:
@ NS ns1.wpressly.com.
@ NS ns2.wpressly.com.
CAA يحدّد جهات إصدار الشهادات (Certificate Authorities) المسموح لها بإصدار شهادات SSL لنطاقك، ويضيف طبقة أمان تمنع جهة غير مصرّح لها من إصدار شهادة باسمك:
@ CAA 0 issue "letsencrypt.org" ; يسمح فقط لـ Let's Encrypt
@ CAA 0 issuewild "letsencrypt.org" ; يسمح بشهادات wildcard منها
@ CAA 0 iodef "mailto:security@example.com" ; أبلغني عند طلب مخالف
راجع تفاصيل الشهادات في تركيب شهادة SSL وتفعيل HTTPS.
سجّل نطاقك وأدِر DNS بسهولة
خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.
احجز نطاقك الآنسجلّات أقل شهرة لكن مهمّة (SRV/PTR/SOA/CAA)
بعد السجلّات الأساسية، هناك سجلّات «الطبقة الثانية» التي قد لا تلمسها يوميًّا، لكنها حاسمة في حالات محدّدة — خصوصًا حين يتعلّق الأمر بالبريد، أو خدمات الصوت والاتصال، أو سلامة المنطقة نفسها. تجاهلها هو سبب شائع لمشاكل غامضة يصعب تشخيصها.
سجلّ SRV (تحديد خدمة على منفذ)
يخبر العميل أين تعمل خدمة معيّنة وعلى أي منفذ، بدل افتراض المنفذ الافتراضي. يستخدم بكثرة في بروتوكولات مثل SIP (الهاتف عبر الإنترنت)، وXMPP (الدردشة)، وMicrosoft Teams/Skype for Business، وألعاب Minecraft. صيغته: _خدمة._بروتوكول SRV أولوية وزن منفذ مضيف:
_sip._tcp.example.com. SRV 10 60 5060 sip1.example.com.
_minecraft._tcp.example.com. SRV 0 5 25565 mc.example.com.
«الأولوية» تعمل كما في MX (الأقل أولًا)، و«الوزن» يوزّع الحِمل بين السجلّات ذات الأولوية نفسها.
سجلّ PTR (الـDNS العكسي — مهم للبريد)
كل ما سبق كان «أمامي»: من اسم إلى عنوان. سجلّ PTR يعمل بالعكس تمامًا: من عنوان IP إلى اسم. يُستخدم في النطاق العكسي (in-addr.arpa لـIPv4 وip6.arpa لـIPv6)، وأهميته القصوى في تسليم البريد: حين يرسل خادمك بريدًا، يفحص الخادم المستقبِل العنوان الذي اتصل منه، ويتحقّق هل يحلّ عكسيًا إلى اسم منطقي يطابق هوية المرسِل (Forward-confirmed reverse DNS). إن لم يوجد PTR أو لم يطابق، تُصنَّف رسائلك سبامًا أو تُرفض:
34.216.184.93.in-addr.arpa. PTR mail.example.com.
1.0.0...e.ip6.arpa. PTR mail.example.com.
ملاحظة عملية مهمّة: سجلّ PTR لا تضبطه أنت عادةً في منطقة نطاقك، بل يضبطه مالك العنوان — أي شركة الاستضافة أو مزوّد الخادم — لأنه يعيش في المنطقة العكسية التابعة لكتلة العناوين. لذلك إن احتجت PTR صحيحًا لخادم بريد، اطلبه من مزوّد الاستضافة.
سجلّ SOA (بداية السلطة على المنطقة)
كل منطقة DNS تحتوي إلزاميًّا على سجلّ SOA (Start of Authority) واحد على الجذر، وهو «بطاقة هوية» المنطقة. يحمل بيانات إدارية: خادم الأسماء الأساسي، بريد المسؤول، رقم تسلسلي (Serial) يزيد مع كل تعديل ليعرف الخوادم الثانوية أن عليها التحديث، وقيم زمنية للتحديث وإعادة المحاولة وانتهاء الصلاحية:
example.com. SOA ns1.wpressly.com. admin.example.com. (
2026061101 ; Serial (التاريخ + رقم تعديل اليوم)
7200 ; Refresh
3600 ; Retry
1209600 ; Expire
300 ) ; Minimum / negative TTL
نادرًا ما تعدّل SOA يدويًّا، لكن فهمه مفيد عند تشخيص مشاكل المزامنة بين خوادم الأسماء، أو عند ملاحظة أن الرقم التسلسلي لم يتغيّر رغم تعديلك (ما يعني أن التعديل لم يُنشر فعليًّا).
سجلّ ALIAS/ANAME (CNAME مسطّح على الجذر)
ذكرنا أن CNAME ممنوع على الجذر. لكن ماذا لو كانت استضافتك (مثل Netlify أو Vercel أو خدمة CDN) تعطيك اسمًا لا عنوانًا، وتريد أن يشير example.com نفسه إليها؟ هنا يأتي سجلّ ALIAS (يسمّيه بعض المزوّدين ANAME أو CNAME Flattening). هو يتصرّف كـCNAME ظاهريًّا، لكن المزوّد «يسطّحه» داخليًّا: يحلّ الاسم المستهدف إلى عنوان IP ويردّ به سجلّ A عاديًا، فلا يخالف قواعد الجذر:
@ ALIAS my-site.netlify.app. ; الجذر يتبع استضافة طرف ثالث
@ ANAME d111abc.cloudfront.net. ; نفس الفكرة لدى مزوّد آخر
ليس سجلًّا قياسيًّا في بروتوكول DNS الأصلي، لذا توفّره يعتمد على مزوّدك. إن لم يدعمه، البديل هو وضع سجلّ A بالعنوان الصريح إن كان ثابتًا.
مصادقة البريد بالتفصيل (SPF/DKIM/DMARC)
أكثر سبب يجعل بريدك «يهبط» في مجلّد السبام، أو يُرفض كليًّا، هو ضعف مصادقة البريد. الثلاثي SPF + DKIM + DMARC هو ما يقنع مزوّدي البريد (Gmail وOutlook وغيرهما) أن رسائلك أصلية وليست انتحالًا لنطاقك. كلها سجلّات TXT (عدا أن DKIM وDMARC يوضعان على أسماء فرعية خاصّة). لنفصّل كلًّا منها بأمثلة قابلة للنسخ.
SPF — من يحقّ له الإرسال باسمك؟
سجلّ SPF (Sender Policy Framework) يعدّد الخوادم والخدمات المسموح لها بإرسال بريد باسم نطاقك. يوضع كسجلّ TXT واحد فقط على الجذر، ويبدأ دائمًا بـv=spf1. القاعدة الذهبية: سجلّ SPF واحد لا أكثر؛ وجود سجلَّين يكسر الآلية بالكامل:
@ TXT "v=spf1 include:_spf.google.com include:mailgun.org ip4:93.184.216.34 ~all"
تتكوّن قيمة SPF من «آليات» (Mechanisms) تُقرأ من اليسار حتى أول تطابق:
| الآلية | معناها | مثال |
|---|---|---|
include: | اسمح بالمصرّح لهم في نطاق آخر | include:_spf.google.com |
ip4: / ip6: | اسمح بعنوان/كتلة عناوين محدّدة | ip4:93.184.216.34 |
a | اسمح بالخادم في سجلّ A للنطاق | a |
mx | اسمح بخوادم MX للنطاق | mx |
~all | SoftFail: مرّر المشكوك لكن علّمه | ~all |
-all | HardFail: ارفض أي مرسِل غير مدرج | -all |
?all | محايد: لا حكم (لا يُنصح به) | ?all |
الفرق العملي بين ~all و-all مهم: استخدم ~all (SoftFail) أثناء الإعداد والاختبار كي لا تخسر بريدًا شرعيًّا بالخطأ، ثم انتقل إلى -all (HardFail) بعد التأكّد من إدراج كل مصادر إرسالك. انتبه أيضًا لحدّ «10 عمليات بحث DNS» داخل SPF؛ تجاوزه يُبطل السجلّ.
DKIM — التوقيع الرقمي للرسالة
سجلّ DKIM (DomainKeys Identified Mail) يضيف توقيعًا رقميًّا لكل رسالة مرسلة، يثبت أنها صادرة فعلًا من نطاقك وأنها لم تُعدَّل في الطريق. يعمل بزوج مفاتيح: المفتاح الخاص يحتفظ به خادم الإرسال ويوقّع به، والمفتاح العام تنشره أنت في DNS كسجلّ TXT على اسم فرعي يُسمّى Selector. الـSelector يسمح بوجود أكثر من مفتاح (مثلًا للتدوير الدوري للمفاتيح):
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB...IDAQAB"
google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
عند استلام الرسالة، يقرأ المستقبِل اسم الـSelector من ترويسة الرسالة، يجلب المفتاح العام من DNS، ويتحقّق من التوقيع. تطابق التوقيع = الرسالة أصلية وسليمة. عادةً تأخذ قيمة DKIM جاهزة من مزوّد بريدك (Google Workspace، Mailgun، إلخ) وتلصقها كما هي.
DMARC — السياسة والتقارير
سجلّ DMARC (Domain-based Message Authentication) هو القائد الذي يربط SPF وDKIM معًا: يقرّر ماذا يفعل المستقبِل حين تفشل المصادقة، وإلى أين يرسل تقارير عمّا يحدث باسم نطاقك. يوضع كسجلّ TXT على الاسم الفرعي _dmarc:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100; aspf=r; adkim=r"
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=50"
أهم وسم هو p= (السياسة)، وله ثلاث قيم تمثّل تدرّجًا في الصرامة:
السياسة (p=) | ماذا يفعل المستقبِل عند الفشل | متى تستخدمها |
|---|---|---|
p=none | لا شيء — يراقب ويرسل تقارير فقط | البداية: راقب قبل أن تشدّد |
p=quarantine | يضع الرسالة الفاشلة في السبام | بعد التأكّد أن الشرعي يمرّ |
p=reject | يرفض الرسالة الفاشلة كليًّا | الهدف النهائي للحماية الكاملة |
الوسم rua= يحدّد بريدًا لاستقبال التقارير المجمّعة (Aggregate reports) يوميًّا — وهي ذهب خالص لاكتشاف من ينتحل نطاقك ومن مصادر إرسالك التي نسيتها. النهج الموصى به: ابدأ بـp=none مع rua، اقرأ التقارير أسبوعين، أصلح أي مصدر شرعي يفشل، ثم تدرّج إلى quarantine فـreject. الوسم pct= يطبّق السياسة على نسبة مئوية فقط من البريد، ما يتيح تدرّجًا أنعم.
CNAME مع شبكة CDN
من أكثر استخدامات CNAME شيوعًا اليوم ربط نطاقك بشبكة توزيع محتوى (CDN). شبكة الـCDN تخزّن نسخًا من موقعك في عشرات المواقع حول العالم، فتُخدَّم الصفحات من أقرب نقطة للزائر بدل خادمك الأصلي البعيد. إن لم تكن تعرف الفكرة، اقرأ ما هي شبكة توزيع المحتوى CDN؟ أولًا.
عمليًّا، يعطيك مزوّد الـCDN اسمًا فريدًا (لا عنوانًا)، لأن عناوين عُقَده تتغيّر باستمرار حسب الحِمل والموقع الجغرافي. لذلك تربط نطاقك الفرعي به عبر CNAME:
www CNAME d111abc.cloudfront.net. ; CDN على AWS
assets CNAME example.b-cdn.net. ; نطاق فرعي للملفّات الثابتة
cdn CNAME example.cdn.cloudflare.net.
أما إن أردت توجيه الجذر نفسه (example.com بلا www) عبر CDN، فلا يمكنك استخدام CNAME على الجذر كما شرحنا — هنا تستخدم سجلّ ALIAS/ANAME إن دعمه مزوّدك، أو تعتمد على مزوّد يدمج الـCDN مع خوادم أسمائه ويسطّح السجلّ تلقائيًّا. هذا أحد أسباب اختيار مزوّد DNS يدعم CNAME Flattening حين تخطّط لاستخدام CDN على الجذر.
TTL والانتشار: لماذا لا يظهر تغييري فورًا؟
كل سجلّ يحمل قيمة TTL (Time To Live) بالثواني، تحدّد كم تخزّن المحلِّلات والخوادم نسخة السجلّ مؤقّتًا (Cache) قبل أن تطلب نسخة جديدة من الخادم المختصّ. هذا هو المفتاح لفهم «انتشار DNS»: حين تعدّل سجلًّا، الخادم المختصّ يحمل القيمة الجديدة فورًا، لكن كل محلِّل في العالم سيظلّ يخدم القيمة القديمة حتى ينتهي الـTTL الذي خزّنها به.
| قيمة TTL | يعني |
|---|---|
| 300 (5 دقائق) | تغييرات سريعة الانتشار (قبل النقل) |
| 3600 (ساعة) | توازن شائع للسجلّات العادية |
| 86400 (يوم) | استقرار وتقليل استعلامات (سجلّات نادرة التغيّر) |
لا توجد قيمة TTL «صحيحة» واحدة؛ القيمة المثلى تختلف حسب نوع السجلّ ومدى تكرار تغييره. إليك استراتيجية عملية حسب النوع:
| نوع السجلّ | TTL المقترح | السبب |
|---|---|---|
| A/AAAA قيد التغيير القريب | 300 ثانية | تسريع الانتشار قبل النقل |
| A/AAAA مستقرّ | 3600 ثانية | توازن بين السرعة والكفاءة |
| MX | 3600–14400 | يتغيّر نادرًا، لكن أبقِه مرنًا |
| TXT (SPF/DKIM/DMARC) | 3600 | قد تحتاج تعديله أثناء الضبط |
| NS | 86400 | شديد الاستقرار، يُغيّر نادرًا جدًّا |
| CNAME للـCDN | 3600 | يتبع وجهة مستقرّة عادةً |
النصيحة العملية الذهبية: قبل أي تغيير مخطّط له (نقل الموقع أو ترقية الخادم أو تبديل المزوّد)، خفّض TTL للسجلّ المعني إلى 300 ثانية قبل التغيير بيوم على الأقل — لأن التخفيض نفسه يحتاج وقتًا لينتشر بقيمته القديمة. بعد ذلك نفّذ التغيير الفعلي فينتشر خلال دقائق، ثم أعِد TTL لقيمة أعلى بعد الاستقرار لتقليل الاستعلامات. «انتشار DNS» قد يستغرق من دقائق إلى ساعات حسب TTL وذواكر المحلِّلات حول العالم — هذا طبيعي وليس عطلًا.
أدوات فحص DNS
لا تعتمد على «هل يفتح الموقع عندي؟» للحكم على انتشار التغيير، لأن جهازك قد يخدم نسخة مخزّنة محلّيًّا. استخدم أدوات تستعلم مباشرة من الخوادم. إليك أهمّها:
| الأداة | المنصّة | تستعلم عن |
|---|---|---|
dig | لينكس/ماك | أي نوع سجلّ بتفصيل كامل وTTL |
nslookup | ويندوز/الكل | استعلام سريع لسجلّ معيّن |
host | لينكس/ماك | استعلام مختصر وسريع |
| فاحص أونلاين | المتصفّح | الانتشار عبر مواقع عالمية متعدّدة |
أمثلة عملية لأوامر dig وnslookup:
dig example.com A +short ; عنوان IPv4 فقط
dig example.com MX ; سجلّات البريد وأولوياتها
dig _dmarc.example.com TXT +short ; سياسة DMARC
dig example.com NS ; خوادم الأسماء المختصّة
dig @1.1.1.1 example.com A ; استعلم من محلِّل محدّد لتجاوز Cache المحلّي
nslookup -type=MX example.com ; نفس الفكرة على ويندوز
نقطة مهمّة: لفحص ما إذا انتشر التغيير عالميًّا، استخدم فاحصًا أونلاين يستعلم من عشرات المواقع حول العالم في وقت واحد. إن ظهرت القيمة الجديدة في بعض المواقع والقديمة في أخرى، فالانتشار جارٍ ولم يكتمل بعد — انتظر بقدر TTL القديم. ولتجاوز ذاكرة جهازك المحلّية، استعلم من محلِّل عام مباشرة بإضافة @1.1.1.1 كما في المثال أعلاه.
سيناريوهات شائعة سريعة
| تريد أن | افعل |
|---|---|
| توجيه نطاقك لخادم جديد | حدّث سجلّ A (وAAAA) بالعنوان الجديد |
| جعل www يتبع النطاق | CNAME من www إلى الجذر |
| توجيه الجذر لاستضافة باسم لا IP | استخدم ALIAS/ANAME (CNAME مسطّح) |
| استقبال بريد بنطاقك | أضِف سجلّ MX (+ SPF/DKIM/DMARC) |
| ربط نطاق فرعي بشبكة CDN | CNAME من النطاق الفرعي إلى اسم الـCDN |
| التحقّق من ملكية النطاق | أضِف سجلّ TXT المطلوب من الخدمة |
| تقييد من يصدر شهادتك | أضِف سجلّ CAA |
| تشغيل خدمة صوت/دردشة | أضِف سجلّ SRV بالمنفذ والمضيف |
| تحسين تسليم بريدك | اطلب PTR صحيحًا من مزوّد الخادم |
النطاقات الفرعية (Subdomains)
النطاق الفرعي مثل blog.example.com أو app.example.com ليس نطاقًا منفصلًا تشتريه، بل مجرّد سجلّ DNS تضيفه تحت نطاقك الأساسي. هذا يمنحك مرونة هائلة: تستضيف المدونة على خادم، والمتجر على آخر، والتطبيق على ثالث — كلها تحت نفس النطاق بلا تكلفة إضافية. تنشئ نطاقًا فرعيًّا بإضافة سجلّ A (إن عرفت العنوان) أو CNAME (إن كان يتبع اسمًا):
blog A 185.199.108.153 ; المدونة على خادم خاص
app A 93.184.216.34 ; التطبيق على خادم آخر
shop CNAME mystore.myshopify.com. ; المتجر لدى طرف ثالث
docs CNAME org.gitbook.io. ; التوثيق على خدمة سحابية
يمكنك أيضًا إنشاء نطاق فرعي «شامل» (Wildcard) بالرمز * ليلتقط أي نطاق فرعي غير معرّف صراحةً — مفيد لتطبيقات SaaS متعدّدة المستأجرين حيث يحصل كل عميل على نطاق فرعي خاص:
* A 93.184.216.34 ; أي نطاق فرعي غير معرّف يشير هنا
انتبه أن سجلّات النطاقات الفرعية تخضع لنفس قواعد الجذر: CNAME لا يُمزَج مع غيره، والـTTL يُدار لكل سجلّ على حدة. ولاحظ أن النطاق الفرعي قد يحتاج شهادة SSL خاصّة به (أو شهادة wildcard تغطّي *.example.com).
سجّل نطاقك وأدِر DNS بسهولة
خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.
احجز نطاقك الآنحلّ المشاكل الشائعة
| المشكلة | السبب المحتمل | الحلّ |
|---|---|---|
| الموقع لا يفتح بعد تغيير A | لم يكتمل الانتشار | انتظر بقدر TTL القديم، وافحص بـdig |
| الموقع يفتح عندك لا عند غيرك | Cache محلّي قديم على جهازك | امسح DNS Cache أو استعلم من @1.1.1.1 |
| البريد لا يصل | غياب MX أو خطأ في قيمته | راجع سجلّ MX وأولويّته وأنه اسم لا IP |
| بريدك يذهب للسبام | SPF/DKIM/DMARC ناقص أو خاطئ | اضبط سجلّات TXT الثلاثة بدقّة |
| بريدك مرفوض كليًّا | PTR مفقود أو لا يطابق | اطلب PTR صحيحًا من مزوّد الخادم |
| CNAME لا يعمل على الجذر | قيد تقني في البروتوكول | استخدم A أو ALIAS/ANAME |
| الشهادة لا تصدر | CAA يمنع جهة الإصدار | أضِف الجهة في سجلّ CAA أو احذف القيد |
| تعديلك لا ينتشر إطلاقًا | لم يتغيّر Serial في SOA | تأكّد أن المنطقة حُفظت ونُشرت فعلًا |
أخطاء شائعة
- وضع CNAME على جذر النطاق (@) بدل ALIAS/ANAME.
- نسيان سجلّ MX فلا يصل البريد إطلاقًا.
- إعداد أكثر من سجلّ SPF واحد (يجب أن يكون سجلّ SPF واحدًا فقط لكل نطاق).
- استخدام
-allفي SPF قبل التأكّد من إدراج كل مصادر الإرسال، فتضيع رسائل شرعية. - ترك DMARC على
p=noneللأبد دون التدرّج إلىquarantineثمreject. - وضع عنوان IP في قيمة MX أو SPF
includeبدل اسم مضيف صالح. - توقّع ظهور التغيير فورًا وتجاهل الـTTL وذاكرة المحلِّلات.
الخلاصة والخطوة التالية
فهم سجلّات DNS يمنحك تحكّمًا كاملًا في نطاقك: أين يشير، كيف يستقبل البريد، أين تُخدَّم ملفّاته، وكيف يُؤمَّن. ابدأ بسجلّ A وAAAA الصحيحين، أضِف MX مع ثلاثي SPF وDKIM وDMARC للبريد، استخدم CNAME (أو ALIAS على الجذر) لربط الـCDN، واضبط TTL بذكاء قبل أي تغيير مخطّط. وإن كنت تختار بنية الاستضافة المناسبة لمشروعك، فقارن خياراتك في الاستضافة المشتركة وVPS والمُدارة.
سجّل نطاقك وأدِر DNS بسهولة
خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.
احجز نطاقك الآنالأسئلة الشائعة
ما الفرق بين سجلّ A وسجلّ CNAME؟ سجلّ A يربط الاسم بعنوان IP رقمي مباشرة، بينما CNAME يربط الاسم باسم آخر (اسم مستعار) يُحَل بدوره إلى IP. استخدم A للجذر والخوادم ذات العناوين الثابتة، وCNAME للنطاقات الفرعية التي تتبع اسمًا خارجيًّا متغيّر العنوان مثل شبكات الـCDN.
لماذا لا يظهر تعديل DNS فورًا؟
بسبب الـTTL: المحلِّلات والخوادم تخزّن نسخة من السجلّ مؤقّتًا حتى انتهاء مدّته. خفّض TTL قبل التغيير المخطّط له بيوم لتسريع الانتشار، وتوقّع من دقائق إلى ساعات حتى يكتمل عالميًّا. افحص بـdig أو فاحص أونلاين بدل الاعتماد على جهازك.
ما سجلّ DNS الذي يوجّه البريد؟ سجلّ MX. يحدّد خادم البريد المسؤول عن استقبال رسائل نطاقك ويحمل رقم أولوية (الأقل أعلى أولوية). تكمله سجلّات TXT للأمان (SPF وDKIM وDMARC) وسجلّ PTR العكسي من جهة المرسِل لضمان عدم الرفض.
هل أحتاج سجلّ AAAA؟ ليس إلزاميًّا، لكنه مفيد إن كان خادمك يدعم IPv6 ليصله زوّار الشبكات الحديثة بأسرع مسار. يتعايش مع سجلّ A دون مشكلة: يفضّل العميل IPv6 إن توفّر، وإلا يسقط تلقائيًّا إلى IPv4.
ما الفرق بين SPF وDKIM وDMARC؟ SPF يحدّد من يحقّ له الإرسال باسمك، وDKIM يضيف توقيعًا رقميًّا يثبت أن الرسالة لم تُعدَّل، وDMARC يربط الاثنين ويقرّر ماذا يفعل المستقبِل عند الفشل وإلى أين يرسل التقارير. الثلاثة معًا هي ما يبقي بريدك خارج السبام.
ما هو سجلّ PTR ولماذا هو مهم للبريد؟ PTR هو سجلّ DNS العكسي الذي يربط عنوان IP باسم، عكس بقيّة السجلّات. خوادم البريد المستقبِلة تتحقّق منه: إن لم يحلّ عنوان المرسِل عكسيًّا إلى اسم منطقي مطابق، تُرفض رسائلك أو تُصنّف سبامًا. تضبطه عادةً شركة الاستضافة لا أنت، فاطلبه منها لخادم بريدك.
لماذا لا يمكن وضع CNAME على جذر النطاق؟ لأن الجذر يحمل إلزاميًّا سجلّات SOA وNS، وقاعدة DNS تمنع مزج CNAME مع أي سجلّ آخر لنفس الاسم. البديل هو سجلّ ALIAS أو ANAME (CNAME مسطّح) الذي يحلّ الاسم داخليًّا ويردّ بسجلّ A، أو وضع سجلّ A صريح إن كان العنوان ثابتًا.
كيف أربط نطاقي بشبكة CDN؟
للنطاقات الفرعية مثل www أو cdn، أضِف سجلّ CNAME يشير إلى الاسم الذي يعطيك إياه مزوّد الـCDN. للجذر نفسه، استخدم ALIAS/ANAME لأن CNAME ممنوع عليه. اقرأ ما هي شبكة CDN؟ لفهم الفائدة كاملة قبل الإعداد.
كيف أتحقّق من انتشار تغيير DNS؟
استخدم أمر dig example.com A +short أو nslookup، أو جرّب فاحص DNS والانتشار الذي يستعلم من مواقع عالمية متعدّدة في آن واحد. لتجاوز ذاكرة جهازك المحلّية، استعلم من محلِّل عام مباشرة عبر dig @1.1.1.1 example.com. اختلاف النتائج بين المواقع يعني أن الانتشار جارٍ ولم يكتمل.
ما علاقة DNS بشهادة SSL؟ بعض طرق التحقّق من ملكية النطاق لإصدار SSL تتمّ بإضافة سجلّ TXT (طريقة DNS-01)، كما يحدّد سجلّ CAA من يحقّ له إصدار الشهادة من الأساس. التفاصيل في تركيب SSL وتفعيل HTTPS.
لماذا يذهب بريدي إلى السبام؟
غالبًا بسبب نقص أو خطأ في سجلّات مصادقة البريد (SPF/DKIM/DMARC) داخل TXT، أو غياب سجلّ PTR عكسي صحيح. اضبطها بدقّة ليثق مزوّدو البريد بنطاقك ويسلّموا رسائلك إلى الوارد. ابدأ DMARC بـp=none مع تقارير ثم تدرّج إلى reject.