انتشار الـDNS: لماذا يستغرق التغيير وقتًا وكيف تتابعه

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

المصطلح الشائع «انتشار DNS» (DNS Propagation) مُضلِّل، ومن المفيد أن تتخلّى عنه ذهنيًّا منذ البداية. لا يوجد شيء «ينتشر» من خادم إلى خادم كما تنتشر الموجة. ما يحدث فعليًّا أبسط من ذلك وأدقّ: عند تعديل أي سجلّ DNS، يُحدَّث مصدر الحقيقة — وهو خادم الأسماء المختصّ (Authoritative Nameserver) لنطاقك — لحظيًّا. القيمة الجديدة موجودة هناك في الثانية التي ضغطت فيها «حفظ». المشكلة ليست في الوصول إلى القيمة الجديدة، بل في التخلّص من القيمة القديمة المخزّنة في آلاف المحلِّلات حول العالم.

كل محلِّل استعلم عن سجلّك قبل تعديلك احتفظ بنسخة منه في ذاكرته المؤقّتة (Cache) لمدّة محدّدة سلفًا بقيمة الـTTL. طوال هذه المدّة، سيردّ المحلِّل على أي مستخدم يسأله بالنسخة القديمة دون أن يكلّف نفسه عناء سؤال خادمك المختصّ من جديد — هذا هو هدف التخزين المؤقّت أصلًا: تقليل الضغط وتسريع الإنترنت. لذلك «الانتشار» في حقيقته هو انتظار انتهاء صلاحية الكاش عبر الشبكة، لا انتقال بيانات.

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

ولفهم الصورة الكاملة، تذكّر كيف يُحَل اسم النطاق من الأساس: متصفّحك يسأل محلِّلًا عوديًّا، وهذا المحلِّل يبدأ رحلة من خادم الجذر إلى خادم الـTLD ثم إلى خادمك المختصّ، ويخزّن النتيجة في الطريق. كل محطّة في هذه الرحلة فيها كاش، وكل كاش هو نقطة احتمالية لـ«تأخّر» تغييرك. إن أردت التعمّق في تشريح كل نوع سجلّ على حدة، راجع شرح سجلّات DNS الذي يكمّل هذا المقال.

TTL: العامل الذي يحدّد المدّة كلها

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

الفكرة الأساسية: TTL يُقرأ وقت التخزين لا وقت التغيير. حين يستعلم محلِّل عن سجلّك ويأخذ TTL قيمته 3600 ثانية (ساعة)، فإنه سيخدم تلك النسخة لمدّة ساعة كاملة من لحظة استعلامه هو، بغضّ النظر عمّا تفعله أنت لاحقًا. لو عدّلت السجلّ بعد دقيقة واحدة من استعلامه، فسيظلّ يخدم القديم 59 دقيقة أخرى. هذا يفسّر لماذا لا يوجد رقم واحد دقيق لمدّة الانتشار: كل محلِّل في مرحلة مختلفة من «عدّاده».

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

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

طبقات التخزين المؤقّت: من يحمل نسختك القديمة؟

«الكاش» ليس مكانًا واحدًا، بل سلسلة من الطبقات بين زائرك وخادمك المختصّ. كل طبقة قد تحمل نسخة قديمة بمدّة صلاحية مختلفة، وأي طبقة منها قد تكون سبب رؤيتك للقيمة القديمة بينما عدّلتها فعلًا. فهم هذه الطبقات هو نصف حلّ أي مشكلة انتشار، لأنه يخبرك أين عالقة النسخة القديمة بالضبط.

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

أهم نقطتين عمليًّا: أولًا، محلِّل مزوّد الإنترنت (ISP) هو غالبًا «المتأخّر» الأكبر، لأن بعض مزوّدي الإنترنت يتجاهلون TTL المنخفض ويفرضون حدًّا أدنى خاصًّا بهم (مثلًا لا يقلّ عن ساعة) لتقليل الحِمل — وأنت لا تتحكّم بهم. ثانيًا، المحلِّلات العامة مثل 8.8.8.8 من Google و1.1.1.1 من Cloudflare تحترم TTL بدقّة عادةً، وتوفّر صفحات «مسح كاش» علنية تتيح لك إجبارها على نسيان النسخة القديمة فورًا — وهذا مخرج عملي ممتاز.

كاش المتصفّح خاصّة

ميزة مزعجة في بعض المتصفّحات (Chrome تحديدًا) أن لها كاش DNS داخليًّا مستقلًّا عن نظام التشغيل. لذلك قد تمسح كاش الويندوز وتظلّ ترى القديم في كروم. الحلّ: افتح chrome://net-internals/#dns واضغط «Clear host cache»، أو ببساطة استخدم نافذة تصفّح خفيّة (Incognito) أو متصفّحًا مختلفًا للاختبار. الأذكى من ذلك ألّا تختبر الانتشار عبر المتصفّح أصلًا، بل عبر dig أو فاحص أونلاين كما سنوضّح.

لماذا يرى زوّار مختلفون نتائج مختلفة؟

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

العوامل التي تجعل تجربتين تختلفان في اللحظة نفسها:

الخلاصة العملية: خلال فترة الانتشار، تعدّد الإجابات أمر طبيعي ومتوقّع، وليس عطلًا. إن رأيت في فاحص عالمي أن 70% من المواقع تعطي العنوان الجديد و30% القديم، فالانتشار يسير في مساره الصحيح ولم يكتمل بعد. لا تتسرّع بالتراجع عن التغيير ظنًّا أنه فشل — فقط انتظر بقدر TTL القديم الأطول.

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

كم يستغرق الانتشار فعليًّا؟ (حسب نوع التغيير)

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

السبب أن خوادم الأسماء مسجّلة على مستوى سجلّ الـTLD (مثل .com)، وقيمة TTL لهذه الإحالة مرتفعة جدًّا عادةً (يوم إلى يومين)، ولا تتحكّم بها أنت بل مشغّل الـTLD ومسجّلك. لذلك تغيير المزوّد بالكامل (تبديل NS) يختلف جذريًّا عن تعديل سجلّ A داخل المزوّد نفسه.

نقطة دقيقة ولطيفة: إضافة سجلّ لم يكن موجودًا أسرع بكثير من تعديل سجلّ قائم. السبب أن لا أحد خزّن «إجابة قديمة» له ليتشبّث بها. الحدّ الوحيد هو ما يُسمّى التخزين المؤقّت السلبي (Negative Caching): لو سأل محلِّل عن سجلّ غير موجود فحصل على «لا يوجد» (NXDOMAIN)، فسيخزّن هذا «النفي» لمدّة محدّدة بحقل minimum في سجلّ SOA. لذلك إن أنشأت نطاقًا فرعيًّا جديدًا وزرته قبل إنشائه، قد تنتظر دقائق حتى تنتهي صلاحية «النفي» المخزّن.

كيف تسرّع الانتشار: استراتيجية خفض TTL

أهم تقنية عملية لتسريع تغيير DNS هي خفض TTL مسبقًا. الفكرة بسيطة لكن توقيتها حاسم: لا تفيدك إن خفّضت TTL لحظة التغيير، لأن المحلِّلات حول العالم ما تزال تحمل القيمة القديمة بـTTL القديم المرتفع. يجب خفض TTL قبل التغيير الفعلي بمدّة لا تقلّ عن قيمة TTL القديمة.

إليك الإجراء الكامل خطوة بخطوة، وهو ما يفعله المحترفون قبل أي نقل موقع أو ترقية خادم:

1. قبل 24–48 ساعة من التغيير: اخفض TTL للسجلّ المعني (مثلًا سجلّ A) من قيمته الحالية إلى 300 ثانية (5 دقائق). احفظ. لا تغيّر القيمة نفسها بعد، فقط TTL.
2. انتظر بقدر TTL القديم: إن كان TTL القديم 86400 (يوم)، انتظر يومًا كاملًا حتى تنتهي صلاحية كل النسخ المخزّنة بالقيمة المرتفعة وتُعاد بـ300 الجديدة.
3. نفّذ التغيير الفعلي: الآن غيّر قيمة السجلّ (العنوان الجديد مثلًا). بما أن TTL الحالي 300، سينتشر التغيير خلال 5 دقائق تقريبًا لمعظم العالم.
4. بعد التأكّد من الاستقرار: أعِد TTL إلى قيمة أعلى (3600 أو أكثر) لتقليل الاستعلامات وحمل الخوادم، بعد أن أدّى TTL المنخفض غرضه.

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

متابعة الانتشار بالأدوات

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

الفواحص العالمية أونلاين

موقعا whatsmydns.net وdnschecker.org هما الأشهر لمتابعة الانتشار العالمي، ويمكنك كذلك استخدام فاحص DNS والانتشار المجاني عندنا للتحقّق من سجلّاتك عبر عدّة محلّلات دفعة واحدة. تدخل اسم نطاقك، تختار نوع السجلّ (A، MX، NS…)، فتستعلم الأداة من عشرات خوادم DNS موزّعة على القارّات في وقت واحد، وتعرض لك خريطة: علامة خضراء لكل موقع ظهرت فيه القيمة الجديدة، وحمراء لمن ما يزال يخدم القديمة. هذه أفضل طريقة بصرية لتقدير «كم بقي» من الانتشار.

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

أوامر التحقّق العملية

أمر dig هو سكّين الجيش السويسري لتشخيص DNS. إليك أهم استخداماته لمتابعة الانتشار، مع شرح كل واحد:

# 1) العنوان الحالي فقط (سريع ونظيف)
dig example.com A +short

# 2) عرض كامل مع قيمة TTL المتبقّية (راقب العدّاد ينقص)
dig example.com A

# 3) استعلم من محلِّل عام محدّد لتجاوز كاشك المحلّي ومحلِّل ISP
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short

# 4) قارن استجابة محلِّلين مختلفين جنبًا إلى جنب لكشف التفاوت
dig @8.8.8.8 example.com A +short ; dig @1.1.1.1 example.com A +short

# 5) تتبّع المسار الكامل من خادم الجذر حتى الخادم المختصّ
dig example.com A +trace

# 6) اسأل الخادم المختصّ مباشرة (مصدر الحقيقة — يتجاوز كل كاش)
dig example.com NS +short
dig @ns1.wpressly.com example.com A +short

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

# مقارنة TTL المتبقّي عبر استدعاءات متتالية (يُظهر العدّاد ينقص)
dig @8.8.8.8 example.com A
# ... انتظر دقيقة ثم كرّر:
dig @8.8.8.8 example.com A

# فحص نوع سجلّ آخر أثناء انتشار تغيير معيّن
dig example.com MX +short
dig example.com NS
dig _dmarc.example.com TXT +short

أما nslookup فهو البديل الجاهز على ويندوز (وهو متوفّر على كل المنصّات):

# الاستعلام الأساسي
nslookup example.com

# استعلم عن نوع سجلّ محدّد
nslookup -type=MX example.com
nslookup -type=NS example.com

# استعلم من محلِّل عام لتجاوز محلِّل ISP وكاشك
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# على ويندوز: عرض كل التفاصيل
nslookup -type=A -debug example.com

ملاحظة عملية: nslookup يخفي قيمة TTL افتراضيًّا، لذا حين تحتاج رؤية الـTTL المتبقّي بدقّة فضّل dig إن كان متاحًا. على ويندوز يمكنك تثبيت أدوات BIND للحصول على dig، أو استخدام WSL.

مسح الكاش المحلّي على جهازك

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

# ويندوز (موجّه أوامر أو PowerShell كمسؤول)
ipconfig /flushdns
# للتأكّد من المسح:
ipconfig /displaydns

# macOS (الإصدارات الحديثة) — يحتاج صلاحية sudo
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# لينكس مع systemd-resolved (Ubuntu/Debian حديثة)
sudo systemd-resolve --flush-caches
# أو على الإصدارات الأحدث:
sudo resolvectl flush-caches

# لينكس مع nscd (إن كان مثبّتًا)
sudo systemctl restart nscd

# لينكس مع dnsmasq
sudo systemctl restart dnsmasq

ولا تنسَ كاش المتصفّح المستقلّ، خصوصًا Chrome:

# Chrome: افتح هذا العنوان في شريط العنوان ثم اضغط Clear host cache
chrome://net-internals/#dns

# Firefox: افتح وعطّل/فعّل التخزين عبر
about:networking#dns

نصيحة: بعد مسح الكاش المحلّي، إن أردت يقينًا تامًّا أن ما تراه هو القيمة الفعلية الحديثة، استعلم مباشرة من خادمك المختصّ بـdig @ns1.yourhost.com example.com — هذا يتجاوز كل طبقات الكاش بين جهازك والمصدر.

انتشار DNS ونقل المواقع وتغيير الاستضافة

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

السيناريو الكلاسيكي الخطر: متجر يكتب طلبًا في قاعدة بيانات الخادم القديم بينما زائر آخر يكتب في الجديد، فتتشتّت الطلبات بين قاعدتين. الحلّ الاحترافي لتفادي هذا:

1. خفّض TTL قبل النقل بيوم على الأقل كما شرحنا، ليكون الانتشار سريعًا قدر الإمكان.
2. انسخ الموقع وقاعدة البيانات للخادم الجديد وتأكّد أنه يعمل تمامًا قبل تبديل DNS (اختبره عبر تعديل ملف hosts المحلّي لتشير للخادم الجديد قبل الناس).
3. فعّل وضع الصيانة أو read-only أثناء اللحظة الحرجة إن كان موقعك يكتب بيانات (متجر/عضويات)، لمنع الكتابة المزدوجة.
4. بدّل سجلّ A للعنوان الجديد، وراقب الانتشار بـwhatsmydns حتى يخضرّ معظمه.
5. أبقِ الخادم القديم يعمل 48–72 ساعة بعد التبديل، لأن «ذيل» الزوّار على محلِّلات بطيئة سيظلّ يصله. لا تطفئه فور رؤيتك الجديد على جهازك.

إن كنت تربط دومينك باستضافة لأول مرّة (لا نقلًا)، فالتفاصيل العملية لإعداد السجلّات الأولى في ربط الدومين بالاستضافة. وإن كان «النقل» المقصود هو نقل ملكية الدومين بين المسجّلين (لا تغيير الاستضافة)، فهذه عملية مختلفة لها انتشارها الخاص على مستوى NS، اقرأها في نقل دومين بين المسجّلين.

حالة خاصّة: تغيير خوادم الأسماء (NS)

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

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

الأخطاء الشائعة في انتشار DNS

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

الخطأ القاتل: التعديل عند المسجّل الخطأ

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

# من هي خوادم الأسماء المختصّة الحقيقية للنطاق؟
dig example.com NS +short
# إن أظهرت ns1.cloudflare.com فعدّل في Cloudflare لا في المسجّل

هذا الفحص البسيط يوفّر عليك ساعات من «لماذا لا ينتشر تغييري؟» — لأنه ببساطة لم يُطبّق في المكان الصحيح أصلًا.

الخلط مع النطاقات الفرعية

خطأ آخر شائع: تنشئ نطاقًا فرعيًّا جديدًا (shop.example.com) وتتوقّعه فوريًّا، فتقلق حين «لا ينتشر». غالبًا السبب كاش سلبي إن زرته قبل إنشائه، أو نسيان أن النطاق الفرعي يحتاج سجلًّا خاصًّا به منفصلًا عن الجذر. تفاصيل بنية النطاقات الفرعية وأنواع سجلّاتها في النطاقات الفرعية.

نصائح خبير لإدارة الانتشار بثقة

بعد سنوات من نقل المواقع وتشخيص مشاكل DNS، إليك خلاصة عملية تختصر عليك المنحنى:

• خطّط لـTTL قبل أيام لا دقائق. أعظم أداة تسريع متاحة لك هي خفض TTL مسبقًا — وهي بلا قيمة إن تذكّرتها لحظة التغيير. اجعل خفض TTL أول بند في قائمة أي نقل.
• استعلم من المصدر مباشرة عند الشكّ. dig @ns1.yourhost.com example.com يتجاوز كل كاش ويخبرك بالحقيقة المطلقة في الخادم المختصّ. إن كانت القيمة صحيحة هناك، فالمشكلة كاش لا إعداد.
• افحص NS أولًا دائمًا. قبل لوم الانتشار، تأكّد أنك تعدّل في المكان الصحيح بـdig example.com NS. نصف مشاكل «عدم الانتشار» سببها التعديل في لوحة خاطئة.
• لا تطفئ القديم بسرعة. «يعمل عندي» لا يعني «وصل الجميع». أبقِ الخادم القديم حيًّا حتى يخضرّ الفاحص العالمي كاملًا، ثم أضِف هامش أمان يومًا.
• راقب TTL المتبقّي لا الساعة. الرقم بجانب السجلّ في dig يخبرك بدقّة كم بقي على محلِّل معيّن، أفضل من التخمين بالساعة.
• استخدم محلِّلًا عامًّا للاختبار. 8.8.8.8 و1.1.1.1 يحترمان TTL بدقّة وأسرع تحديثًا من كثير من محلِّلات مزوّدي الإنترنت — اعتمدهما مرجعًا للاختبار لا محلِّل شبكتك.
• خطّط للبريد بعناية. سجلّات MX تتغيّر نادرًا لكنها حسّاسة: أي بريد يصل أثناء انتشار MX قد يذهب للخادم الخطأ ويُفقد. خفّض TTL لها أيضًا قبل أي تغيير بريد.

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

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

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

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

كم يستغرق انتشار DNS عادةً؟ يعتمد على نوع التغيير وTTL السابق. تعديل سجلّ عادي (A أو CNAME أو TXT) يكتمل غالبًا خلال دقائق إلى ساعة، بحدّ أقصى يساوي TTL القديم. أما تغيير خوادم الأسماء (NS) فهو الأبطأ وقد يحتاج من ساعتين إلى 48 ساعة لأن TTL الإحالة عند سجلّ الـTLD مرتفع ولا تتحكّم به.

لماذا يرى أصدقائي العنوان الجديد وأنا لا أراه؟ لأن كلًّا منكم يمرّ عبر سلسلة كاش مختلفة بأعمار مختلفة. صديقك على محلِّل انتهت لديه صلاحية النسخة القديمة فيرى الجديد، بينما جهازك أو محلِّل مزوّد إنترنتك ما يزال يحمل القديمة. امسح كاش جهازك بـipconfig /flushdns ونظائره، أو استعلم من محلِّل عام بـdig @8.8.8.8 example.com.

كيف أسرّع انتشار DNS؟ أفضل طريقة هي خفض TTL للسجلّ المعني إلى 300 ثانية قبل التغيير الفعلي بـ24–48 ساعة، فتنتهي النسخ القديمة المرتفعة وتُعاد بقيمة منخفضة. بعدها ينتشر تغييرك الفعلي خلال دقائق. التخفيض لحظة التغيير لا يفيد لأن المحلِّلات ما تزال تحمل القيمة بـTTL القديم المرتفع.

كيف أتابع انتشار DNS؟ استخدم فاحصًا عالميًّا مثل whatsmydns.net أو dnschecker.org يستعلم من عشرات المواقع حول العالم ويعرض خريطة خضراء/حمراء، وكمّل بأوامر dig example.com A +short وnslookup. تجنّب الحكم بفتح الموقع على جهازك لأنه قد يخدم نسخة محلّية مخزّنة لا تعكس الواقع العالمي.

ما علاقة TTL بانتشار DNS؟ TTL هو العامل الحاسم: يحدّد كم تحتفظ المحلِّلات بنسخة السجلّ قبل أن تسأل من جديد. كلما قلّ TTL أسرع ظهور التغييرات لكن زادت الاستعلامات، وكلما ارتفع قلّ الحمل لكن بطؤ الانتشار. القيمة الشائعة 3600 (ساعة)، وتُخفَّض مؤقّتًا إلى 300 قبل أي تغيير مخطّط ثم تُعاد.

هل مسح كاش DNS على جهازي يسرّع الانتشار للجميع؟ لا. مسح الكاش المحلّي يؤثّر على جهازك أنت فقط فيجعلك ترى القيمة الجديدة فورًا إن كانت منتشرة عند مصدرك. لا علاقة له ببقيّة العالم؛ كل جهاز ومحلِّل يحدّث وفق عدّاد TTL الخاصّ به. الأمر المناسب على ويندوز ipconfig /flushdns، وعلى ماك sudo dscacheutil -flushcache.

لماذا لا يظهر تغييري إطلاقًا حتى بعد يوم كامل؟ السبب الأشيع أنك عدّلت في المكان الخطأ: لوحة مسجّل لا تدير DNS فعليًّا بينما النطاق يستخدم خوادم أسماء مزوّد آخر. افحص بـdig example.com NS +short لمعرفة من يدير DNS حقًّا وعدّل هناك. سبب آخر محتمل أن المنطقة لم تُحفظ/تُنشر (لم يتغيّر Serial في SOA).

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

لماذا تغيير خوادم الأسماء (NS) أبطأ من تغيير سجلّ عادي؟ لأن خوادم الأسماء مسجّلة على مستوى سجلّ الـTLD (مثل .com) بقيمة TTL مرتفعة جدًّا (يوم إلى يومين) لا تتحكّم بها أنت بل مشغّل الـTLD. لذلك تبديل المزوّد بالكامل قد يحتاج حتى 48 ساعة. لتقليل أثره، انسخ كل سجلّاتك القديمة إلى المزوّد الجديد قبل تبديل NS فلا ينقطع شيء أيًّا كان من يجيب الزائر.

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