مخدم أسماء

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

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

 التاريخ

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

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

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

في عام 1983 وضع پول ماكاپتريس توصيفاً نظرياً لخدمة أسماء النطاقات في الوثيقة RFC 882 والوثيقة RFC 883، وتم تعديل التوصيف في عام 1987 بالوثيقتين RFC 1034 و RFC 1035، كما قام باول بالتحقيق البرمجي لنسخة نظام أسماء النطاقات، ولكن النسخة لم تكن تخص نظام يونكس.

جرى تنفيذ نظام أسماء النطاقات تحت نظام يونكس عام 1984 من قبل أربعة طلاب كانوا يحضرون لشهادة الدكتوراه في جامعة بيركلي. وجرت إضافته إلى نظام BSD من قبل رالف كامبل. وفي عام 1985 نفذ أحد مهندسي شركة دي إي سي نسخة BIND) Berkeley Internet Name Domain System) التي أُضيفت إلى معظم منظومات يونكس ولينوكس. كما نفذت شركة نورتل نسخة منظومة بيركلي لنطاق الأسماء من الإنترنت BIND على ويندوز في عام 1985، وسميت نسخة نظام BIND باسك لأسماء النطاقات لا تخص يونيكس وتتميز بتوافقها الكامل مع أنظمة BIND بفضل تقييس الپروتوكول DNS.

 نظام أسماء النطاقات

•  مقالة مفصلة: نظام أسماء النطاقات

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

يمتلك كل كيان إداري - عبر مُخدِّماتِه - القدرة على الرد على طلبات الترجمة (ترجمة الأسماء إلى عناوين)، إما مباشرةً بوساطة جداول تحتوي على العنوان المقابل للاسم المطلوب ترجمته (محفوظة ضمن مُخدِّماته)؛ وإما اعتماداً على كيانات أخرى أعلى منه أو أدنى منه أو مكافئة له بالهرمية. لذا يحتاج الكيان الإداري الذي يدير مجموعة نطاقات إلى معرفة دقيقة بمخدمات كيانات إدارية أخرى يمكن له أن يعتمد عليها في حال لم يستطع حل اسم نطاق. ومن ثم، فإن العلاقة الهرمية للكيانات الإدارية (ومُخدِّماتها) تسهِّل من عملية حلّ الأسماء، إذ يمكن لكل كيان أن يعتمد على الكيان الأدنى منه أو الأعلى منه أو المكافئ له هرمياً لحل اسم ما. فالكيان الذي يدير النطاق (.com) سيحتاج إلى الكيان الأدنى منه هرمياً، والذي يدير النطاق (yahoo.com) لحلّ الاسم (www.yahoo.com). أما الكيان الإداري الذي يدير النطاق (yahoo.com) والذي يمتلك رسالة موجهة إلى (host.mail.sy) فسيحتاج إلى الكيان الإداري الأعلى منه هرمياً والذي يدير النطاق (.com)، والذي سيحتاج إلى الكيان الإداري المكافئ له والذي يدير النطاق (.sy) والذي سيحتاج إلى الكيان الإداري الأدنى منه هرمياً والذي يدير النطاق (mail.sy) للوصول إلى (host.mail.sy).

يدعى جذر شجرة الأسماء بالنقطة أو «.». يتوضع هذا الجذر في مستوى النطاقات الأعلى (مستوى الجذر أو root-level). وقد جرى تثبيت نطاقات المستوى الأعلى تاريخياً مثل com و edu وغيرها. إلا أن ICANN (وهي مجلس الإنترنت المؤهل لإسناد العناوين والأسماء) وافقت على إدخال سبعة نطاقات جديدة في عام 2001، وهي: biz، info، name، museum، aero، coop.

يُستخدم نمطان من أسماء النطاقات الخاصة بالمستوى الأعلى حالياً. ففي الولايات المتحدة، تُعبِّر نطاقات المستوى الأعلى عن بنى تنظيمية وسياسية سميت بأسماء مؤلفة من ثلاثة أحرف مثل com Ëedu. وتُستخدم بعض هذه النطاقات (مثل com، و org، وnet) خارج الولايات المتحدة الأمريكية أيضاً، وتدعى هذه النطاقات نطاقات المستوى الأعلى العمومية GTLDs) Generic Top-Level Domains). أما في بقية أنحاء العالم فيُستخدم رمز مؤلف من حرفين، ويدل على البلد. تتعايش أسماء نطاقات المستويات العليا الجغرافية والتنظيمية سوياً ضمن الفضاء العام للأسماء نفسه.

تكون أسماء النطاقات غير حساسة لشكل الأحرف (كبيرة أو صغيرة) فاسم «MICROSOFT» مطابق لاسم «microsoft» ولاسم «Microsoft» في نظام DNS. إذ يقوم نظام DNS بإهمال الفرق بين الحروف الكبيرة والصغيرة إلا أنه يقوم بنشرها على حالها في حال وجودها.

يتشكل اسم كامل ومؤهل خاص بمضيف Fully Qualified Host Name من اسم النطاق مدموجاً مع اسم المضيف الأصلي. فعلى سبيل المثال، يكون www.w3c.org اسماً كاملاً مؤهلاً للمضيف www في النطاق w3c الذي ينتمي إلى النطاق (org). يمكن لمواقع أخرى أن تستخدم اسم المضيف www من دون تعارض مع الاسم السابق وذلك لاختلاف الاسمين الكاملين المؤهلين، فعلى سبيل المثال، يعبّر www.w3c.org عن عنوان IP مختلف عن العنوان www.cert.org على الرغم من تشابه النطاق الأول مع النطاق الأخير من الاسمين، ولكن اختلاف الاسمين الكاملين المؤهلين يجعل الاسمين مختلفين.

 إدارة النطاقات

جرت سابقاً عملية إدارة مُخدِّمات نطاقات المستوى الأعلى org و com و edu و net من قبل حلول الشبكة network solutions بتوكيل من مؤسسة العلوم الوطنية National Science Foundation. بيد أن هذا الحل الاحتكاري قد تغير اليوم وجرى السماح لمنظمات أخرى بتسجيل أسماء نطاقات في المستوى GTLDs. أما نطاقات المستويات العليا الأخرى مثل النطاقات الخاصة بالبلدان، فتدار من قبل منظمات محلية. ويوفر مزودو خدمة الإنترنت خدمة مباشرة لتسجيل الأسماء. ويتعامل مزودو الخدمة مع سلطة إدارة النطاق الأعلى على نحوٍ شفاف مع المستخدم.

 كيفية اختيار اسم نطاق

يعدّ بعض الأسماء ممنوعاً كحال الأسماء المُسجلة أسماءً مملوكة. ويُنصَح عادةً باستخدام أسماء قصيرة سهلة الإدخال وبألا تكون الأسماء أطول من 12 حرفاً مع أن خدمة DNS تسمح اليوم باستخدام أسماء بطول يراوح بين 36 ـ255 حرفاً لكل مكون من مكونات الاسم الكامل.

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

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

ـ اختيار اسم وحيد ضمن النطاق المحلي.

ـ تعريف مُضيف أو أكثر لتخديم النطاق الجديد.

ـ التنسيق مع مدير النطاق الأعلى.

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

 خدمة حل أسماء النطاقات

يعدّ كل مضيف زبوناً DNS أو زبوناً ومخدماً بآن واحد. وتكون جميع مخدمات الأسماء على علم بالمخدمات الرئيسية. كما تمتلك المخدمات الرئيسية ما يكفي من المعلومات عن النطاقات ذات المستويات العليا، مثل: com و eduوorg وfr وde وغيرها، إذ يكون النطاق org على معرفة كاملة بالنطاق w3c.org، ويكون com على معرفة تامة بالنطاق admin.com وهكذا دواليك، حيث يمكن لكل منطقة أن تقوم بتوكيل السلطة على نطاقاتها الفرعية لمخدمات أخرى.

لنفترض أننا نريد البحث عن عنوان الجهاز mail.w3c.org بدءاً من الجهاز host1.mydomain.com. يتوجه الجهاز host1 بالسؤال إلى مخدم الأسماء المحلي، وهو ns.mydomain.org للبحث عن جواب. لا يمتلك مخدم الأسماء المحلي أيّ معلومات عن العنوان، كما لا يمتلك أيّ معلومات عن mail.w3c.org أو عن w3c.org أو حتى عن org، إلا أنه يعلم بوجود عدة مخدمات خاصة بإدارة النطاق الرئيسي (org). بالنتيجة، يقوم بالاستعلام من المخدم الرئيسي الخاص بالنطاق (org) عن mail.w3c.org.

يمتلك النطاق org مخدماته الخاصة التي تبحث عن مُخدِّمات مسجلة وقادرة على أن تجيب عن التساؤل الخاص بترجمة العنوان mail.w3c.org. ومن ثم يمكن الحصول على عنوان المُخدِّم الخاص بالنطاق w3c.org. أما المخدم الخاص بالنطاق w3c.org، فيكون مخدماً رسمياً للمعلومات المطلوبة يمتلك الجداول التي تترجم الاسم mail التابع للنطاق w3c.org إلى عنوان. ويقوم هذا المُخدِّم بإعادة العنوان المطلوب؛ حين رجوع العنوان يُخزِّن ns.mydomain.com لديه لائحة المُخدِّمات الخاصة بالنطاقات org و w3c.org.

 انظر أيضاً

• BIND
• مقارنة برامج مخدم الأسماء
• Directory service
• DNS Security Extensions (DNSSEC)
• Lightweight Directory Access Protocol (LDAP)
• Network Information Service (NIS)
• Name Service Switch (NSS)
• resolver, resolv.conf, resolvconf for Unix/Linux
• OpenNIC
• DNS Advantage
• OpenDNS
• Google Public DNS
• Open Root Server Network
• RealNames

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

 وصلات خارجية

• DNS & BIND Resources
• Website DNS Lookup
• The benefits of changing DNS servers