انتشار DNS وسيرفرات الأسماء (Nameservers) ولماذا لا يشير نطاقك إلى موقعك حتى الآن
إذا كان نطاقك لا يعرض موقعك الجديد بعد، فالسبب في أغلب الأحوال أن تغييرات DNS لم تصل إلى جميع المُحلِّلات (resolvers) بعد. فإما أن سيرفرات الأسماء أو سجل A لدى مسجِّل النطاق غير صحيحة، وإما أن الإجابات القديمة ما زالت مخزنة مؤقتًا إلى أن تنتهي صلاحيتها (TTL)، وهو ما يستغرق عادةً من بضع دقائق إلى بضع ساعات، وبحد أقصى نحو 48 ساعة. يوضح لك هذا الشرح كيفية توجيه نطاق مسجَّل لدى جهة أخرى إلى استضافتك أو سيرفرك لدى Cloudesta، والتحقق من التغيير من عدة مواقع، ومعاينة موقعك قبل تفعيل DNS.
ينطبق هذا الشرح عند نقل موقع إلى Cloudesta، أو إطلاق موقع جديد، أو تغيير مزوِّد البريد الإلكتروني.
المتطلبات المسبقة
- صلاحية تسجيل الدخول إلى مسجِّل النطاق الذي اشتريت منه نطاقك (أو إلى مزوِّد DNS الحالي).
- رسالة الترحيب من Cloudesta، والتي تتضمن عنوان IP الخاص بسيرفرك، وسيرفرات الأسماء الواجب استخدامها في حسابات الاستضافة.
- طرفية (terminal) تتوفر فيها الأداة
dig. على Ubuntu 22.04/24.04 ثبِّتها باستخدامsudo apt install dnsutils. ويمكن لمستخدمي Windows استخدامnslookup.
1. كيف تعمل عملية تحليل DNS؟
عندما يكتب شخص ما example.com، يرسل جهازه استعلامًا إلى مُحلِّل تكراري (recursive resolver)، يديره عادةً مزوِّد خدمة الإنترنت أو خدمة عامة مثل 1.1.1.1 أو 8.8.8.8. فإذا لم تكن لدى المُحلِّل إجابة مخزنة مؤقتًا، فإنه يستعلم من السيرفرات الجذرية (root servers)، التي تحيله إلى السيرفرات المسؤولة عن .com. وتحيله هذه بدورها إلى سيرفرات الأسماء الخاصة بالنطاق. تحتفظ سيرفرات الأسماء بالسجلات الفعلية وتعيد الإجابة النهائية، مثل عنوان IP الخاص بسيرفر الويب لديك.
تحمل كل إجابة قيمة TTL (مدة الصلاحية) بالثواني، وتحتفظ المُحلِّلات بالإجابة في ذاكرة التخزين المؤقت طوال هذه المدة. فـ"الانتشار" ليس دفعًا للتغيير إلى الإنترنت بأكمله، بل هو الوقت اللازم لانتهاء صلاحية الإجابات القديمة المخزنة مؤقتًا حول العالم. ولذلك قد يرى مستخدمون مختلفون موقعك القديم والجديد في الوقت نفسه.
2. ما الفرق بين سيرفرات الأسماء وسجلات A وCNAME وMX؟
- سيرفرات الأسماء (NS) تُضبط لدى مسجِّل النطاق، وهي تحدد أي خدمة DNS هي المرجعية (authoritative) للنطاق بأكمله.
- سجل A يربط اسمًا بعنوان IPv4، مثل
example.com → 203.0.113.10. - سجل CNAME يجعل اسمًا ما اسمًا مستعارًا لاسم آخر، مثل
www.example.com → example.com. - سجلات MX تخبر سيرفرات البريد الأخرى بالمكان الذي يجب أن تسلِّم إليه رسائل البريد الإلكتروني الخاصة بنطاقك. أما سجلات TXT فتحتوي على قيم SPF وDKIM وقيم التحقق.
لا تسري السجلات إلا على خدمة DNS التي تشير إليها سيرفرات الأسماء الخاصة بك. وتعديل سجل A في أي مكان آخر لا يكون له أي تأثير.
3. كيف أوجِّه نطاقًا مسجَّلًا لدى جهة أخرى إلى Cloudesta؟
أمامك خياران. اختر أحدهما فقط، لا كليهما.
الخيار A: استخدام سيرفرات الأسماء الخاصة بـ Cloudesta (المعتاد في الاستضافة المشتركة)
لدى مسجِّل النطاق، استبدل سيرفرات الأسماء الحالية بتلك الواردة في رسالة الترحيب. بالنسبة إلى حسابات استضافة cPanel تكون عادةً:
dns1.madar-it.com
dns2.madar-it.com
بعد التغيير، تدير جميع السجلات من خلال cPanel » Domains » Zone Editor. انقر على Manage بجوار نطاقك.
الخيار B: الإبقاء على DNS الحالي وتعديل السجلات
هذا هو الخيار المعتاد مع VPS سحابي أو سيرفر n8n، أو عندما يدير مزوِّد آخر خدمة DNS الخاصة بك. اترك سيرفرات الأسماء كما هي، وعدِّل السجلات التالية لدى مزوِّد DNS الحالي، مستخدمًا عنوان IP الوارد في رسالة الترحيب:
Type Name Value TTL
A example.com (@) 203.0.113.10 300
CNAME www example.com 300
MX example.com (@) mail.example.com (10) 3600 # only if mail is hosted on Cloudesta
A mail 203.0.113.10 3600 # only if mail is hosted on Cloudesta
إذا كان بريدك الإلكتروني سيبقى لدى مزوِّد آخر، فلا تلمس سجلات MX الخاصة به.
4. كم يستغرق انتشار DNS؟
بالنسبة إلى تغييرات السجلات، تساوي مدة الانتظار قيمة TTL للسجل القديم. فالسجل الذي تبلغ قيمة TTL له 3600 قد يظل مخزنًا مؤقتًا لمدة تصل إلى ساعة واحدة. أما تغييرات سيرفرات الأسماء فتستغرق وقتًا أطول، لأن سجلات التفويض (delegation) لدى نطاق المستوى الأعلى (TLD) تكون قيمة TTL لها عادةً 48 ساعة. وعمليًا، تُحدِّث معظم المُحلِّلات بياناتها خلال بضع ساعات.
لتسريع عملية نقل مخطط لها، خفِّض قيمة TTL للسجلات التي ستغيِّرها إلى 300 قبل التغيير بمدة لا تقل عن قيمة TTL القديمة. أجرِ التغيير، ثم أعد رفع قيمة TTL بعد ذلك.
5. كيف أعاين موقعي قبل تغيير DNS؟
أضف سطرًا إلى ملف hosts على جهازك. يتجاوز هذا إعدادات DNS على جهازك أنت فقط.
# Linux / macOS
sudo nano /etc/hosts
# Windows (open Notepad as Administrator)
C:\Windows\System32\drivers\etc\hosts
# Add this line, then save:
203.0.113.10 example.com www.example.com
أعد تحميل الموقع في نافذة تصفح خاصة. توقَّع ظهور تحذير SSL، لأن AutoSSL أو Let's Encrypt لا يمكنهما إصدار شهادة حتى يشير DNS العام إلى السيرفر. احذف السطر عند الانتهاء، وإلا فستظل ترى السيرفر الجديد حتى لو كانت إعدادات DNS خاطئة.
التحقق من نجاح الإعداد
أولًا، تحقق من التفويض واستعلم من السيرفرات المرجعية مباشرة. فإجابتها هي ما سيراه العالم في النهاية.
dig NS example.com +short
dig @dns1.madar-it.com example.com A +short
dig +trace example.com A
بعد ذلك، قارن النتائج من المُحلِّلات العامة، فقد تظل تعيد القيم القديمة المخزنة مؤقتًا.
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 www.example.com +short
dig @8.8.8.8 example.com MX +short
# Windows
nslookup example.com 1.1.1.1
للحصول على رؤية على مستوى العالم، استخدم أداة ويب مثل dnschecker.org، إذ تعرض الإجابات من مُحلِّلات في دول عديدة. بمجرد أن تعيد السيرفرات المرجعية القيمة 203.0.113.10، يكون إعدادك صحيحًا. وأي إجابات قديمة متبقية هي بيانات مخزنة مؤقتًا ستنتهي صلاحيتها من تلقاء نفسها.
المشكلات الشائعة
توقف وصول البريد الإلكتروني بعد تغيير سيرفرات الأسماء
المنطقة الجديدة تفتقر إلى سجلات MX وTXT الخاصة بمزوِّد البريد لديك. أضفها في cPanel » Domains » Zone Editor واضبط Email Routing على Remote Mail Exchanger. ثم تحقق من النتيجة باستخدام dig @8.8.8.8 example.com MX +short.
example.com يعمل لكن www.example.com لا يعمل، أو العكس
النطاق الجذري وwww اسمان منفصلان، ويحتاج كل منهما إلى سجل خاص به. أضف سجل A للاسم @ وسجل CNAME أو A للاسم www.
مزوِّد DNS يرفض إضافة سجل CNAME على النطاق الجذري
معيار DNS لا يسمح بوجود سجل CNAME على النطاق الجذري (apex)، لأنه يتعارض مع سجلات NS وSOA وMX الموجودة هناك. استخدم سجل A يشير إلى عنوان IP الخاص بالسيرفر. كما يوفر بعض المزوِّدين سجل ALIAS/ANAME أو سجلًا من نوع flattening يعمل على النطاق الجذري.
أداة dig تعرض عنوان IP الجديد لكن المتصفح ما زال يحمِّل الموقع القديم
مزوِّد خدمة الإنترنت أو نظام التشغيل أو المتصفح لديك قد خزَّن الإجابة القديمة مؤقتًا. افحص ملف hosts بحثًا عن أسطر متبقية، ثم امسح ذاكرة التخزين المؤقت المحلية:
sudo resolvectl flush-caches # Ubuntu
ipconfig /flushdns # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # macOS
إذا ظل الموقع القديم يظهر، فجرِّب استخدام بيانات الهاتف المحمول أو اضبط المُحلِّل على 1.1.1.1. لا يمكن مسح ذاكرة التخزين المؤقت لدى مزوِّد خدمة الإنترنت من جهتك، بل تنتهي صلاحيتها عند انقضاء قيمة TTL القديمة.
فشل AutoSSL أو Let's Encrypt في إصدار شهادة
تتطلب عملية التحقق أن يشير DNS العام إلى السيرفر. انتظر حتى تعيد السيرفرات المرجعية والمُحلِّلات الرئيسية عنوان IP الجديد. ثم شغِّل cPanel » Security » SSL/TLS Status » Run AutoSSL، أو أعد تشغيل Certbot على VPS الخاص بك.
الأسئلة الشائعة
هل يمكنني تسريع انتشار DNS؟
لا يمكنك إجبار المُحلِّلات الأخرى على مسح ذاكرة التخزين المؤقت لديها. لكن يمكنك خفض قيمة TTL إلى 300 ثانية قبل أي تغيير مخطط له، بحيث تنتهي صلاحية الإجابات القديمة بسرعة.
هل أغيِّر سيرفرات الأسماء أم سجل A فقط؟
غيِّر سيرفرات الأسماء إذا كنت تريد إدارة كل شيء من cPanel. وغيِّر سجل A فقط إذا كانت خدمة DNS أو البريد الإلكتروني لديك تُدار من جهة أخرى وتريد تركها دون تغيير.
من يضبط DNS العكسي (PTR) لعنوان IP الخاص بسيرفري؟
يتحكم مالك نطاق عناوين IP في DNS العكسي، لذا لا يمكنك ضبطه من منطقة DNS الخاصة بك. افتح تذكرة دعم وستضبطه Cloudesta لعنوان IP الخاص بـ VPS أو السيرفر المخصص لديك.
هل تحتاج إلى مساعدة؟ إذا ظل نطاقك لا يعمل بعد مرور 48 ساعة، أو لم تكن متأكدًا من السجلات التي يجب إنشاؤها، فافتح تذكرة دعم عبر https://cloudesta.com/submitticket.php وأرفق اسم نطاقك ومخرجات الأمر dig NS example.com +short.