ما هو نظام أسماء النطاقات (DNS)؟ شرح مفاهيم خادم DNS وعناوين IP

مقدمة إلى عالم نظام أسماء النطاقات (DNS)

في عالم الإنترنت الواسع، يلعب نظام أسماء النطاقات (DNS) دورًا محوريًا لا غنى عنه. إنه بمثابة دليل الهاتف للإنترنت، حيث يترجم أسماء النطاقات سهلة التذكر، مثل freecodecamp.org، إلى عناوين IP رقمية تفهمها أجهزة الكمبيوتر. بنهاية هذا المقال، ستكون قد اكتسبت فهمًا عميقًا لما يلي:

• ما هو DNS وما هي وظيفته الأساسية.
• كيف تعمل خوادم DNS.
• آلية عمل عناوين بروتوكول الإنترنت (IP Addresses) ضمن سياق DNS.

نماذج ذهنية أساسية لفهم أعمق لـ DNS

قبل الغوص في التفاصيل المعقدة لـ DNS، من الضروري التعرف على بعض النماذج الذهنية الأساسية. ستساعدك هذه المفاهيم في بناء إطار مرجعي قوي، مما يسهل فهم المصطلحات المختلفة والاحتفاظ بالمعلومات، خاصة عندما تصبح الأمور أكثر تقنية.

الاستعلام والاستجابة (Query and Response)

هذا النموذج بسيط ومباشر: يطلب الطرف الأول شيئًا من الطرف الثاني، ويقوم الطرف الثاني بالاستجابة لهذا الطلب. تخيل الأمر كأنك تسأل سؤالاً وتتلقى إجابة.

علاقات العقد الأبناء والأصول (Parent-Child Node Relationships)

تُظهر هذه العلاقات كيفية تنظيم البيانات في هيكل هرمي، يشبه الشجرة، حيث تتفرع العقد الفرعية (الأبناء) من عقد رئيسية (الآباء). هذا المفهوم أساسي لفهم بنية مساحة أسماء النطاقات.

الرسائل (Messages)

على عكس الاستعلام والاستجابة، قد تكون الرسالة مجرد إرسال معلومات دون انتظار رد مباشر. في عالم DNS، يختلف تنسيق ومحتوى الرسائل بناءً على الاستخدام المحدد.

علاقة العميل والخادم (Client-Server Relationship)

بأبسط العبارات، الخادم (Server) هو جهاز برمجي أو مادي يوفر وظائف لأجهزة أو برامج أخرى تُسمى "العملاء" (Clients). استعد للكثير من الحديث عن الخوادم، حيث يتضمن نظام DNS العديد منها لتمكيننا من استخدام الإنترنت.

ما هو نظام أسماء النطاقات (DNS)؟

نظام أسماء النطاقات (Domain Name System)، أو DNS باختصار، هو نظام يربط أسماء النطاقات التي يسهل على البشر تذكرها (الموجودة في عناوين URL أو عناوين البريد الإلكتروني) بعناوين IP الرقمية. على سبيل المثال، يقوم DNS بترجمة وربط النطاق freecodecamp.org بعنوان IP الخاص به: 104.26.2.33. لفهم هذا التعريف بشكل كامل، سنتناول في هذا القسم:

• السياق التاريخي لتطوير DNS: ما هي المشكلات التي حلها هو وعناوين IP؟
• مفهوم أسماء النطاقات (Domain Names).
• مفهوم عناوين IP (IP Addresses).

السياق التاريخي: نشأة DNS وحل مشكلات ARPAnet

في عام 1966، أسست وكالة مشاريع الأبحاث المتقدمة (ARPA)، وهي وكالة حكومية أمريكية، شبكة حاسوبية تُعرف باسم ARPAnet. يمكن اعتبار ARPAnet التكرار الأول لما نعرفه اليوم بالإنترنت. كانت الأهداف الرئيسية لـ ARPAnet تشمل توفير اتصال موثوق حتى في حالة فشل جزئي للمعدات أو الشبكة، والقدرة على الاتصال بأنواع مختلفة من أجهزة الكمبيوتر وأنظمة التشغيل، وأن تكون جهدًا تعاونيًا لا احتكارًا لشركة واحدة. لتحقيق الموثوقية، صُممت ARPAnet بحيث لا تكون أي نقطة أو وصلة أكثر أهمية من غيرها، مع بناء مسارات احتياطية وإعادة توجيه البيانات ديناميكيًا عند فشل أي جزء من الشبكة.

المشكلات التي حلها DNS و TCP/IP

كان DNS وبروتوكول TCP/IP حاسمين في حل مشكلتين رئيسيتين واجهت ARPAnet:

1. الاعتماد على ملف HOSTS.TXT المركزي:

   • في ARPAnet، كان هناك موقع واحد (ملف يُسمى HOSTS.TXT) يحتوي على جميع تعيينات الأسماء إلى العناوين لكل مضيف على الشبكة.
   • كانت صيانة HOSTS.TXT تتم بواسطة مركز معلومات الشبكة في SRI (الذي أُطلق عليه اسم "the NIC") ويُوزع من مضيف واحد، SRI-NIC.
   • كان مسؤولو ARPAnet يرسلون تغييراتهم عبر البريد الإلكتروني إلى NIC، ويقومون دوريًا بنقل الملفات (FTP) إلى SRI-NIC للحصول على أحدث نسخة من ملف HOSTS.TXT. كانت التغييرات تُجمع في ملف HOSTS.TXT جديد مرة أو مرتين في الأسبوع.

   واجه هذا الإعداد ثلاث تحديات رئيسية:

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

   في جوهره، كان ملف HOSTS.TXT يمثل نقطة فشل واحدة، ولم يكن هذا النهج قابلًا للتوسع بعد عدد معين من المضيفين. كانت ARPAnet بحاجة إلى حل لامركزي وقابل للتوسع، وكان DNS هو هذا الحل.

2. عدم موثوقية الاتصال بين المضيفين:

   • لم يكن الاتصال بين المضيفين داخل نفس الشبكة موثوقًا بما يكفي. ساعد بروتوكول TCP/IP في حل هذه المشكلة.
   • يوفر بروتوكول التحكم في الإرسال (Transmission Control Protocol أو TCP) تدابير لضمان جودة عملية تحويل الرسائل (بين المضيفين) إلى حزم. بروتوكول TCP موجه بالاتصال، مما يعني ضرورة إنشاء اتصال بين المضيف المصدر والمضيف الوجهة.
   • يحدد بروتوكول الإنترنت (Internet Protocol أو IP) كيفية نقل الرسائل (الحزم) بين المضيف المصدر والمضيف الوجهة. عنوان IP هو معرف فريد لمسار معين يؤدي إلى مضيف على الشبكة.

   يعمل TCP و IP معًا بشكل وثيق، ولهذا السبب يُشار إليهما عادةً باسم "TCP/IP". على الرغم من أننا لن نتعمق في تفاصيلهما في هذا المقال، إلا أن كلاً من TCP وبروتوكول حزم بيانات المستخدم (User Datagram Protocol أو UDP) يُستخدمان في طبقة نقل البيانات الخاصة بـ DNS. يعتبر UDP أسرع وأقل موثوقية بكثير ولا يتطلب اتصالات؛ بينما TCP أبطأ وأكثر موثوقية بكثير ولكنه يحتاج إلى اتصالات. يُستخدم كلاهما حسب الحاجة والملاءمة في DNS؛ وغني عن القول أن تضمين TCP في ARPAnet كان إضافة قيمة لطبقة نقل البيانات.

   بحلول أوائل الثمانينيات، أصبح DNS و TCP/IP (وبالتالي عناوين IP) إجراءات تشغيل قياسية لشبكة ARPAnet. هذا التاريخ مختصر للغاية. إذا كنت ترغب في معرفة المزيد عن هذه المواضيع، يرجى الرجوع إلى قسم الموارد في نهاية هذا المقال. الآن بعد أن أصبح لدينا بعض السياق التاريخي، دعنا ننتقل إلى معرفة المزيد عن أسماء النطاقات وعناوين IP.

   أسماء النطاقات (Domain Names): الهوية الرقمية لموارد الإنترنت

   في سياق DNS، يوفر اسم النطاق طريقة سهلة الاستخدام للإشارة إلى الموارد غير المحلية. يمكن أن يكون هذا موقع ويب، نظام بريد إلكتروني، خادم طباعة، أو أي خادم آخر متاح على الإنترنت. اسم النطاق يمكن أن يكون أكثر من مجرد موقع ويب! الهدف من أسماء النطاقات هو توفير آلية لتسمية الموارد بطريقة تجعل الأسماء قابلة للاستخدام في مضيفين وشبكات وعائلات بروتوكولات وشبكات إنترنت ومؤسسات إدارية مختلفة.

   اسم النطاق أسهل بكثير في التذكر والإدخال في متصفح الإنترنت من عنوان IP. اسم النطاق هو جزء من محدد موقع الموارد الموحد (Uniform Resource Locator أو URL)، ولكن المصطلحين ليسا مترادفين. URL هو العنوان الكامل لمورد على الويب، بينما اسم النطاق هو اسم موقع الويب وهو مكون فرعي لكل URL. على الرغم من وجود فروق تقنية بين URL وأسماء النطاقات، إلا أن متصفحات الويب عادة ما تتعامل معهما بنفس الطريقة، لذلك ستصل إلى موقع الويب إذا قمت بكتابة عنوان الويب الكامل، أو مجرد اسم النطاق.

   نطاقات المستوى الأعلى (TLDs) ونطاقات المستوى الثاني (SLDs)

   يتكون أي نطاق من جزأين رئيسيين: نطاق المستوى الأعلى (Top-Level Domain أو TLD) ونطاق المستوى الثاني (Second-Level Domain أو SLD). تصبح أجزاء اسم النطاق أكثر تحديدًا عند الانتقال من اليمين (النهاية) إلى اليسار (البداية). قد يكون هذا مربكًا في البداية. على سبيل المثال، دعنا نلقي نظرة على freecodecamp.org:

   • عنوان URL: https://www.freecodecamp.org
   • اسم النطاق: freecodecamp.org
   • نطاق المستوى الأعلى (TLD): org
   • نطاق المستوى الثاني (SLD): freecodecamp

   في الأيام الأولى لـ ARPAnet، كان هناك عدد محدود من نطاقات TLD المتاحة، بما في ذلك com و edu و gov و org و arpa و mil ونطاقات رمز البلد المكونة من حرفين. كانت هذه النطاقات TLD مخصصة في البداية للمؤسسات المشاركة في ARPAnet، ولكن بعضها أصبح متاحًا لاحقًا في الأسواق التجارية. اليوم، هناك ثروة مقارنة من نطاقات TLD المتاحة، بما في ذلك net و aero و biz و coop و info و museum و name وغيرها.

   نطاقات المستوى الثاني (SLDs) هي النطاقات المتاحة للشراء الفردي من خلال مسجلي النطاقات (على سبيل المثال، Namecheap).

   عناوين IP (IP Addresses): تحديد المواقع على الشبكة

   على الرغم من أن عناوين IP مرتبطة بـ DNS في وظيفتها، إلا أن بروتوكول الإنترنت نفسه منفصل تقنيًا عن DNS. لقد قدمنا بالفعل سياقًا تاريخيًا لهذا التمييز، والآن سنشرح كيفية عمل عناوين IP.

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

   مثل اسم النطاق، يتبع تنظيم عناوين IP هيكلًا هرميًا. على عكس أسماء النطاقات، تصبح عناوين IP أكثر تحديدًا عند الانتقال من اليسار إلى اليمين. هذا مثال لـ IPv4 أدناه:

   

   يوضح هذا الرسم البياني أن 129.144 هو جزء الشبكة وأن 50.56 هو جزء المضيف في عنوان IPv4.

   • الشبكة (Network): الرقم الفريد المخصص لشبكتك.
   • المضيف (Host): يحدد المضيف (الجهاز) على الشبكة.

   إذا كانت هناك حاجة إلى تحديد أكبر، يمكن لمسؤولي الشبكة تقسيم مساحة العنوان إلى شبكات فرعية (subnet) وتفويض أرقام إضافية.

   كم عدد عناوين IP الموجودة؟

   • IPv4: كان IPv4 هو التكرار الأول لبروتوكول IP الذي استخدمته ARPAnet في الإنتاج. تم نشره في أوائل الثمانينيات، ولا يزال هو الإصدار الأكثر انتشارًا من IP. إنه مخطط 32 بت، وبالتالي يمكنه دعم ما يزيد قليلاً عن 4 مليارات عنوان. ولكن هل هذا يكفي؟ لا.
   • IPv6: يتميز IPv6 بمخطط 128 بت، مما يسمح له بدعم 340 تريليون تريليون تريليون (undecillion) عنوان. كما أنه يوفر تحسينات في الأداء مقارنة بـ IPv4.

   أمثلة:

   • مثال على عنوان IPv4: 104.26.2.33 (freeCodeCamp)
   • مثال على عنوان IPv6: 2001:db8:a0b:12f0::1 (التنسيق المضغوط ولا يشير إلى freeCodeCamp)

   كيف يعمل نظام أسماء النطاقات (DNS)؟

   لقد تعلمنا عن أسماء النطاقات! تعلمنا عن عناوين IP! الآن، كيف ترتبط هذه المفاهيم بنظام أسماء النطاقات؟ أولاً وقبل كل شيء، تتناسب جميعها ضمن مساحة الأسماء.

   مساحة أسماء النطاقات (The Domain Namespace)

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

   

   دعنا نفكك هذا، بدءًا من الأعلى.

   • الجذر (Root): الجزء العلوي من هذا الرسم البياني، المشار إليه بـ "."، يُسمى "الجذر". خوادم الأسماء الموثوقة التي تخدم منطقة جذر DNS، والمعروفة باسم "خوادم الجذر" (root servers)، هي شبكة تضم مئات الخوادم في العديد من البلدان حول العالم. وهي مُكوّنة في منطقة جذر DNS كسلطات مسماة (13 named authorities). يحتوي النطاق الجذر على تسمية بطول صفر.
   • نطاقات المستوى الأعلى (TLDs): من هنا نزولاً، تحتوي كل عقدة (نقطة) في الرسم البياني على تسمية فريدة يصل طولها إلى 63 حرفًا. المستوى الأول بعد الجذر هو نطاقات TLD: مثل com و org و edu و gov. يرجى ملاحظة أن هذا الرسم البياني لا يحتوي على قائمة كاملة من نطاقات TLD.
   • نطاقات المستوى الثاني (SLDs): أسفل نطاقات TLD توجد نطاقات SLD، وهي نطاقات المستوى الثاني.
   • النطاقات الفرعية (Subdomains): تُسمى فروع كل عقدة "نطاقات فرعية"، والتي لا تزال تُعتبر جزءًا من النطاق الأصلي. على سبيل المثال، في freecodecamp.org، يعتبر freecodecamp (SLD) نطاقًا فرعيًا لـ org (TLD). اعتمادًا على التسلسل الهرمي لموقع الويب، قد تكون هناك نطاقات من المستوى الثالث والرابع والخامس. على سبيل المثال، في hypothetical-subdomain.freecodecamp.org، يعتبر hypothetical-subdomain نطاق المستوى الثالث، وهو نطاق فرعي لـ freecodecamp. وهكذا دواليك، على الأقل حتى 127 مستوى، وهو الحد الأقصى المسموح به بواسطة DNS.

   من يدير مساحة الأسماء؟

   هل سيكون من الجنون محاولة أن يدير شخص واحد أو منظمة واحدة كل شيء؟ نعم، سيكون كذلك. خاصة وأن أحد الأهداف الرئيسية لتصميم DNS كان تعزيز الإدارة الموزعة واللامركزية للنظام ككل. أتمنى لو كان بإمكاني أن أخبركم أن المسؤولين يُطلق عليهم "ملوك مساحة الأسماء"، ولكن للأسف ليس كذلك.

   كل نطاق (أو نطاق فرعي) في مساحة أسماء النطاقات هو جزء من "منطقة" (zone)، وهي "جزء يُدار ذاتيًا من مساحة الأسماء". لذا، تُقسم مساحة الأسماء إلى مناطق. تُدار المسؤولية عن هذه المناطق من خلال التفويض والإدارة. تُسمى عملية تعيين مسؤولية النطاقات الفرعية لكيانات أخرى "التفويض" (delegation). على سبيل المثال، تدير سجل المصلحة العامة (Public Interest Registry) اسم النطاق org، ومنذ عام 2003. قد تقوم سجل المصلحة العامة بتفويض المسؤولية لأطراف أخرى لإدارة النطاقات الفرعية لـ org، مثل freecodecamp. ثم قد يقوم من يدير freecodecamp بتعيين المسؤولية عن النطاقات الفرعية لـ freecodecamp (على سبيل المثال، hypothetical-subdomain.freecodecamp.com) لطرف آخر.

   إذا كان شخص ما (منظمة أو فريق أو فرد) يدير منطقة، فإن ما يفعله هو إدارة خادم الأسماء (nameserver) المسؤول عن تلك المنطقة. هذا يقودنا إلى أحد أهم المفاهيم الأساسية في نظام أسماء النطاقات.

   خوادم أسماء النطاقات (Domain Name Servers)

   البرامج التي تخزن معلومات حول مساحة أسماء النطاقات تُسمى "خوادم الأسماء" (nameservers). في هذه المرحلة، يكون التفكير في علاقة العميل والخادم مفيدًا، على الأقل في البداية. خوادم أسماء النطاقات هي الجانب "الخادم" في علاقة العميل والخادم.

   قد تقوم خوادم الأسماء بتحميل منطقة واحدة، أو مئات، أو حتى آلاف المناطق، ولكنها لا تقوم أبدًا بتحميل مساحة الأسماء بأكملها. بمجرد أن يقوم خادم الأسماء بتحميل المنطقة بالكامل، يُقال إنه "موثوق" (authoritative) لتلك المنطقة. لفهم سبب عمل خوادم الأسماء بالطريقة التي تعمل بها، من المفيد فهم الجزء "العميل" من العلاقة.

   المحللات (Resolvers): عملاء DNS

   في DNS، يُسمى العميل (طالب المعلومات) "المحلل" (resolver)، وهو ما قد يبدو معكوسًا في البداية. ألن يُسمى الخادم الذي يحل الطلب "المحلل"؟ لقد اعتقدت ذلك أيضًا، لكنه ليس كذلك. من الأفضل حفظ ذلك والمضي قدمًا.

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

   المحللات مسؤولة عن مساعدة التطبيقات المثبتة على نظام التشغيل في ترجمة طلبات البيانات المتعلقة بـ DNS إلى استعلامات DNS. باختصار، المحللات مسؤولة عن تجميع وإرسال طلبات البيانات. بمجرد أن يتلقى المحلل الاستجابة (إن وجدت)، فإنه يمررها مرة أخرى إلى التطبيق الأصلي الطالب بتنسيق يمكن للتطبيق الطالب استهلاكه.

   العودة إلى خوادم الأسماء: عملية الحل (Resolution)

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

   أنواع الاستعلامات (Query Types)

   أنواع الاستعلامات؟ نعم، هناك أنواع متعددة من استعلامات DNS. ولكن أولاً، ما الذي يوجد عادة في استعلام DNS؟ إنه طلب للحصول على معلومات، وتحديداً لعنوان IP المرتبط باسم نطاق.

   • الاستعلام المتكرر (Recursive Query): تسمح الاستعلامات المتكررة بإحالة الاستعلام إلى عدة خوادم أسماء ليتم حلها. إذا لم يكن لدى خادم الأسماء الذي تم استعلامه أولاً البيانات المطلوبة، فإن خادم الأسماء هذا يرسل الاستعلام إلى خادم الأسماء التالي الأكثر ملاءمة، حتى يتم العثور على خادم الأسماء الذي يحتوي على ملفات البيانات المطلوبة ويرسل استجابة إلى المحلل.
   • الاستعلام التكراري (Iterative Query): تتطلب الاستعلامات التكرارية من خادم الأسماء الذي تم استعلامه أن يستجيب إما بالبيانات المطلوبة أو بخطأ. قد تحتوي الاستجابة على عنوان IP لخادم الأسماء الأكثر ملاءمة لإرسال الطلب إليه لاحقًا؛ ثم قد يرسل المحلل طلبًا آخر إلى خادم الأسماء الأكثر ملاءمة هذا.

   في حال كنت بحاجة إلى ذلك، يمكنك أيضًا الاستعلام عن اسم النطاق، إذا كان كل ما لديك هو عنوان IP. يُسمى هذا "البحث العكسي لـ DNS" (reverse DNS lookup).

   بمجرد أن يصل الاستعلام إلى خادم أسماء يحتوي على ملفات البيانات المطلوبة، يمكن حل الاستعلام. تحتوي خوادم الأسماء على عدد من ملفات البيانات المرتبطة بها، والتي قد تُستخدم كلها أو بعضها لحل الاستعلام.

   سجلات الموارد (Resource Records – RRs)

   هذه هي ملفات البيانات في مساحة أسماء النطاقات. تحتوي ملفات البيانات هذه على تنسيقات ومحتويات محددة. سجلات الموارد الأكثر شيوعًا:

   • سجل A (A Record): إذا لم تكن قد سمعت عن أي سجلات موارد أخرى باستثناء هذا، فهذا منطقي. إنه على الأرجح أشهر سجل موارد ويحتوي على عنوان IP للنطاق المعطى.
   • سجل CNAME (CNAME Record): إذا لم تكن قد سمعت عن أي سجلات موارد أخرى باستثناء هذا وسجل A، فهذا أيضًا منطقي. يشير الحرف "C" إلى "قانوني" (canonical)، ويُستخدم بدلاً من سجل A، لتعيين اسم مستعار لنطاق.
   • سجل SOA (SOA Record): يحتوي هذا السجل على معلومات إدارية حول المنطقة، بما في ذلك عنوان البريد الإلكتروني للمسؤول. تلميح: إذا كنت تدير منطقة، فتأكد من وجود عنوان بريد إلكتروني صالح هنا، حتى يتمكن الأشخاص من التواصل معك إذا لزم الأمر.

   أنواع سجلات الموارد (RR) المهمة الأخرى هي PR و NS و SRV و MX. يمكنك القراءة عنها هنا.

   التخزين المؤقت (Caching) ووقت البقاء (Time to Live – TTL)

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

   لذلك، تحتوي جميع سجلات الموارد على ما يُسمى قيمة "وقت البقاء" (Time to Live أو TTL)، والتي تحدد المدة التي يمكن خلالها تخزين تلك البيانات مؤقتًا. عندما ينتهي هذا الوقت (يصل إلى الصفر)، يحذف خادم الأسماء السجل.

   ملاحظة هامة: لا ينطبق TTL على خوادم الأسماء الموثوقة للمنطقة التي تحتوي على سجل الموارد. بل ينطبق فقط على خادم الأسماء الذي قام بتخزين سجل الموارد هذا مؤقتًا.

   يوم في حياة استعلام DNS

   لقد غطينا الكثير من المفاهيم في هذا المقال، وكانت المعلومات مكثفة. لربط كل هذا معًا وجعله واقعيًا، إليك "يوم" (مجازي) في حياة استعلام DNS.

   

   لماذا يجب أن تعرف كل هذا؟ الأهمية العملية لـ DNS

   هناك العديد من الأسباب للتعرف على مفاهيم DNS وعناوين IP. أولاً، إنه العمود الفقري للإنترنت، هذا الشيء الذي يستخدمه الكثير منا، ونطور مشاعر تجاهه (حب/كره/ما إلى ذلك)، ونعتبره أمرًا مسلمًا به كل يوم. من المهم أن تكون على دراية بالهياكل التي تمكننا من إنجاز أشياء عظيمة اليوم باستخدام التكنولوجيا والإنترنت.

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

   الخلاصة التقنية

   في هذا المقال، استكشفنا نظام أسماء النطاقات (DNS) من جذوره التاريخية إلى آليات عمله المعقدة. لقد رأينا كيف تطور DNS من نظام مركزي غير قابل للتوسع (HOSTS.TXT) إلى بنية هرمية موزعة ومرنة، مما جعله حجر الزاوية في الإنترنت الحديث. فهمنا أن DNS هو المترجم الأساسي الذي يربط بين أسماء النطاقات المألوفة وعناوين IP الرقمية، مما يسهل على المستخدمين الوصول إلى موارد الويب دون الحاجة لتذكر سلاسل الأرقام المعقدة. كما تطرقنا إلى دور خوادم الأسماء والمحللات، وأنواع الاستعلامات، وأهمية سجلات الموارد مثل A Record و CNAME Record، بالإضافة إلى مفهوم التخزين المؤقت و TTL لضمان الكفاءة والتحديث. إن إتقان هذه المفاهيم ليس مجرد معرفة نظرية، بل هو ضرورة عملية لأي متخصص تقني يتعامل مع البنية التحتية للشبكات أو تطوير الويب، حيث يوفر أساسًا متينًا لتشخيص المشكلات وتحسين الأداء.

   مصادر ومراجع إضافية

   بالنسبة لأولئك الذين ما زالوا يقرأون ويرغبون في معرفة المزيد عن DNS، أوصي أولاً وقبل كل شيء بكتاب "DNS and BIND, 5th Ed."، الذي كتبه Cricket Liu ونشرته O'Reilly Media. إنه لا يقدر بثمن. كما أشجع الجميع على البحث في طلبات التعليقات الأصلية (RFCs) المرتبطة أدناه. لا توجد نقاط فقط لقراءة المصادر الأولية، بل هي أيضًا وثائق منظمة ومفهومة بشكل استثنائي، ولهذا السبب اقتبست منها في هذا المقال.

   • RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES
   • RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
   • RFC 1122: Requirements for Internet Hosts -- Communication Layers
   • More about DNS Design Goals, from Connected: An Internet Encyclopedia
   • How the Internet was Born from the ARPAnet to the Interpret, from The Conversation
   • Learning DNS Video Course, by Cricket Liu, from O'Reilly Media