ما هو DNS
إن DNS هو دفتر عناوين الإنترنت: يأخذ اسم نطاق مثل rgb.ir ويعيد العنوان الرقمي للخادم الذي على المتصفح أن يتصل به. والذي لا يفعله دفتر العناوين العادي أنه يخزّن الجواب في كل نقطة على الطريق، وهذا التخزين هو السبب الأول لكون تغيير السجل غير فوري.
- الدرس 4 من 12
- مبتدئ
- مجاني، دون تسجيل
مسار استعلام واحد، حين لا يكون الجواب مخزّنا
-
1
الذاكرة
المتصفح ونظام التشغيل والراوتر، لكل منها نسخته
-
2
خادم الاستعلام
الذي يسأل نيابة عنك ويحتفظ بالجواب
-
3
خادم الجذر
لا يعرف نطاقك، بل يعرف فقط ممن يُسأل عن الامتداد
-
4
خادم الامتداد
لـir، الخوادم التي تقول من يحمل أجوبة هذا النطاق
-
5
الخادم المعتمد
يعطي السجل نفسه وعمره
وعمليا لا تصل أكثر الاستعلامات إلى المحطة الثانية، لأن الجواب مخزّن سلفا. وهذا المسار الكامل هو حال المرة الأولى.
آخر مراجعة: تُراجع الحقائق وأسماء الأدوات في هذا الدرس مقابل مصادرها في هذا التاريخ.
ما الذي يفعله DNS فعلا؟
يترجم DNS الاسم إلى عنوان. تكتب rgb.ir، فيطلب المتصفح عنوانا رقميا، ويعطيه DNS. ولولا هذه الترجمة لَلَزِمَك حفظ العنوان الرقمي لكل موقع، والأهم: لما استطاع صاحب موقع أن يغيّر خادمه دون أن يضيع كل الزوار.
وتشبيه دفتر العناوين صحيح لكنه يغطي نصف الحكاية. فدفتر العناوين ليس دفترا واحدا؛ بل بنية شجرية تبدأ من الجذر وتصل إلى الامتداد ومنه إلى الخوادم التي تحمل أجوبة نطاقك. ولا مكان فيه يحفظ ملفا كاملا بكل أسماء العالم.
أما النصف الآخر فهو ما لا يقوله التشبيه أصلا: كل من على ذلك الطريق يحتفظ بالجواب مدة محددة. فمتصفحك ونظام التشغيل وراوتر البيت وخادم الاستعلام لدى المشغّل، كلهم يحملون نسخا. ولهذا فإن جواب السؤال الذي يسأله الجميع، «لماذا لم يُطبَّق تغيير DNS بعد»، لا علاقة له بصحة السجل.
ولنطرح هنا أيضا تصورا خاطئا شائعا: فـDNS يدلّ فقط ولا ينقل بيانات بنفسه. وبعد أن تحصل على العنوان يكون اتصالك مباشرا بخادم الوجهة ولا يبقى DNS على الطريق.
كيف يتحول الاسم إلى عنوان؟
في أربعة أسئلة، وفي صفر سؤال إن كان الجواب مخزّنا سلفا. فأولا ينظر خادم الاستعلام في ذاكرته. فإن لم يجد شيئا سأل أحد خوادم الجذر أي الخوادم يعرف الامتداد ir، ثم سأل تلك الخوادم من يحمل أجوبة rgb.ir، وأخيرا أخذ السجل نفسه من ذلك الخادم.
وحسنة هذا أنه قابل للقياس. فاليوم، ومن هذا الخادم، سألنا خادم استعلام عاما عن اسم جديد تماما تحت نطاقنا: استغرقت المرة الأولى ٦٦ ميلي ثانية والثانية والثالثة ٧ ميلي ثوان. وهذا الفارق هو بالضبط ما يفعله التخزين.
وتفصيل واحد يُظهر الطريق أفضل من أي شرح: بعد لحظات سألنا عن اسم جديد آخر تحت النطاق نفسه، فكانت مرته الأولى ١١ ميلي ثانية لا ٦٦. أي أن خادم الاستعلام لم يعد يحتاج أن يبدأ من الجذر؛ إنما لم يكن يتذكر جواب ذلك الاسم بعينه. فالذاكرة تمتلئ على حدة في كل درجة من هذه الشجرة.
ونتيجة نافعة: بطء فتح موقع أجنبي أول مرة ليس دائما من خادم الوجهة. فقد يكون هذه الجولات القليلة بعينها، ولأنها تقع مرة واحدة لا يظهرها اختبار ثانٍ. فإن كنت تقيس السرعة وجاءت النتيجة أفضل في المرة الثانية، فالأرجح أن هذا ما رأيت.
ما هو TTL ولماذا ليس تغيير السجل فوريا؟
TTL رقم يُرسَل مع كل سجل ويقول كم ثانية يبقى هذا الجواب صالحا. وأي خادم استعلام أخذ الجواب لن يسأل مرة أخرى حتى تنتهي تلك المدة. فحين تغيّر سجلا يكون العالم متأخرا عنك بمقدار TTL القديم، لا بمقدار ما تعرضه اللوحة.
والأرقام تُرى في زون هذا الموقع نفسه، وكانت اليوم هذه: سجل A عمره ٣٠٠ ثانية، أي خمس دقائق. وسجل MX ٣٠٠ أيضا. وسجلات NS على الخادم المعتمد ٨٦٤٠٠ ثانية، أي يوم، بينما يُعرَّف النطاق نفسه في المستوى الأعلى بعمر ٩٠٠ ثانية. وخوادم الجذر تعرّف الامتداد ir بعمر ١٧٢٨٠٠ ثانية، أي يومين.
واستخلص من هذا التفاوت نتيجة عملية: تغيير سجل A سريع وتغيير خوادم الأسماء بطيء. فإن كنت تنقل الخادم فقط فخمس دقائق؛ وإن كنت تنقل النطاق كله إلى مزوّد آخر فاحسبها ساعات.
والفخ الذي يوقع كثيرين هو التخزين السلبي. فإن لم يكن الاسم موجودا، خُزّن «غير موجود» أيضا. وعمره يحدده سجل SOA وهو لنطاقنا ١٨٠٠ ثانية، أي نصف ساعة. أي إن جرّبت نطاقا فرعيا قبل إنشائه، فلن يُعثَر عليه بعد إنشائه أيضا نصف ساعة، وهذا السلوك هو بالضبط ما عرّفه RFC 2308. والقاعدة بسيطة: لا تجرّب سجلا قبل أن تنشئه.
سلّم الأعمار على نطاقنا نحن
-
1
سجل A: ٣٠٠ ثانية
خمس دقائق. ونقل الخادم هو التغيير السريع، وهو هنا.
-
2
سجل MX: ٣٠٠ ثانية
وجهة البريد، بالعمر نفسه، خمس دقائق.
-
3
الجواب السلبي: ١٨٠٠ ثانية
نصف ساعة. جرّب نطاقا فرعيا قبل إنشائه وهذا انتظارك.
-
4
سجلات NS: ٨٦٤٠٠ ثانية
يوم واحد، عند الخادم المعتمد. وفي المستوى الأعلى يُعرَّف النطاق نفسه بـ٩٠٠ ثانية.
-
5
الامتداد ir في الجذر: ١٧٢٨٠٠ ثانية
يومان. أعلى درجة وأبطؤها، والتي ليست بيدك أبدا.
هذه الأرقام الخمسة لزون rgb.ir في ٧ سبتمبر ٢٠٢٦ وليست قيمة افتراضية لأحد. ولنطاقك أرقام أخرى؛ فانظر فيها.
لماذا يعتمد بريدك على DNS أيضا؟
لأن قرار وصول بريدك إلى صندوق الوارد أو إلى المزعج يُتَّخذ عمليا داخل هذه السجلات. ثلاثة سجلات نصية تقوم بذلك وكلها في DNS النطاق: فـSPF يقول أي الخوادم يجوز لها الإرسال باسمك، وDKIM يحمل التوقيع المعمّى، وDMARC يقول ماذا يُفعل بالبريد الذي يفشل في الاثنين.
وعلى هذا النطاق بعينه، سجل SPF عندنا هو v=spf1 +mx +a ~all، ومفتاح DKIM منشور تحت اسم default._domainkey، وسياسة DMARC عندنا مضبوطة على الحجر. ويستطيع أي أحد أن يرى هذه من الخارج لأن سجل DNS عام؛ وهو الشيء نفسه الذي يراه الخادم المستقبِل.
وهنا يخطئ التصور الذهني: يُظنّ أن عدم وصول البريد يعني مشكلة في خادم البريد. والأغلب أنها مشكلة سجل. وثمة حدّ لا يكاد يذكره أي درس ويكلّف كثيرا لاحقا: لـSPF سقف عشرة استعلامات DNS، وإن دفعتك إضافة الخدمات إلى تجاوزه بطل السجل كله. وهذا السقف حدّده RFC 7208 لا مزوّدك.
فقبل أن تضيف خدمة بريد أخرى، احسب ما يكلّفه السجل الحالي. فكسر ذلك السقف مرة واحدة يرسل بريدا كان يصل صحيحا بالأمس إلى المزعج، ولا يظهر في لوحتك أي خطأ.
ثلاثة سجلات نصية تقرر مصير البريد
يجب أن توجد
- SPF: قائمة الخوادم المسموح لها بالإرسال باسم نطاقك.
- DKIM: مفتاح التوقيع العام الذي يتحقق به المستقبِل من أصالة الرسالة.
- DMARC: سياسة التعامل مع البريد الذي يفشل في الاثنين.
هنا يقع الخلل
- تجاوز سقف عشرة استعلامات في SPF، فيبطل السجل كله.
- سجلا SPF منفصلان بدل واحد، وهذا خطأ بذاته.
- إضافة خدمة جديدة دون تحديث السجل، ثم الاستغراب من مجلد المزعج.
ووجود السجلات الثلاثة لا يضمن التسليم إلى صندوق الوارد. فمحتوى الرسالة وسجل عنوان المرسِل وسياسة كل مستقبِل لها أثر أيضا.
كيف تنظر بنفسك في سجلات نطاق؟
أبسط طريق دون تثبيت شيء هو أداة فحص DNS المجانية عندنا. فهي تستعلم لحظتها من خادمنا عن سجلات A وAAAA وCNAME وNS وMX وTXT وSOA، وتذكر سلامة SPF وDMARC على حدة. والاستعلام حقيقي ولا يُنسخ من مكان؛ وسقفه اليومي موجود كي لا يحوّل سكربتٌ خادمَنا إلى أداة مجانية له.
وإن كان لديك طرفية، فـdig في لينكس وماك يؤدي العمل نفسه بدقة أكبر، وnslookup في ويندوز نسخة أبسط منه. وثمة عادة تفصل الهاوي عن المحترف: اسأل الخادم المعتمد للنطاق نفسه لا خادم الاستعلام المحلي عندك. فالمحلي يعطيك جوابا مخزّنا والعمر المتبقي؛ والمعتمد يعطيك القيمة الحقيقية للسجل.
ورأينا هذا الفارق نفسه اليوم على نطاقنا: أعاد الخادم المحلي سجلات NS بعمر ٢١٦٠٠ ثانية وأعادها الخادم المعتمد بـ٨٦٤٠٠. ولا خطأ في أيهما؛ فالأول ما بقي من عدّ تنازلي والثاني الرقم الأصلي.
وشيء يستحق الفعل بعد كل تغيير: اسأل من أكثر من مكان. واختلاف الأجوبة ليس عطلا بالضرورة؛ فقد لا تكون الذواكر أُفرغت بعد، أو تكون الخدمة المقصودة تعطي كل سائل عنوانا أقرب إليه عمدا. ولتعرف ما النطاق أصلا ومن سجّله، يفتح مقال ما هو النطاق تلك الطبقة.
المسار السريع مع الذكاء الاصطناعي
نقل موقع دون انقطاع كان أمرا يتعلمه الناس بإفساده مرة. أما الآن فيمكن استخراج الخطة كلها من زونك الحقيقي في دقائق، بشرط أن تقدّم المخرجات الحقيقية وألا تطلب من النموذج تخمين القيم.
- خذ الزون كله بسطر واحد: for t in A AAAA MX NS TXT SOA CAA; do dig +noall +answer $t example.com; done، وضع نطاقك مكان النموذج.
- الصق تلك المخرجات كما هي وقل ما التغيير الذي تنويه: الخادم وحده أم خوادم الأسماء كذلك. ويكفي هنا صنف سريع ورخيص من النماذج؛ فالعمل حساب على بيانات جلبتها أنت.
- اطلب جدولا زمنيا لا نصيحة عامة: لكل سجل سيتغير، كم من الوقت قبله يجب خفض عمره وكم يجب الانتظار بعد ذلك.
- وقبل التنفيذ، تحقق بعينيك من قيمتين: العمر الحالي لسجل A وعمر سجلات NS. فإن كتب النموذج رقما ليس في مخرجاتك، فارمِ الجواب كله عندها.
وصفة جاهزة للنسخ
دورك مدير DNS. النص أدناه مخرجات خام لسجلات نطاق واحد، كما هي.
{الصق مخرجات dig هنا}
التغيير الذي أنويه: {سجل A وحده، أو خوادم الأسماء، أو كلاهما}
وقت التنفيذ المفضل: {الساعة واليوم}
اكتب هذه فقط:
١. العمر الحالي لكل سجل سيتغير، حرفيا من هذا النص.
٢. كم دقيقة أو ساعة قبل التنفيذ يجب أن أخفض ذلك العمر، وإلى أي قيمة.
٣. كم يجب أن أنتظر بعد التغيير حتى أطمئن أن كل خوادم الاستعلام لديها الجواب الجديد، بناء على هذه القيم نفسها.
٤. قائمة قصيرة بما يجب فحصه بعد التغيير، ومنها سجلات البريد.
قاعدة: لا تكتب رقما ليس في النص أعلاه. وإن لم تكن قيمة في النص فقل إنها لم تكن في المخرجات. ولا تعطِ نصيحة عامة؛ بل جدول هذا النطاق وحده.قبل أن تثق بالناتج: وهذه الخطة صحيحة بقدر ما تكون مخرجاتك حديثة ومأخوذة من الخادم المعتمد؛ فمخرجات الخادم المحلي تعرض العمر المتبقي، والتخطيط بها يجعلك تطمئن قبل الأوان. وليبقَ التنفيذ بيدك أيضا: لا تغيّر سجلات البريد في اليوم الذي تنقل فيه الخادم، ولا تفعل أيا منهما في ساعة يشتد فيها الزحام على الموقع.
الذكاء الاصطناعي في هذا العمل
سجل DNS نص، والنص هو ما يجيده النموذج اللغوي. الصق مخرجات dig واسأل أي سجل ناقص، ولماذا لا يمرّ SPF، وما معنى قيمة SOA هذه؛ فالأجوبة جيدة عادة. أما موقفنا في الجهة المقابلة فواضح: لا تدع النموذج يكتب سجلا تضعه أنت دون أن تفهمه. فالسجل الخاطئ في DNS يبقى خاطئا بمقدار عمره، والبريد هو الشيء الوحيد الذي يتعطل بصمت حين يتعطل.
أدوات تساعد فعلا
- Claude يعمل جيدا لقراءة مخرجات dig ومقارنة زونين ببعضهما، كأن تريد معرفة الفارق بين نطاق يصل بريده وآخر لا يصل. وإيران ليست في قائمة الدول المدعومة لدى أنثروبيك، فلا طريق رسمي للتسجيل أو الدفع.
- Gemini جيد لشرح مصطلحات DNS ورسائل أخطائه بالفارسية. وصفحة غوغل نفسها تقول إن تطبيق جيميناي يعمل في أكثر من مئتين وثلاثين دولة ومنطقة، وإيران ليست في تلك القائمة.
- Gemini Notebook والاستعمال الصحيح هنا هو هذا: أعطه صفحة مساعدة مزوّد DNS الخاص بك واسأل من داخل تلك الوثيقة، فأسماء الحقول والقيود تختلف في كل لوحة. ويعمل على حساب غوغل نفسه، وإيران ليست ضمن المناطق المتاحة.
اين ينقلب ضدك
الخطر المحدد هنا سجل حسن الهيئة وخاطئ. فالنموذج يعرف نحو SPF وDKIM وDMARC، وبالنبرة الواثقة نفسها يبني سجلا قد يتجاوز سقف العشرة استعلامات، أو يُغفل خدمة ترسل البريد فعلا، أو يضبط سياسة DMARC درجة أشد مما أنت مستعد له. وذلك السقف حدّده RFC 7208، والنموذج لا يحسبه وهو يكتب السجل. وأنثروبيك نفسها تسمّي هذا الاختراع الواثق هلوسة في وثائقها وتكتب عن تقليله. وقاعدتنا: اختبر السجل المقترح بأداة استعلام قبل وضعه، وبعد وضعه أرسل رسالة حقيقية واقرأ ترويساتها. والذي يجب ألا تلصقه أبدا في محادثة هو مفتاح API لمزوّد DNS أو مفتاح DKIM الخاص؛ وصفحة مساعدة غوغل تقول صراحة ألا تُدخل معلومات سرية. ولمعرفة شكل الدفع لكل من هذه الأدوات من إيران، انظر دليل الشراء.
المصادر: RFC 7208: SPF, the ten lookup limit Anthropic: reduce hallucinations Anthropic: supported countries Google: Gemini Apps privacy and data Google: where Gemini Apps are available
حدود هذه النصيحة
كل قيمة في هذا الدرس تخص زوننا نحن في يوم بعينه وليست قيمة افتراضية لأحد؛ فقد يكون لنطاقك سجل A بعمر ساعة، وعندها تتضاعف كل حسابات هذه الصفحة عندك. وأزمنة الاستعلام أُخذت من هذا الخادم ومن خادم استعلام عام واحد: ومن داخل إيران وعلى شبكات الهاتف تختلف الأرقام، ولا نستطيع قياسها من هنا. والأهم أن هذا الدرس عن إيجاد العنوان لا عن الوصول إليه؛ فالاسم الذي يُترجَم بصحة إلى عنوان قد لا يُفتح مع ذلك، وتلك المشكلة في موضع آخر من الطريق.
من عملنا نحن
أخذنا كل أرقام هذا الدرس في اليوم نفسه من هذا الخادم ومخرجاتها الخام في تقرير هذه الجلسة، لكن أطرف ما رأيناه لم يكن رقما. فحين سألنا عن سجل A لنطاقنا مرة من خادم الاستعلام المحلي ومرة من خادمنا المعتمد، حصلنا على مجموعتي عناوين مختلفتين. ولم تكن أي منهما معطلة: فالخدمة الجالسة أمام موقعنا تعطي كل سائل عمدا عنوانا أقرب إليه. والدرس الذي يحمله هذا للعمل اليومي أن «فحصت السجل وكان صحيحا» ليست جملة تامة حتى تقول من أين سألت، وهذا الغموض وحده هو سبب تجادل شخصين ساعات حول تغيير DNS واحد وكلاهما صادق.
اسئلة متابعة حقيقية
لماذا يُفتح الموقع لي بعد تغيير DNS ولا يُفتح لزميلي؟
لأنك وهو تسألان خادمي استعلام مختلفين، وذاكرتاهما لا تفرغان في اللحظة نفسها. فعمر السجل القديم بدأ لكل منهما في وقت مختلف. ولا شيء تفعله سوى انتظار انقضاء عمر السجل السابق؛ وإفراغ ذاكرة جهازك لا يحل مشكلته.
هل تغيير DNS جهازي إلى خادم عام يجعل الإنترنت أسرع؟
إنما يسرّع ذلك الجزء الصغير وحده لا غير. فالفارق الذي قسناه بين استعلام جديد وآخر مخزّن كان ٥٩ ميلي ثانية، ومرة واحدة لكل اسم. وبعد الحصول على العنوان تعتمد بقية سرعة الموقع على الطريق وخادم الوجهة، وهما لا يتغيران بتغيير خادم الاستعلام.
أنشأت السجل ولا يزال لا يُعثَر عليه، أين الخطأ؟
إن كنت جرّبته مرة قبل إنشائه فالأرجح ألا خطأ أصلا، وإنما هو التخزين السلبي: فجواب «غير موجود» خُزّن ويبقى حتى ينقضي عمره، وهو لنطاقنا نصف ساعة. وللتأكد، اسأل الاسم نفسه مباشرة من الخادم المعتمد للنطاق؛ فإن أجاب هناك فالسجل سليم وكل ما عليك الانتظار.