تُنشئ نطاقًا فرعيًا جديدًا. تعرض واجهة الإدارة السجل، ويستطيع زميل لك الوصول إلى الموقع، لكن حاسوبك لا يزال يُبلغ عن NXDOMAIN. هل فشل التغيير؟ ليس بالضرورة. فقد يتذكّر المحلِّل أيضًا أن اسمًا ما لم يكن موجودًا من قبل. وهذه الإجابة السلبية المخزّنة حالةٌ قائمة بذاتها.
دليل Cloudflare لاستكشاف أخطاء DNS وإصلاحها، المحدَّث في 21 أكتوبر 2026، يصف هذه الحالة بالضبط. وهذا شرح تقني حالي، وليس إطلاقًا لمنتج DNS جديد. ويستحق هذا التمييز الاهتمام لأن عدة مخازن مختلفة تمامًا تختفي تحت الكلمة اليومية «ذاكرة التخزين المؤقت»: إجابات DNS، ومحتوى المتصفح، وملفات الويب المخزّنة مؤقتًا.
قد يظل عدم الوجود السابق مخزّنًا
يبحث المحلِّل التكراري عن الاسم نيابةً عنك. وإذا سبق أن تلقّى إجابة سلبية، فيمكنه إعادة استخدامها لمدة محدودة. وإذا أُنشئ السجل في الأثناء على خادم الأسماء الموثوق، فلا يعلم المحلِّل بذلك بالضرورة في اللحظة نفسها.
لا تُقصّر قيمة TTL الجديدة لسجل A الذي أنشأته للتو هذه الحالة السلبية القائمة بأثر رجعي. ففي التخزين المؤقت السلبي، تؤدي معلومات SOA الخاصة بالمنطقة دورًا. ويصف RFC2308 القيمة الابتدائية بأنها الأصغر بين SOA TTL وSOA.MINIMUM. أما الوقت المتبقي فعليًا لإجابة مخزّنة فهو أمر مختلف أيضًا.
يستخدم مثالنا التوضيحي الخاص أرقامًا مختلَقة فقط: قد يكون إدخال سلبي صالحًا في البداية لمدة 300 ثانية. وبعد 120 ثانية، يُنشأ سجل DNS الحقيقي. وقد يظل لدى المحلِّل حينئذٍ 180 ثانية متبقية من إجابته القديمة. يوضّح هذا العلاقة الزمنية؛ وليس مدةً مقيسة لدى Cloudflare أو لنطاقك.
استعلامان للقراءة فقط يفصلان بين المصدر وذاكرة التخزين المؤقت
السؤال الأول هو: ماذا يقول خادم الأسماء الموثوق المسؤول؟ والثاني: ماذا يقول المحلِّل التكراري الذي يستخدمه جهازك فعليًا؟ يمكن للإجابات المختلفة أن تضيّق نطاق الخلل. لكنها لا تثبت تلقائيًا وجود تخزين مؤقت سلبي؛ إذ يجب أيضًا استبعاد الأخطاء الإملائية أو التفويض غير الصحيح.
dig @YOUR-AUTHORITATIVE-NAMESERVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A
dig @YOUR-RECURSIVE-RESOLVER neu.example.com A +noall +authorityاستبدل العناصر النائبة بالخوادم التي حدّدتها فعليًا. الأوامر قوالب للقراءة فقط ولم تُنفَّذ هنا. انظر إلى رمز الاستجابة والاسم ونوع السجل، وتفاصيل SOA إن وُجدت، معًا. ولن تكون إجابةٌ لمضيف ذي تهجئة مشابهة مقارنةً مناسبة.
سجّل أيضًا الوقت والمحلِّل المستخدم. وإلا فقد تقارن مسارات مختلفة دون أن تلاحظ. ولا يؤدي مسح ذاكرة DNS المؤقتة المحلية تلقائيًا إلى إزالة الإجابة المخزّنة لدى محلِّل في المنبع. ولهذا السبب تحديدًا قد لا تطال إعادة تشغيل المتصفح الحالة التي تلاحظها.
يجيب DNS وCDN عن أسئلة مختلفة
يساعد DNS على تحليل الاسم. أما ذاكرة CDN المؤقتة، فتحتفظ في المقابل بمحتوى HTTP معيّن جاهزًا. ولا يُبلغ مسح الصور أو أوراق الأنماط المخزّنة مؤقتًا محلِّلَ DNS بأن اسمًا كان مجهولًا من قبل أصبح موجودًا الآن. فالإجراء حينئذٍ ببساطة لا يتوافق مع الطبقة التي تكمن فيها المشكلة.
يصف دليل البدء الخاص بـ Cache من Cloudflare، المحدَّث آخر مرة في 12 أكتوبر 2026، الفرق أيضًا بين الوضع الممرَّر عبر الوكيل ووضع DNS فقط: فالمحتوى القادم من مضيف في وضع DNS فقط لا يمرّ عبر ذاكرة Cloudflare المؤقتة لمجرد أن DNS الخاص به مُدار هناك. ولذلك فإن وجود سجل DNS ليس دليلًا على أن المحتوى يُخزَّن مؤقتًا بشكل فعلي.
من DomainStudio إلى الإجابة الفعلية
في KENJTEC DomainStudio ai، يمكنك إدارة سجلات DNS الخاصة بك مع النوع والهدف وTTL. ويستخدم المسار المنفَّذ Cloudflare لإدارة المنطقة. وبعد أي تغيير، ينبغي أن تحكم على التحليل استنادًا إلى إجابات DNS الفعلية؛ فعبارة «محفوظ» وعبارة «مرئي بالفعل لدى كل محلِّل» تقريران مختلفان.
لذلك لا يمكن الاستعاضة عن أوقات الانتظار بوعد شامل بالنجاح. تحقّق أولًا من التهجئة، وخوادم الأسماء المسؤولة، والإجابة الموثوقة. وعندئذٍ فقط يكون وقت التخزين المؤقت المتبقي تفسيرًا مفيدًا. وهكذا تتحول عبارة «DNS يحتاج إلى وقت فحسب» إلى تشخيص يمكن تتبّعه، تنتمي فيه كل ملاحظة إلى الطبقة التقنية الصحيحة.
المصادر والحالة
البحث والتوثيق حتى 25 أكتوبر 2026. مشكلات DNS العامة · البدء مع Cache · RFC2308 — التخزين المؤقت السلبي لاستعلامات DNS.
