الإقليم ٠ — الطلب الذي يصل: من اسمٍ إلى خادم

النبذة

في منهج الشبكات أنهيتَ رحلةً عند بابٍ مغلق: عرفتَ أن /etc/hosts هو أبسط مترجمٍ من اسمٍ إلى IP، وأن العالم لا يمكن أن يعتمد على ملفٍ في كل جهاز، فوُلد DNS — وتركناه هناك بذرةً. الآن أنت في الجهة الأخرى من الباب: تملك خادماً حقيقياً على 8.8.8.8، وتريد أن يصل إليه كل من يكتب www.foobar.com في متصفّحه. هذا الإقليم يفتح البذرة: كيف يصير الاسم عنواناً، ومن يملك الإجابة، وما نوع الإجابة.

الدرس

ليش نحتاج DNS أصلاً — الدافع الذي تركناه في منهج الشبكات

أنت تعرف من قبل: البشر يحفظون أسماءً، والآلات تسيّر حِزماً إلى أرقام (IP). و /etc/hosts يحلّ هذا لكنه لا يتوسّع: مَن يحدّث الملف على ملياري جهازٍ كلما تغيّر IP موقع؟ المشكلة الحقيقية ليست «الترجمة» — أنت تعرف الترجمة. المشكلة هي التفويض (delegation) واللامركزية: لا أحد يملك القائمة كاملة، ولا يجب أن يملكها. DNS هو الحلّ: شجرةٌ موزَّعة، كل جزءٍ منها يملكه من يملك ذلك الجزء.

ابنِها بنفسك ذهنياً. لو طُلب منك تصميم نظام أسماءٍ للعالم كله بلا ملفٍ مركزي، ستُجبَر على هذه القرارات بالضبط:

• اقسِم الاسم إلى مستويات تُقرأ من اليمين: www.foobar.com ⟵ الجذر . ثم نطاق المستوى الأعلى com ثم foobar ثم www. كل مستوى يفوّض المستوى الذي تحته لمن يملكه.
• اجعل لكل نطاقٍ خوادمَ موثوقة (authoritative) تملك الحقيقة عن أسمائه.
• اجعل أحداً يسأل نيابةً عن المستخدم ويتذكّر الجواب مؤقتاً — هذا الـ resolver (غالباً عند مزوّد الإنترنت)، والتذكّر المؤقت هو الـ caching بمهلة TTL.

هذا بالضبط ما فعله DNS الحقيقي. لاحظ: لم تحفظ شيئاً — اشتققتَه من قيد «بلا مركز». لن نغوص أعمق في آلية الاستعلام الكامل (recursive vs iterative، الجذر، الـ TLD servers) — ذلك تفصيلٌ يفتحه الإقليم ٨ حين نتتبّع google.com خطوةً خطوة. هنا يكفيك: النطاق له منطقة (zone) فيها سجلّات (records)، وكلٌّ منها من نوعٍ يحدّد معناه.

ليش «أنواع» للسجلّات — وما الفرق الذي يصطادك في اللغز

السجلّ في DNS سطرٌ يقول: «هذا الاسم، من هذا النوع، يساوي هذه القيمة». النوع ليس زينة — هو ما تعنيه القيمة. أهمّ الأنواع التي يجب أن تشتقّ منطقها:

المفتاح في اللغز هو الفرق بين سطرين فقط:

• A يشير إلى عنوان IP. قيمته رقمٌ.
• CNAME يشير إلى اسمٍ آخر. قيمته اسمٌ، لا رقم — ثم يُعاد حلّ ذلك الاسم.

الآن أعد قراءة المشروع: «سجلّ www يشير إلى IP خادمك 8.8.8.8». القيمة رقم IP. وما النوع الوحيد الذي قيمته رقم IPv4؟ A. إذاً www هنا سجلّ A، لا CNAME. من أجاب CNAME وقع في عادةٍ شائعة: في مواقع الإنتاج كثيراً ما يكون www سجلّ CNAME يشير إلى النطاق الجذر أو إلى موزِّعٍ خارجي — لكن في هذا المشروع القيمة المعطاة رقم IP، وهذا يحسم النوع. النوع يُحدَّد بالقيمة، لا بالاسم www. هذا هو الدرس.

ليش «خادم» ليست صندوقاً — تعريفٌ يربك ثم يُوضّح

سؤالٌ آخر يطرحه المشروع: «ما هو الـ server؟» الفخّ أن تشير إلى صندوقٍ معدني. لكن الـ server ليس الحديد. الخادم برنامجٌ (أو جهازٌ) يقدّم خدمةً عبر الشبكة استجابةً لطلبات عملاء (clients). الكلمة تصف دوراً، لا شكلاً. نفس الصندوق قد يحمل عدّة خوادم (web server, database server) في آنٍ واحد — وهذا بالضبط حال Task 0: خادمٌ واحدٌ (صندوق) يشغّل عدّة خوادم (أدوار). احفظ هذا التمييز؛ سيصير محورياً في الإقليم ١ حين نفكّك الأدوار داخل الصندوق الواحد.

ليش يصل الطلب أصلاً: ما الذي «يتكلّم» به الخادم مع المستخدم

المشروع يسأل: «ما الذي يستخدمه الخادم للتواصل مع جهاز المستخدم؟» أنت تملك الجواب من منهج الشبكات تقريباً كاملاً: المتصفّح يفتح TCP (المصافحة الثلاثية التي بنيتَها) إلى IP الخادم على port معيّن (٨٠ أو ٤٤٣ — منافذ معروفة درستَها)، ثم يتحدّثان فوق هذا الاتصال بلغةٍ من طبقة التطبيق اسمها HTTP (وHTTPS حين يكون مشفّراً — إقليم ٥). إذاً الجواب الدقيق: HTTP/HTTPS فوق TCP/IP. لاحظ كيف أن كل اللبنات تحت HTTP مبنيّةٌ سلفاً — لم نعد اشتقاق TCP، استعملناه. هذا هو معنى البناء فوق منهجٍ سابق.

الخلاصة — وصلٌ في الشجرة

• فتحتَ بذرة DNS المتروكة في منهج الشبكات: النطاق منطقةٌ فيها سجلّات، والنوع يحدّد معنى القيمة.
• ميّزتَ A (⟵ IP) من CNAME (⟵ اسم)، وحسمتَ لغز المشروع: www المشير إلى رقم IP هو سجلّ A.
• ثبّتّ أن الخادم دورٌ لا صندوق — عقدةٌ ستتفرّع كثيراً في الإقليم التالي.
• ربطتَ كل ذلك بما بنيتَه سابقاً: الطلب يصل عبر HTTP فوق TCP/IP، بلا إعادة اشتقاق.

البذرة المتروكة هنا: الآن صار IP بيد المستخدم، وفُتح الاتصال، ووصل الطلب إلى الصندوق على 8.8.8.8. لكن ماذا يوجد داخل ذلك الصندوق؟ كيف يتحوّل «GET /» الواصل إلى صفحةٍ فيها بياناتٌ من قاعدة بيانات؟ ولماذا لا يكفي برنامجٌ واحد؟ هذا هو الإقليم ١.