DNS الأساسي والثانوي ووقت الانتشار: لماذا يتأخّر موقعك بعد تغيير السيرفر

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

الإجابة المختصرة

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

ما هو DNS الأساسي والثانوي

كل نطاق له «ملفّ منطقة» (zone) يضمّ سجلّاته: عنوان السيرفر الذي يستضيف الموقع، وخادم الايميل، وسجلّات التحقق، وغيرها. الخادم الأساسي (primary أو master) هو الذي تُكتب عليه هذه السجلّات وتُعدَّل. الخادم الثانوي (secondary أو slave) لا يُكتب عليه شيء يدوياً، بل ينسخ الملفّ كاملاً من الأساسي بعملية تُسمّى نقل المنطقة أو AXFR، وهي معرَّفة في RFC 5936. وحين تعدّل سجلّاً على الأساسي، يرسل الأساسي إشعاراً فورياً إلى الثانوي يطلب منه تحديث نسخته، وهذه آلية NOTIFY المعرَّفة في RFC 1996.

النقطة التي يخطئ فيها كثيرون: كلمة «ثانوي» لا تعني «احتياطي يعمل عند الطوارئ فقط». الخادمان مُدرجان معاً في سجلّات NS الخاصة بنطاقك، والخوادم التي تبحث عن موقعك تسأل أيّاً منهما بلا تفضيل، وتقبل الإجابة من أيّهما. الفرق الوحيد بينهما هو مكان الكتابة: الأساسي للتعديل، والثانوي للنسخ.

وقت تشغيل DNS: لماذا يسقط الموقع والايميل معاً

حين يتوقّف DNS، يبقى السيرفر الذي يستضيف موقعك يعمل بكامل طاقته، لكن لا أحد يستطيع الوصول إليه. المتصفّح يسأل «ما عنوان هذا النطاق؟» فلا يجد من يجيب، فيعرض خطأ. وخادم الايميل عند المرسِل يسأل «أين أسلّم الرسالة الموجّهة إلى هذا النطاق؟» فلا يجد سجلّ MX، فيؤجّل الرسالة ثم يُعيدها إلى صاحبها بعد أيام. لذلك يسقط الموقع والايميل معاً وإن كان السيرفر سليماً. أمّا إن كان الخطأ يظهر على جهازك وحدك ولا يراه الآخرون، فالمشكلة غالباً في جهازك لا في النطاق، وقد شرحنا ذلك في مقال خطأ «خادم DNS لا يستجيب».

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

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

ما هو «انتشار DNS» فعلاً

لا توجد عملية «انتشار» بالمعنى الحرفي؛ لا أحد يدفع تغييرك إلى العالم. ما يحدث هو العكس: كل خادم وسيط سأل عن نطاقك قبل التغيير يحتفظ بالإجابة القديمة في ذاكرته مدّةً محدّدة، ثم يسأل من جديد. هذه المدّة هي TTL (Time To Live)، وهي حقل في كل سجلّ DNS يحدّد كم ثانية يجوز للخادم الوسيط الاحتفاظ بالإجابة، كما تعرّفها مواصفة التنفيذ في RFC 1035 ومواصفة المفاهيم في RFC 1034.

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

تغيير خوادم الأسماء أبطأ من تغيير السجلّات. سجلّات NS، أي خوادم الأسماء التي تجيب عن نطاقك، تُخزَّن أيضاً عند سجلّ الامتداد وعند المسجّل بمدد خاصّة بهم ليست تحت سيطرتك. لذلك إن بدّلت خوادم الأسماء كلّها بدل تغيير سجلّ A واحد، فستنتظر مدّة أطول من دون أن تستفيد شيئاً.

كم يستغرق الانتشار، وكيف تقصّره

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

قبل التغيير بيوم أو يومين: نخفّض TTL على السجلّات التي سنغيّرها (A وMX عادةً) إلى دقائق قليلة. التخفيض نفسه يحتاج إلى أن تنتهي القيمة القديمة الطويلة من الذاكرات قبل أن يسري، ولهذا نفعله مبكراً لا في يوم النقل.

يوم التغيير: نعدّل السجلّ إلى عنوان السيرفر الجديد. ولأنّ TTL صارت قصيرة، تنتهي الإجابات القديمة من الذاكرات خلال دقائق لا ساعات.

التحقق من أكثر من مكان: نسأل عدّة خوادم عامّة مباشرةً بأمر dig أو nslookup، مثل 8.8.8.8 و1.1.1.1، ونجرّب من شبكة الجوّال، لا من جهاز واحد على شبكة المكتب. إجابة واحدة لا تعني شيئاً؛ الإجابات المتطابقة من مصادر مختلفة هي الدليل.

مسح ذاكرة Google Public DNS: تتيح Google أداة عامّة لمسح ذاكرة نطاق معيّن من خوادمها، وتنصّ صفحتها على أنّك إن غيّرت المسجّل أو مستضيف DNS حديثاً فامسح النطاق الرئيسي أولاً ثم النطاقات الفرعية؛ راجع أداة مسح الذاكرة. هذا يسرّع الأمر لمن يستخدم خوادم Google فقط، ولا يؤثّر في ذاكرة مزوّد الإنترنت المحلّي.

بعد الاستقرار: نرفع TTL مجدّداً إلى قيمة معقولة (ساعات لا دقائق)، لأن القيم القصيرة جداً تزيد الاستفسارات على خوادم الأسماء وتجعل كل زيارة تنتظر ردّ DNS من جديد، وهذا أحد الأسباب الخفيّة التي ذكرناها في مقال لماذا موقعك بطيء.

خطوات نقل موقع بلا انقطاع

الترتيب أهمّ من السرعة. هذه الخطوات بالترتيب الذي نتّبعه عند نقل موقع عميل من سيرفر إلى آخر، سواء إلى استضافة مشتركة أو إلى سيرفر VPS خاص:

1. انسخ الموقع كاملاً إلى السيرفر الجديد مع قاعدة البيانات والملفّات وصناديق الايميل إن كان الايميل سينتقل أيضاً. لا تلمس DNS بعد.
2. اختبر الموقع على العنوان الجديد قبل أن يراه أحد. أضف سطراً في ملفّ hosts على جهازك يربط اسم النطاق بعنوان IP الجديد، فيرى جهازك وحده النسخة الجديدة بينما يرى العالم القديمة. تصفّح الصفحات، وجرّب النماذج، وسجّل الدخول إلى لوحة الإدارة، ثم احذف السطر.
3. خفّض TTL على سجلّات A وMX في لوحة DNS الحالية، وانتظر حتى تنتهي القيمة القديمة.
4. بدّل السجلّات لا خوادم الأسماء. غيّر سجلّ A إلى عنوان السيرفر الجديد، وسجلّ MX إن انتقل الايميل معه. ثم تحقّق من عدّة خوادم كما سبق.
5. أبقِ السيرفر القديم شغّالاً حتى تنتهي TTL القديمة عند الجميع، وراقب سجلّات الزيارات والايميل عليه؛ حين تتوقّف الطلبات عنه تماماً يمكنك إيقافه. من يوقف السيرفر القديم في اليوم نفسه يخسر الزوّار والرسائل التي ما زالت تُوجَّه إليه، وهو ما يحدث أيضاً حين تنتهي الاستضافة من دون تجديد.
6. ارفع TTL بعد يوم أو يومين من الاستقرار.

أخطاء نراها

تغيير خوادم الأسماء عند المسجّل بدل تغيير السجلّات. يريد العميل نقل الموقع فقط، فيذهب إلى لوحة المسجّل ويبدّل خوادم الأسماء كلّها إلى المستضيف الجديد. النتيجة: تنتقل كل السجلّات دفعة واحدة، بما فيها الايميل وسجلّات التحقق التي لم تُنسخ إلى اللوحة الجديدة، وينتظر مدّة أطول لأن تغيير NS يُخزَّن عند السجلّ الرسمي أيضاً. غيّر سجلّ A فقط إن كان الموقع وحده هو المنتقل.

نسيان MX وSPF. يُنقل الموقع ويُنسى الايميل. سجلّ MX يحدّد أين تُسلَّم الرسائل، وسجلّ SPF يحدّد من يحقّ له الإرسال باسم نطاقك؛ إن بقي أحدهما يشير إلى السيرفر القديم فستتوقّف الرسائل الواردة أو تذهب الصادرة إلى مجلّد الرسائل غير المرغوبة. شرحنا هذه السجلّات واحداً واحداً في مقال سجلّات DNS المذكور في الأعلى.

خادم أسماء واحد. نراه في النطاقات التي أُعدّت على عجل: سجلّ NS واحد يشير إلى سيرفر الموقع نفسه. أيّ إعادة تشغيل لذلك السيرفر تُسقط النطاق كاملاً، موقعاً وايميلاً. القاعدة: خادمان على الأقل، على شبكتين مختلفتين.

‎TTL بطول أسبوع. بعض اللوحات القديمة تضع 604800 ثانية، أي أسبوعاً كاملاً، قيمةً افتراضية. لا بأس بها في الأيام العادية، لكنها تعني أن أي تغيير طارئ، كنقل الموقع بعد عطل في السيرفر، سيحتاج أسبوعاً ليصل إلى الجميع. راجع قيم TTL اليوم، لا يوم الطوارئ.

الأسئلة الشائعة

كم يستغرق انتشار DNS في الإمارات؟

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

هل أحتاج DNS ثانوي إذا كان موقعي صغيراً؟

نعم، ولا علاقة للأمر بحجم الموقع. الخادم الثانوي ليس ترفاً بل الحدّ الأدنى: خادم أسماء واحد يعني أن أي عطل فيه يُسقط الموقع والايميل معاً وإن كان السيرفر سليماً. ولا تدفع مقابله شيئاً إضافياً عادةً؛ خوادم الأسماء لدينا، مثلاً، تأتي بخادمين على الأقل ضمن الخدمة نفسها.

غيّرت السيرفر والايميل توقّف، ما السبب؟

السبب الذي نراه أكثر عند عملائنا أن سجلّ MX لم يُنقل مع الموقع، أو نُقل إلى سيرفر لم تُنشأ عليه صناديق الايميل بعد. تحقّق أولاً من أن MX يشير إلى خادم الايميل الصحيح، ثم من أن SPF يذكر السيرفر الجديد، ثم من وجود الصناديق على الخادم الذي يشير إليه MX. وإن كان الايميل على خدمة خارجية فلا تلمس MX أصلاً.

هل يمكن تسريع انتشار DNS؟

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

المصادر

• [RFC 1035: Domain Names – Implementation and Specification] (اطُّلع عليه في 2026-10-11)
• [RFC 2182: Selection and Operation of Secondary DNS Servers] (اطُّلع عليه في 2026-10-11)
• [RFC 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)] (اطُّلع عليه في 2026-10-11)
• [RFC 5936: DNS Zone Transfer Protocol (AXFR)] (اطُّلع عليه في 2026-10-11)
• [Google Public DNS: Flush Cache] (اطُّلع عليه في 2026-10-11)
• [IANA: Root Servers] (اطُّلع عليه في 2026-10-11)

أين نحن

بيغ بانغ لحلول تقنية المعلومات تخطّط وتدير التقنية لشركات الإمارات منذ 2003، مقرّها في مجمّع الشارقة للبحوث والتكنولوجيا والابتكار وفرعها في الخليج التجاري بدبي. الدعم على مدار الساعة، والمكتب مفتوح من السبت إلى الخميس، 9:00–18:00 بتوقيت الإمارات. تواصل معنا أو راسلنا على واتساب.