سنتعرف في هذا الفيديو على أحد أهم عناصر الشبكات، و أحد أكثر المفاهيم التي نتعامل معها بشكل يومي أثناء تصفحنا لمواقع الويب الموجودة عبر الانترنت وهو Domain Name System نظام تسمية النطاقات أو ما يعرف اختصارًا بالـ DNS. فما هو DNS؟ وما هي أهميته؟ وكيف يعمل؟  تعرف معنا على إجابات هذه الاسئلة خلال هذا الفيديو.

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

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

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

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

العلامة التجارية

تعد العلامة التجارية مفهوما مهما جدًا بالنسبة للأعمال. يوجد لكل شركة علامة تجارية، تمثل اسمها وشعارها ومخطط ألوانها وهويتها البصرية. ومع ذلك، لا نجد أن كل العلامات التجارية معروفة. وهذا هو الفرق في الوعي بالعلامة التجارية.

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

إنه الفرق بين كوكا كولا وشركة كولا بلا اسم. أو الفرق بين منتج شركة Apple ومنتج شركة غير معروف اسمها.

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

الامتدادات (Extensions)

إن أكثر الامتدادات استخدامًا في العالم هي الامتدادات الثلاثة التالية com. و net. و org.. يبدو اسم النطاق مع واحدة من هذه الامتدادات مثاليًا لأي نوع من الأعمال. فاستخدام أحد الامتدادات المجانية مثل TK. قد لا يكون ناجحًا جدًا.

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

وكما قلت للتو أن هذه الامتدادات ذات شعبية كبيرة، لذا يتوقع الزوار أن تستخدم الشركات هذه الامتدادات الثلاثة فقط.

يقدم بعض مقدمي خدمات حجز النطاقات عروضًا لمن يشتري الامتدادات الثلاثة سيحصل على خصم. لذا فإن حصولك على الامتدادات الثلاثة سيكون مفيد جدًا لك في المستقبل - تعدّ هذه الخطوة ذكية جدًا وستضعك في موضع الصدارة.

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

بالتأكيد أن لا أقول أنه يجب عليك أن تملك واحدًا منهم. الشريك المؤسس لووردبريس Matt Mullenweg لديه واحد من أروع أسماء النطاقات ألا وهو www.ma.Tt. نعم، لديه امتداد غريب إلا أنه يتوافق مع إسمه بشكل مثالي.

إذا تمكنت من العثور على شيء ذكي مثل هذا الامتداد، فاحصل عليه مباشرة، ولكن فكر في حقيقة أن الأشخاص الذين لا يعرفون الكثير عن الويب لا يعرفون عن وجود شيء آخر غير امتدادات com. و net. و org..

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

الموقع

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

إذا كان لديك شركة دانماركية تستهدف الدنماركيين فقط، فإن وجود موقع ويب ينتهي في com. لن يكون له داعٍ لأننا نستطيع الحصول على امتداد سهل التمييز مثل dk.. جميع البلدان لديها امتدادات نطاق (Top-level Domain). وبالتأكيد dk. ليس هو الخيار الوحيد المتوفر.

يُستخدم رمز البلد TLD في أغلب الأحيان للشركات والأفراد في البلد المَعني. ويكيبيديا لديها قائمة طويلة وكاملة من TLDS في جميع أنحاء العالم.

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

وهو أيضا خيار للشركات التي تستهدف الدول التي لا تستخدم الأبجدية الإنجليزية، مثل الدول الآسيوية، أو العربية، أو روسيا. وتسمى IDNs (أسماء النطاقات الدولية Internationalized Domain Names) ويجب أن تستخدمها فقط لاستكمال عنوان com. (أو أي TLD آخر) وإلا فإنه سيكون مربكًا للزائرين الذين لغتهم الرئيسية الإنجليزية أو أحد الأبجديات المستخدمة في أوروبا أو أمريكا.

خدع وحِيَل

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

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

قبل الشراء

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

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

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

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

خدمات Whois

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

بدلاً من أن تملئ الحقول بالمعلومات الخاصة بك يجب عليك أن تملئ الحقول بالمعلومات الخاصة بالمزود الذي اشتريت من عنده. ولكن لماذا يعدّ هذا الشيء خطير؟ لأنه وفقًا لسياسات ICANN ، يكون الاسم في تفاصيل WHOIS للذي يملك النطاق (في هذه الحالة اسم الشركة الّتي اشتريت منها النطاق).

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

الخاتمة

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

ضع في حساباتك أن نطاقات المستوى الأعلى (Top-level domains) يمكن أن تساعدك في تصدر نتائج محرك البحث. وذلك لأنه يتم فهرسة ‎.com دومًا بشكل أسرع وأفضل من ‎.ru. إن قضاء الوقت في التفكير في كل التفاصيل والعثور على اسم النطاق الصحيح هو أمر سيستغرق الكثير من الوقت.

ترجمة -وبتصرف- للمقال Essential Tips for Registering a New Domain Name

مقدّمة

تتوفّر الأداة Dig على توزيعات لينكس للاستعلام من خواديم أسماء النطاقات DNS. تساعد هذه الأداة كثيرا في تشخيص مشاكل النطاقات، كما أنها مناسبة للتأكد من أن إعدادات الشبكة تعمل على النحو المتوقّع.

نقدّم في هذا المقال طريقة استخدام الأمر dig للتحقّق من إعدادات أسماء النطاقات والحصول على معلومات عن كيفيّة ظهور نطاقك على شبكة الإنترنت. سنرى خلال هذا الدرس كذلك أدوات مصاحبة تكمّل عمل Dig.

نفّذنا الأوامر المعروضة في هذا المقال على الإصدار 16.04 من أوبنتو، إلا أنه من المُفترَض أن تعمل بطريقة مماثلة على أغلب توزيعات لينكس الحديثة.

كيف يُستخدم الأمر dig

أسهل طريقة لاستخدام الأمر dig هي تمرير اسم النطاق الذي نريد الاستعلام عنه إلى الأمر:

dig example.com

نختبر - مثلا - محرّك البحث DuckDuckGo لنرى المعلومات التي سنحصُل عليها عنه:

dig duckduckgo.com

النتيجة:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64718
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;duckduckgo.com.                        IN      A

;; ANSWER SECTION:
duckduckgo.com.         176     IN      A       50.18.192.251
duckduckgo.com.         176     IN      A       50.18.192.250

;; Query time: 270 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Apr 20 13:28:31 GMT 2017
;; MSG SIZE  rcvd: 75

توجد الكثير من المعلومات في النتيجة أعلاه، فلنفحصها الواحدة تلو الأخرى.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> duckduckgo.com
;; global options: +cmd

تمثّل الأسطر أعلاه ترويسة Header الاستعلام المُرسَل. يمكن تنفيذ الأمر dig على وضع الدُّفعات Batch mode، لذا من الجيّد أن تظهر الترويسات المناسبة لكلّ وضع من أجل تسهيل تحليل النتائج وقراءتها.

تأتي بعد ذلك الأسطُر التالية.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64718
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

يُقدّم هذا المقطع ملخصًّا تقنيًّا لنتائج الاستعلام. يظهر أن الاستعلام نُفِّذ بنجاح (status: NOERROR، أي “الحالة: لا أخطاء”)، أن الأمر استخدم الخيارات qr rd raوأننا حصلنا على إجابتيْن ANSWER: 2، ومقطع معلومات إضافيّ واحد ADDITIONAL: 1.

يظهر بعدها المقطع الإضافيّ الذي يحوي سجلّا من نوع OPT يشير إلى أن الخادوم يدعم معيار EDNS المطلوب لتطبيق إجراءات أمنيّة مثل DNSSEC.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000

ثم يأتي دور الإجابة الفعليّة التي تُظهر البيانات التي حصلنا عليها من الاستعلام.

;; QUESTION SECTION:
;duckduckgo.com.                        IN      A

;; ANSWER SECTION:
duckduckgo.com.         176     IN      A       50.18.192.251
duckduckgo.com.         176     IN      A       50.18.192.250

يعيد المقطع الموالي ذكر الطلب الذي أرسلناه إليه (QUESTION SECTION) ويطبع بعدها سجلّات DNS الموافقة له.

يُرجع الأمر dig مبدئيّا السجلات من النوع A. تُظهر النتيجة أعلاه أن لـduckduckgo.com سجليْن من هذا النوع، يحويان عناوين IP المميّزة لاسم النطاق المطلوب. يشير العدد 176إلى المُعطى TTL أي مدة صلاحيّة المعلومة؛ وهي المدة التي سينتظرها خادوم أسماء النطاقات قبل أن يعيد النظر في الارتباط بين اسم النطاق وعنوان IP. تعني IN أن هذا السّجل من سجلات الإنترنت المعيارية.

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

;; Query time: 27 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Apr 20 13:28:31 GMT 2017
;; MSG SIZE  rcvd: 75

كيف تستخدم Dig لاختبار سجلات DNS

تحوي إجابة dig مبديئا معلومات عن السجلات من النوع A، إلا أنه يمكن تحديد نوع السجل المطلوب بذكره بعد اسم النطاق:

dig your_domain_name.com record_type

يستفسر الأمر التالي عن السجلّات من نوع MX (البريد الإلكتروني):

dig duckduckgo.com MX

يُظهر مقطع الإجابة السجلات التاليّة:

 ;; QUESTION SECTION:
;duckduckgo.com.                        IN      MX

;; ANSWER SECTION:
duckduckgo.com.         300     IN      MX      60 mx2.dnsmadeeasy.com.
duckduckgo.com.         300     IN      MX      40 mx1.dnsmadeeasy.com.
duckduckgo.com.         300     IN      MX      10 in1-smtp.messagingengine.com.
duckduckgo.com.         300     IN      MX      20 in2-smtp.messagingengine.com.
duckduckgo.com.         300     IN      MX      50 mx3.dnsmadeeasy.com.

نمرّر القيمة ANY مكان اسم السجل إن أردنا الحصول على معلومات عن جميع سجلات النطاق:

dig duckduckgo.com ANY

تتضمّن نتائج الأمر السابق جميع السجلّات التي توافق النطاق duckduckgo.com مهما كان نوعها.

ملحوظة: نظرا لآليّة عمل نظام أسماء النطاقات فإن ظهور سجلّ أضيف حديثا إلى النطاق قد يأخذ وقتا. انتظر انقضاء مدّة TTL عند إضافة سجلّ جديد إلى النطاق، قبل أن تعيد الاستعلام عنه.

إذا كان كلّ ما تريد البحث عنه هو عنوان (أو عناوين) IP الذي يُشير إليه النطاق فتمرير short+ مكان نوع السجل يعطيك الإجابة:

dig duckduckgo.com +short

النتيجة:

50.18.192.250
50.18.192.251

استعمال الأمر host بدلا من dig

الأمر host هو بديل للأمر dig يشبهه في خيارات الاستخدام. يُنفَّذ الأمر host على النحو التالي:

host domain_name_or_IP_address

حيث domain_name_or_IP_address هو اسم نطاق أو عنوان IP. لاحظ أن الأمر host لا يحتاج لخيارات من أجل تغيير وظيفة البحث من استعلام DNS العادي إلى استعلام DNS المعكوس (معرفة اسم النطاق انطلاقا من عنوان IP)؛ إذ يختار الوظيفة المناسبة انطلاقا من المعطى المُمرَّر.

يمكن تحديد نوع السجلّات التي تهمّك بتمرير الخيار t- متبوعا باسم السجّل:

host -t mx duckduckgo.com

النتيجة:

duckduckgo.com mail is handled by 20 in2-smtp.messagingengine.com.
duckduckgo.com mail is handled by 10 in1-smtp.messagingengine.com.
duckduckgo.com mail is handled by 50 mx3.dnsmadeeasy.com.
duckduckgo.com mail is handled by 40 mx1.dnsmadeeasy.com.
duckduckgo.com mail is handled by 60 mx2.dnsmadeeasy.com.

استخدم الخيار a- إن أردت معلومات عن جميع أنواع السجلات (الإجابة قد تكون طويلة):

host -a duckduckgo.com

يمكن أيضا استخدام الخيار v- للحصول على معلومات إضافية عن المضيف:

host -v duckduckgo.com

أدوات أخرى للاستعلام عن أسماء النطاقات

Ping

يُعدّ استخدام الأمر ping إحدى أسهل الطرق لمعرفة ما إذا كان الخادوم يميّز الأسماء بطريقة صحيحة:

ping your_domain_name.com

تشبه نتيجة الأمر ما يلي:

PING your_domain_name.com (192.241.160.34) 56(84) bytes of data.
64 bytes from 192.241.160.34: icmp_req=1 ttl=64 time=0.026 ms
64 bytes from 192.241.160.34: icmp_req=2 ttl=64 time=0.038 ms
64 bytes from 192.241.160.34: icmp_req=3 ttl=64 time=0.037 ms
. . .

ستستمر مخرجات الأمر بالظهور إلى أن تضغط على زرّيْ CTRL وC معا لإيقافه.

يمكنك أيضا تحديد عدد المُخرجات بالخيار c-:

ping -c 3 your_domain_name.com

PING your_domain_name.com (192.241.160.34) 56(84) bytes of data.
64 bytes from 192.241.160.34: icmp_req=1 ttl=64 time=0.027 ms
64 bytes from 192.241.160.34: icmp_req=2 ttl=64 time=0.059 ms
64 bytes from 192.241.160.34: icmp_req=3 ttl=64 time=0.042 ms

--- your_domain_name.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.027/0.042/0.059/0.015 ms

استخدام الأمر ping وسيلة سريعة للتأكّد من أن نتيجة تمييز اسم النطاق هي عنوان IP الذي عيّنته له.

Whois

يتيح ميثاق (بروتوكول) Whois معلومات عن أسماء النطاقات المسجَّلة، بما في ذلك عناوين الخواديم المعدّة للعمل عليها. على الرغم من أن أغلب المعلومات التي يُظهرها الأمر whois تتعلّق بالتسجيل Registration إلا أنها يمكن أن تكون مفيدة لمعرفة ما إذا كانت خواديم الأسماء Name servers تظهر على نجو سليم.

يُستخدَم الأمر على النحو التالي:

whois your_domain_name.com

تظهر في نتيجة اﻷمر الكثيرُ من المعلومات التي تختلف طريقة عرضها من خادوم إلى آخر.
تظهر خواديم النطاقات التي توجّه إلى عناوين IP الصحيحة عادة في أسفل النتيجة.

خاتمة

يمكن أن تكون الأدوات Ping، Dig وWhois على الرغم من سهولة التعامل معها مفيدة جدًّا لإجراء اختبارات أساسية على أسماء النطاقات، مما يساعدك في اقتصاد الكثير من الوقت ومعرفة مشاكل الإعدادت بسرعة.

ترجمة - بتصرّف - للمقال How To Use Dig, Whois, & Ping on an Ubuntu VPS to Query DNS Data لصاحبه Justin Ellingwood.

خدمة اسم النطاق (Domain Name Service) هي خدمة إنترنت تربط بين عناوين IP وأسماء النطاق الكاملة (fully qualified domain names‏ [FQDN])؛ وفي هذه الطريقة، تخفف خدمة DNS من حاجة تذكر عناوين IP. تسمى الحواسيب التي تشغّل خدمة DNS «خواديم الأسماء»، ويأتي أوبنتو مع BIND‏ (Brekley Internet Naming Daemon)، وهو أشهر خدمة لإعداد خادوم أسماء في لينُكس.

التثبيت

أدخِل الأمر الآتي في مِحَث الطرفية لتثبيت خادوم dns:

sudo apt-get install bind9

حزمة dnsutils مفيدةٌ جدًا في اختبار واستكشاف أخطاء DNS؛ قد تكون هذه الأدوات مثبتةً مسبقًا على نظامك؛ لكن للتأكد من وجودها أو تثبيتها، أدخِل الأمر الآتي:

sudo apt-get install dnsutils

الضبط

هنالك العديد من الطرق لضبط BIND9؛ لكن بعض أشهر هذه الإعدادات هي خادوم تخزين أسماء (caching nameserver)، الرئيس الأولي (primary master)، والرئيس الثانوي (secondary master).

• عند ضبطه كخادوم تخزين أسماء، فسيجد BIND9 جوابًا عن استعلامات الأسماء وسيتذكر الجواب عندما يُطلَب النطاق مرةً أخرى.
• عندما يُضبَط كخادوم رئيس أولي، فسيقرأ BIND9 البيانات لنطاق (Zone) في ملف في المضيف ويستوثق لهذا النطاق.
• عندما يُضبَط كخادوم رئيس ثانوي؛ فسيحصل BIND9 على بيانات النطاق من خادوم أسماء آخر ويستوثق للنطاق.

لمحة

تُخزَّن ملفات ضبط DNS في المجلد ‎/etc/bind، ملف الضبط الرئيسي هو ‎/etc/bind/named.conf.

يُحدِّد سطر include اسمَ الملف الذي يحتوي على خيارات DNS؛ سطر directory في ملف ‎/etc/bind/named.conf.options يخبر DNS أين سيبحث عن الملفات، جميع الملفات التي يستخدمها BIND ستتعلق بهذا المجلد.

يصف ملف ‎/etc/bind/db.root خواديم الأسماء الرئيسية في العالم؛ تتغير هذه الخواديم مع مرور الوقت، لذلك يجب أن يُحدَّث ملف ‎/etc/bind/db.root بين الحين والآخر؛ وذلك يتم عادةً في تحديثات حزمة bind9؛ يُعرِّف القسم zone خادومًا رئيسيًا (master server)، وهو مخزن في ملف مذكور في خيار file.

من الممكن ضبط نفس الخادوم ليكون خادوم تخزين أسماء، ورئيس أولي، ورئيس ثانوي؛ ويمكن أن يكون الخادوم «بداية السلطة» (Start of Authority‏ [SOA]) لنطاق واحد، بينما يوفر خدمة ثانوية لنطاق آخر؛ ومع كل هذا فهو يوفر خدمات التخزين للمضيفين على الشبكة المحلية LAN.

خادوم تخزين الأسماء

الضبط الافتراضي هو العمل كخادوم تخزين؛ كل ما هو مطلوب هو ببساطة إضافة عناوين IP لخواديم DNS التي وفرها لك مزود الخدمة ISP؛ ببساطة، أزل التعليقات عن الأسطر الآتية وعدلها في ملف ‎/etc/bind ‎/named.conf.options:

forwarders {
              1.2.3.4;
              5.6.7.8;
           };

ملاحظة: استبدل 1.2.3.4 و 5.6.7.8 بعناوين IP لخواديم الأسماء لديك.

أعد الآن تشغيل خادوم DNS لتفعيل الضبط الجديد، وذلك بتنفيذ الأمر الآتي من مِحَث الطرفية:

sudo service bind9 restart

راجع القسم «dig» لمزيدٍ من المعلومات حول اختبار خادوم تخزين DNS.

الرئيس الأولي

سنضبط في هذا القسم BIND9 كخادوم رئيس أولي للنطاق example.com؛ استبدل example.com باسم نطاقك الكامل.

• ملف تمرير المنطقة

لإضافة منطقة DNS إلى BIND9، مما يحول BIND9 إلى خادوم رئيس أولي، فإنَّ أول خطوة هي تعديل ملف ‎/etc/bind/named.conf.local:

zone "example.com" {
        type master;
        file "/etc/bind/db.example.com";
};

ملاحظة: إذا كان سيستقبل bind تحديثاتٍ تلقائيةً عبر DDNS، فعليك استخدام الملف ‎/var/lib/bind ‎/db.example.com‎ بدلًا من ‎/etc/bind/db.example.com سواءً في الملف السابق أو في أمر النسخ الآتي.

استخدم الآن ملف نطاق موجود مسبقًا كقالب لإنشاء ملف ‎/etc/bind/db.example.com:

sudo cp /etc/bind/db.local /etc/bind/db.example.com

عدِّل ملف النطاق الجديد ‎/etc/bind/db.example.com مغيّرًا localhost إلى FQDN لخادومك، واترك النقطة الإضافية في النهاية؛ وغيّر 127.0.0.1 إلى عنوان IP لخادوم الأسماء و root.localhost إلى عنوان بريد صالح، لكن باستخدام "." بدلًا من رمز "@" واترك أيضًا النقطة الإضافية في النهاية؛ عدِّل التعليق لكي يبيّن النطاق الخاص بهذا الملف.

أنشئ «سجلًا» (record) للنطاق الأساسي، example.com، وأيضًا أنشِئ سجلًا لخادوم الأسماء، الذي هو في هذا المثال ns.example.com:

;
; BIND data file for example.com
;
$TTL    604800
@       IN       SOA    example.com.     root.example.com. (
                              2             ; Serial
                         604800             ; Refresh
                          86400             ; Retry
                        2419200             ; Expire
                         604800 )           ; Negative Cache TTL
        IN       A      192.168.1.10
;
@       IN       NS     ns.example.com.
@       IN       A      192.168.1.10
@       IN       AAAA   ::1
ns      IN       A      192.168.1.10

يجب أن تزيد الرقم التسلسلي (Serial Number) في كل مرة تعدِّل فيها على ملف النطاق؛ إذا عدَّلت عدة تغيرات قبل إعادة تشغيل BIND9، فَزِد الرقم التسلسلي مرةً واحدةً فقط.

تستطيع الآن إضافة سجلات DNS في نهاية ملف المنطقة، راجع القسم «أنواع السجلات الشائعة» للتفاصيل.

ملاحظة: يحب العديد من مدراء الأنظمة استخدام تاريخ آخر تعديل كرقم تسلسلي للمنطقة؛ مثل 2012010100 الذي هو yyyymmddss (حيث ss هو الرقم التسلسلي).

بعد أن أجريت تعديلاتك في ملف النطاق؛ فيجب إعادة تشغيل BIND9 لكي تأخذ التعديلات مجراها.

sudo service bind9 restart

• ملف النطاق المعكوس

بعد أن ضبطت النطاق لحل الأسماء إلى عناوين IP، فمن المطلوب أيضًا «نطاق معكوس» (Reverse zone)؛ يسمح النطاق المعكوس لخدمة DNS بحل العناوين إلى أسماء.

عدِّل ملف ‎/etc/bind/named.conf.local، وأضف ما يلي:

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192";
};

ملاحظة: استبدل 1.168.192 بأول ثلاث خانات تستخدمها شبكتك؛ وسَمِّ ملف النطاق ‎/etc/bind/db.192 تسميةً ملائمةً، حيث يجب أن يُطابِق أول خانة من خانات عنوان الشبكة.

أنشِئ الآن ملف ‎/etc/bind/db.192:

sudo cp /etc/bind/db.127 /etc/bind/db.192

ثم غيِّر ملف ‎/etc/bind/db.192 معدِّلًا نفس الخيارات في ‎/etc/bind/db.example.com:

;
; BIND reverse data file for local 192.168.1.XXX net
;
$TTL  604800
@     IN       SOA    ns.example.com.     root.example.com. (
                             2                 ; Serial
                        604800                 ; Refresh
                         86400                 ; Retry
                       2419200                 ; Expire
                        604800 )               ; Negative Cache TTL
;
@     IN       NS      ns.
10    IN       PTR     ns.example.com.

يجب أن يُزاد الرقم التسلسلي في النطاق المعكوس في كل مرة يُعدَّل فيها الملف. فلكل سجل A تضبطه في ‎/etc/bind/db.example.com لعنوان مختلف، يجب عليك أن تنشِئ سجل PTR في ‎/etc/bind/db.192.

أعد تشغيل BIND9 بعد إنشاء ملف النطاق المعكوس.

sudo service bind9 restart

الرئيس الثانوي

بعد أن يُضبَط الرئيس الأولي فسنحتاج إلى رئيس ثانوي لكي نحافظ على بقاء النطاق في حال لم يكن الرئيس الأولي متوفرًا.

في البداية، يجب أن يُسمَح بنقل النطاق في الخادوم الرئيس الأولي؛ أضف الخيار allow-transfer إلى قسم النطاق والنطاق المعكوس في ملف ‎/etc/bind/named.conf.local:

zone "example.com" {
        type master;
        file "/etc/bind/db.example.com";
        allow-transfer { 192.168.1.11; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192";
        allow-transfer { 192.168.1.11; };
};

ملاحظة: استبدل 192.168.1.11 بعنوان IP لخادوم الأسماء الثانوي.

أعد تشغيل خدمة BIND9 في الرئيس الأولي:

sudo service bind9 restart

الآن ثبِّت على الرئيس الثانوي الحزمة bind9 بنفس الطريقة التي ثبتتها على الأولي؛ ثم عدِّل ملف ‎/etc/bind/named.conf.local وأضف التعاريف الآتية لنطاقَيّ التمرير والعكس:

zone "example.com" {
        type slave;
        file "db.example.com";
        masters { 192.168.1.10; };
};

zone "1.168.192.in-addr.arpa" {
        type slave;
        file "db.192";
        masters { 192.168.1.10; };
};

ملاحظة: استبدل 192.168.1.10 بعنوان IP لخادوم الأسماء الأولي.

أعد تشغيل خدمة BIND9 على الخادوم الثانوي:

sudo service bind9 restart

يجب أن تشاهد في سجل ‎/var/log/syslog شيئًا شبيهًا بما يلي (قُسِّمَت بعض الأسطر لكي تتسع في عرض الصفحة):

client 192.168.1.10#39448: received notify for zone '1.168.192.in-addr.arpa'
zone 1.168.192.in-addr.arpa/IN: Transfer started.
transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:
 connected using 192.168.1.11#37531
zone 1.168.192.in-addr.arpa/IN: transferred serial 5
transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:
 Transfer completed: 1 messages,
6 records, 212 bytes, 0.002 secs (106000 bytes/sec)
zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5)

client 192.168.1.10#20329: received notify for zone 'example.com'
zone example.com/IN: Transfer started.
transfer of 'example.com/IN' from 192.168.1.10#53: connected using 192.168.1.11#38577
zone example.com/IN: transferred serial 5
transfer of 'example.com/IN' from 192.168.1.10#53: Transfer completed: 1 messages,
8 records, 225 bytes, 0.002 secs (112500 bytes/sec)

ملاحظة: تُنقَل المنطقة فقط إذا كان الرقم التسلسلي على الأولي أكبر منه على الثانوي؛ وإذا أردت أن يعلم الرئيس الأولي بتعديلات النطاقات في خواديم DNS الثانوية، فعليك إضافة الخيار ;{ also-notify { ipaddress  في ملف ‎/etc/bind/named.conf.local كما هو موضح في المثال الآتي:

zone "example.com" {
        type master;
        file "/etc/bind/db.example.com";
        allow-transfer { 192.168.1.11; };
        also-notify { 192.168.1.11; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192";
        allow-transfer { 192.168.1.11; };
        also-notify { 192.168.1.11; };
};

ملاحظة: المجلد الافتراضي للنطاقات غير الموثوق منها هو ‎/var/cache/bind؛ يُضبَط هذا المجلد أيضًا في AppArmor ليسمح للعفريت named بالكتابة إليه؛ المزيد من المعلومات حول AppArmor ستتوفر في الدرس القادم.

استكشاف الأخطاء وإصلاحها

يشرح هذا القسم الطرق التي تستخدم للمساعدة في تحديد المسبب عندما تحدث المشاكل مع DNS و BIND9.

الاختبار

• ملف resolv.conf

أول خطوة في اختبار BIND9 هي إضافة عنوان IP لخادوم الأسماء للذي يستبين أسماء المضيفين؛ يجب أن يُضبَّط خادوم الأسماء أيضًا لمضيف آخر للتأكد مرةً أخرى؛ تحقق إن كان الملف ‎/etc/resolv.conf يحتوي على الأسطر الآتية:

nameserver 192.168.1.10
nameserver 192.168.1.11

خواديم الأسماء التي تستمع على ‎127.*‎ مسؤولة عن إضافة عناوين IP الخاصة بهم إلى ملف resolv.conf (باستخدام resolveconf)؛ وهذا يتم عبر الملف ‎/etc/default/bind9 بتغيير السطر:

RESOLVECONF=no 

إلى:

RESOLVECONF=yes.‏‎

ملاحظة: يجب إضافة عنوان IP لخادوم الأسماء الثانوي في حال لم يكن الخادوم الأولي متوفرًا.

• أداة البحث dig

إذا ثبتت حزمة dnsutils فيمكنك اختبار إعداداتك باستخدام أداة البحث في DNS المسماة dig:

بعد تثبيت BIND9، فاستخدم dig مع بطاقة loopback (أي localhost) للتأكد أنها تستمع على المنفذ 53؛ أدخِل الأمر الآتي في مِحَث الطرفية:

dig -x 127.0.0.1

يجب أن تُشاهِد أسطرًا شبيهة بالآتي في ناتج الأمر:

;; Query time: 1 msec
;; SERVER: 192.168.1.10#53(192.168.1.10)

إذا ضَبطَت BIND9 كخادوم تخزين الأسماء، فابحث (dig) عن نطاق خارجي للتحقق من زمن الطلبية:

dig ubuntu.com

لاحظ وقت الطلبية في نهاية ناتج الأمر السابق:

;; Query time: 49 msec

بعد استخدام dig مرةً أخرى، يجب أن يتحسن الرقم السابق:

;; Query time: 1 msec

• أداة ping

لشرح كيف تَستخدم التطبيقات DNS لكي يستبين اسم المضيف؛ فسنستخدم الأداة ping لإرسال طلب ICMP echo؛ وذلك بإدخال الأمر الآتي في الطرفية:

ping example.com

ما سبق سيختبر إن استطاع خادوم الأسماء استبيان الاسم ns.example.com وتحويله إلى عنوان IP؛ يجب أن تشابه مخرجات الأمر السابق ما يلي:

PING ns.example.com (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.800 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.813 ms

• named-checkzone

طريقة رائعة لاختبار ملفات النطاقات لديك هي استخدام الأداة المثبتة مع حزمة bind9؛ تسمح هذه الأداة لك بالتأكد من أن الضبط صحيح قبل إعادة تشغيل BIND9 وجعل التغيرات حيةً.

أدخِل الأمر الآتي في الطرفية لاختبار ملف النطاق في مثالنا:

named-checkzone example.com /etc/bind/db.example.com

إذا كان كل شيءٍ مضبوطًا ضبطًا سليمًا، فستشاهد مخرجاتٍ شبيهةٍ بما يلي:

zone example.com/IN: loaded serial 6
OK

وبشكل مشابه، أدخل ما يلي لاختبار ملف النطاق العكسي:

named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192

يجب أن تكون المخرجات شبيهةً بما يلي:

zone 1.168.192.in-addr.arpa/IN: loaded serial 3
OK

ملاحظة: سيكون الرقم التسلسلي لملف النطاق عندك مختلفًا عادةً.

التسجيل

لدى BIND9 خيارات كثيرة لضبط التسجيل (logging)؛ هنالك خياران رئيسيان هما الخيار channel الذي يضبط أين سيذهب السجل، والخيار category الذي يحدد ما هي المعلومات التي ستُسجَّل.

إذا لم يُحدَّد ضبطٌ للتسجيل، فالضبط الافتراضي هو:

logging {
     category default { default_syslog; default_debug; };
     category unmatched { null; };
};

يشرح هذا القسم ضبط BIND9 لإرسال رسائل debug متعلقة بطلبيات DNS إلى ملفٍ منفصل.

سنحتاج أولًا إلى ضبط «قناة» (channel) لتحديد الملف الذي ستُرسَل إليه الرسائل، عدل ملف ‎‎/etc/bind/‎named.conf.local، وأضف ما يلي:

logging {
    channel query.log {
        file "/var/log/query.log";
        severity debug 3;
    };
};

• اضبط الآن تصنيفًا لإرسال جميع طلبيات DNS إلى ملف query:

logging {
    channel query.log {
        file "/var/log/query.log";
        severity debug 3;
    };
    category queries { query.log; };
};

ملاحظة: لاحظ أن الخيار debug يمكن أن يُضبَط من المرحلة 1 إلى 3؛ وستستخدم المرحلة 1 إذا لم تُحدَّد مرحلة.

ولما كان عفريت named يعمل كمستخدم bind، فيجب إنشاء الملف ‎/var/log/query.log وتغيير ملكيته:

sudo touch /var/log/query.log
sudo chown bind /var/log/query.log

قبل أن يتمكن العفريت named من الكتابة إلى ملف السجل الجديد، فيجب أن يُحدَّث ضبط AppArmor؛ أولًا، عدِّل ملف ‎/etc/apparmor.d/usr.sbin.named وأضف:

/var/log/query.log w,

ثم أعد تحميل ملف ضبطه:

cat /etc/apparmor.d/usr.sbin.named | sudo apparmor_parser -r

أعد الآن تشغيل BIND9 لكي تأخذ التغييرات مفعولها:

sudo service bind9 restart

يجب أن ترى الملف ‎/var/log/query.log ممتلئًا بمعلومات الطلبيات؛ هذا مثال بسيط عن ضبط تسجيل BIND9؛ راجع القسم «المزيد من المعلومات» للمزيد من الخيارات المتقدمة.

المراجع

أنواع السجلات الشائعة

يغطي هذا القسم بعض أنواع سجلات DNS الشائعة.

• سجل A: يربط هذا السجل عنوان IP إلى اسم مضيف.

www IN A 192.168.1.12

• سجل CNAME: يُستخدَم لإنشاء اسم بديل لسجل موجود مسبقًا، لا يمكنك استخدام سجل CNAME للإشارة إلى سجل CNAME آخر.

web IN CNAME www

• سجل MX: يُستخدَم لتعريف أين يجب أن يُرسَل البريد؛ يجب أن يشير إلى سجل A، وليس سجل CNAME.

     IN MX 1 mail.example.com.
mail IN A    192.168.1.13

• سجل NS: يُستخدَم لتعريف أيّة خواديم تُخَدِّم نسخًا من المنطقة؛ يجب أن يشير إلى سجل A، وليس إلى CNAME؛ هذا مكان تعريف الخادومين الأولى والثانوي.

    IN NS ns.example.com.
    IN NS ns2.example.com.
ns  IN A  192.168.1.10
ns2 IN A  192.168.1.11

المزيد من المعلومات

• دليل «DNS HOWTO» يشرح الخيارات المتقدمة لضبط BIND9.
• انظر إلى bind9.net للحصول على شرح معمّق لعمل DNS و BIND9.
• كتاب «DNS and BIND» هو كتابٌ شائع أصبح في إصداره الخامس؛ وهنالك أيضًا كتاب «DNS and BIND on IPv6».
• مكان رائع لطلب المساعدة في BIND9 والتعاون مع مجتمع خادوم أوبنتو هو قناة IRC على خادوم Freenode «#ubuntu-server»‎.
• أيضًا، راجع «BIND9 Server HOWTO» في ويكي أوبنتو.

ترجمة -وبتصرف- للمقال: Ubuntu Server Guide: Domain Name Service DNS. 

مقدِّمة

نظام أسماء النطاقات Domain Name System، أو DNS اختصارًا، جزء متكامل من آلية ربط مختلف الأنظِمة التي تعمل على شبكة الإنترنت. ستحتاج الحواسيب والأشخاص الذين يستعملونها - في غياب نظام DNS - إلى استخدام العناوين المكوَّنة من أرقام، المعروفة باسم عناوين IP (بالإنجليزية IP Addresses).

يُسبِّب الاعتمادُ على عناوين IP - وحدَها - للتواصل على الإنترنت العديد من المشاكل. أولها المُشكل البديهي المتمثِّل في العدد الكبير من الأرقام المُعقَّدة المطلوبة لإجراء المهامّ، مهما كانت بساطتها. ينضاف إلى ذلك مشكلُ نقل موقع إلكتروني إلى مقدِّم استضافة Hosting provider جديد، أو تبديل مكان تواجد خواديمك إلى موقع مُغايِِر؛ سيتوجَّب عليك في الحالتين إعلامُ كل واحد من زبنائك بالموقع الجديد.

تمتلك خواديم DNS - وهي الحواسيب التي تشكِّل معًا النظام الذي يمكِّننا من استخدام أسماء للعنونة - القدرة على تأديّة وظائف عديدة تُساهِم كل واحدة منها في إمكانية النفاذ إلى خواديمك بأسماء بدلَ أرقام.

تحدّثنا في مقال سابق عن مفاهيم ومُصطلَحات نظام أسماء النّطاقات الأساسية؛ نفترض هنا معرفة هذه المُصطلحات والمفاهيم. سنناقش في هذا المقال بعض أنواع إعدادات خواديم DNS: ميزات وحالات استخدام وخصائص كل واحد منها.

مسار استعلام DNS path query - DNS

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

تحتفِظ بعض البرامج، كما هي حال أغلب متصفِّحات الوب، بنسخ مخبَّأةCache من الاستعلامات الأخيرة. تفتّش هذه التطبيقات بدءًا في النُّسخ المخبَّأة لديها بحثًا عن عنوان IP النطاق؛ فإن لم تجِد الإجابة التي تبحث عنها تلجأ إلى أداة الحلّ Resolver الموجودة في نظام التّشغيل.

يُقصَد بأداة الحلّ أي عنصر يوجد في جانب العميل ويُشارِك في استعلام DNS. تقوم مكتبة الحلّ Resolving library بهذا الدّور في نظام التشغيل الذي يستخدمها للبحث عن إجابة لاستعلامات DNS. فنيَّا مكتبة الحلّ هي مجموعة من الدّوال Functions للترجمة بين أسماء النّطاقات وعناوين IP. أداة الحل في نظام التشغيل هي العامل المحفِّز لعملية البحث عن عنوان IP؛ فكل ما تقوم به هو النّظر في بضع ملفات موجودة على نظام التشغيل (مثل etc/hosts/ في نظام غنو/لينوكس) أو تحويل الطّلب إلى أداة حلّ أخرى.

يمر الاستعلام من البرنامج العميل إلى أداة الحلّ الموجودة في نظام التشغيل؛ التي تُرسلها إلى خادوم أسماء ليبحثَ عن عنوان IP المطلوب. يُسمَّى خادوم الأسماء في هذه الحالة خادوم DNS تكراري، Recursive DNS server. خادوم DNS تكراري هو خادوم مضبوط لمواصلة إرسال طلبات إلى خواديم DNS الأخرى بحثا عن العنوان الذي يُحيل إليه اسم النّطاق حتى يجد الإجابة. بعد عملية البحث يُحوِّل الخادوم التكراري الإجابة - أو رسالة الخطأ في حال تعذر الحصول على عنوان IP - إلى العميل (أداة الحلّ في نظام التّشغيل التي بدورها تمرِّرها إلى البرنامج).

تحتفظ الخواديم التكرارية هي الأخرى - غالبًا - بنُسخ مخبَّأة من الاستعلامات. تبدأ هذه الخواديم عند وصول استعلام جديد بالبحث أولا في النسخ المُخبَّأة لديها، فإن لم توجد الإجابة في تلك النُّسخ؛ تنظُر إذا ما كانت تعرِف عنوان IP النطاق الأعلى لاسم النطاق قيدَ البحث. على سبيل المثال: إذا كان الاستعلام يتعلَّق بالنطاق www.example.com ولم يجد الخادوم التكراري نسخة مخبّأة بالنتيجة؛ فالخطوة الموالية هي العثور على خواديم أسماء النّطاق example.com، وفي حالة عدم معرفتها يبحث عن خواديم النطاق العلوي Top-level domain - TLD، أي com في هذا المثال. المبدأ هو أن يُرسِل الخادوم التكراري الاستعلام إلى خادوم الأسماء الأكثر تحديدا من بين خواديم الأسماء التي يعرفها للحصول على معلومات عن النّطاق.

يحدُث ألا يعرف الخادوم التكراري عنوانَ أي من عناصر اسم النّطاق، في هذه الحالة يتوجّب عليه البدء من أعلى التسلسل الهرمي بإرسال استعلام إلى خواديم الجذر Root servers. تعرِف خواديم الجذر عناوين كل خواديم الأسماء التي تُدير النطاقات العلوية (TLD) مثل com. و net. و org. وغيرها. يُجيب الخادوم الجذر عند تلقي الاستعلام عن www.example.com بعنوان IP خواديم أسماء النطاق العلوي com.

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

رأينا في المثال السابق أنه توجد أنواع عديدة من الخواديم يقوم كل منها بدورِ مُختلِف. سنتعرف في الفقرات المُقبلة على خصائص كل واحد من أنواع خواديم DNS.

الفروق الوظيفية Functional differences

تختلف خواديم DNS في الوظائف التي تؤديها؛ فأغلب الخواديم التي تدخل في إطار نظام أسماء النطاقات تتخصّص في وظائف محدَّدة. يعتمِد نوع خادوم DNS الذي تستخدمه على حاجاتك وطبيعة المشاكل التي تريد إيجاد حلول لها.

الخواديم المُقتصِرة على منطقة السلطة Authoritative-Only DNS Servers

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

لدى الخواديم المُقتصِرة على منطقة السلطة الخصائص التالية:

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

• لا تُجيب على الاستعلامات التكرارية. التّعريف الّدقيق لخادوم مقتصر على منطقة السلطة هو أنه خادوم لا يتعامل مع الاستعلامات التكرارية. تعني هذه الخاصية أن الخادوم المُقتصِر على السّلطة لا يقوم أبدًا بدور عميل في نظام DNS. الاستعلامات التي تصِل إلى هذا الخادوم تأتي في الغالب من خادوم أسماء حالّ Resolving name server تلقى إحالة إلى الخادوم المُقتصر على السّلطة، وهو ما يعني أن هذا الأخير إما لديه الإجابة الكاملة أو لديه إحالة إلى خادوم أسماء مُفوَّض من طرفه بإدارة بعض موارد النّطاق.

• لا يحتفظ بأي نُسَخ مخبَّأة. توجد كل المعلومات التي يحتاجها الخادوم المُقتصِر على السّلطة في نظام الملفّات لديه، وبما أنه لا يُرسِل استعلامات إلى خواديم أخرى فهذا يعني أنه لا يوجد لديه داعٍ لحفظ نُسخ مخبَّأة.

خادوم DNS مُخبِّئ Caching DNS Server

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

تُعتَبر الخواديم المُقتصِرة على منطقة السلطة، من وجهة نظر معلومات نطاق محدَّد، مثالية؛ إلا أن الخواديم المخبِّئة أكثر فائدة من وجهة نظر العميل الذي قد يكون مجرَّد واجهة رسومية بسيطة، تتيح له الخواديم المُخبِّئة الوصول إلى كامل نظام DNS.

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

لدى الخواديم المُخبِّئة الخصائص التاليّة:

• إمكانية الوصول إلى كل معلومات نظام DNS المُتاحة للعموم؛ إذ أن الخواديم المُخبِّئة تستطيع الحصول على كل معلومات النّطاقات الموجودة لدى خواديم الأسماء المرتبِطة بالترتيب الهرمي لنظام DNS التي يُتاح الوصول إليها بشكل عام. تعرف الخواديم المُخبِّئة عناوين خواديم الجذر وتستطيع تتبّع الإحالات بذكاء أثناء حصولها على البيانات.

• القدرة على التّدرج في إرسال البيانات إلى العملاء محدودي الموارد (الذاكرة Memory، المُعالِج Processor، ..إلخ). تقوم أغلب نُظُم التّشغيل الحديثة بتوكيل عملية تعيين أسماء النطاقات إلى خواديم تكرارية مُتفرِّغة لهذا الغرض، وذلك عن طريق مكتبة الحلّ. كل ما تقوم به مكتبة الحلّ هو إرسال استعلام ثم انتظار الحصول على إجابة كاملة. لدى الخادوم المُخبِّئ الإمكانات اللازمة بالضبط لتلبية طلب هذه المكتبات. يعني قبول الخواديم المُخبّئة للاستعلامات التكرارية أنها تضمن إما إرسال إجابة إلى العميل أو إبلاغه برسالة خطأ.

• تحتفظ بنسخ من البيانات المطلوبة في الاستعلامات الأخيرة. تُنشئ هذه الخواديم نسخ من بيانات DNS الأخيرة التي حصلت عليها أثناء البحث عن استعلامات العملاء. تعتمد سرعة الحصول على إجابة من طرف خادوم مخبّئ على عوامل أهمها عدد عملاء الخادوم، وسعة ذاكرة التخبئة Cache memory وقيمة TTL الموجودة في سجلاّت خادوم اسم النطاق المطلوب.

خادوم إعادة التوجيه Forwarding DNS Server

يُشكِّل خادوم إعادة التوجيه بديلًا عن إنشاء نُسَخ مخبَّأة على الحواسيب العميلة. تُضيف هذه المقاربة حلقةً جديدة في مسار استعلام DNS عن طريق تشغيل خادوم إعادة توجيه تتلخَّص مهمته في تمرير كل استعلامات DNS إلى خادوم لديه القدرة على التعامل مع الطلبات التكرارية (خادوم مُخبِّئ على سبيل المثال). تُعطي هذه الطّريقة ميزة الحصول على نُسخ مخبَّأة يُمكن الوصول إليها من الشبكة المحلية Local network دون الحاجة لعمل الاستعلامات التكرارية (قد تستأثر الاستعلامات التكرارية بمواردة مُعتبرة في الخواديم التي لديها حركة اتصالات فائقة).

لدى خواديم إعادة التوجيه الخصائص التالية:

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

• توفير تخبِئة بالقرب من الشبكة المحلية. يستطيع خادوم إعادة التوجيه طلب خواديم DNS تكرارية متاحة للعموم وهو ما يُغنيك إن لم تكن لديك القدرة على إنشاء وصيانة وتأمين خدمة DNS كاملة. إتاحة تخبئة قريبة من الشبكة المحلية تعني التقليل من الوقت اللازم للإجابة على الاستعلامات.

• زيادة المرونة عن طريق تعريف فضاء محلي لأسماء النطاقات. يستطيع خادوم إعادة التوجيه إضافة شروط على وجهة الاستعلامات وذلك للتأكد من أن الطلبات المحلية تُوجَّه إلى خواديم خاصة بينما تُرسل الطّلبات الخارجية إلى خواديم DNS عامّة.

الحلول التجميعية

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

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

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

الفروقات الارتباطية Relational Differences

من المهم الانتباه للفروق في العلاقة بين الخواديم. فبالرغم أن أغلب الفروق بين إعدادات الخواديم هي فروق وظيفية إلا أن الاختلافات في طبيعة العلاقة بين الخواديم مهمة جدًّا هي الأخرى.

الخواديم الرئيسة والخواديم التابعة Primary and Slave Servers

تعمَد الكثير من أنظمة DNS المسؤولة عن نطاق معيَّن إلى تضمين نُظُم احتياطية مكوَّنة من عدة خواديم لضمان الوصول إلى الخدمات التي توفّرها. تأتي العلاقة بين الخواديم في هذه النّظم على عدّة أشكال، لكن الخادوم - في الغالب - إما أن يكون رئيسًا Primary أو تابِعًا Slave. لدى كل من الخادوم الرئيس والتابع السّلطة على النطاق المسؤول عنه ولا يوجد فرق منه هذه الناحية. الفرق الوحيد بين خادوم أسماء رئيس وآخر تابِع هو المكان الذي يقرأ منه ملفات النطاق: يقرأ الخادوم الرئيس ملفات النطاق من القرص الصّلب لديه. يُضيف مديرو النُّظُم ملفات النطاق إلى نظام الملفات الموجود على الخادوم الرئيس. عند تحرير أو نقل ملفات النطاق فإن ذلك يتم على مستوى الخادوم الرئيس.

يستقبل الخادوم التابِع ملفات النطاق من أحد الخواديم الرئيسة ثمّ يحفظ نسخًا منها لديه في ذاكرة التخبِئة. في حال إعادة تشغيل الخادوم الرئيس فإنه يتحقق من كون ملفات النطاق محدَّثَة Up-to-date ويقوم بتحديث معلوماته من الخادوم الرئيس إن تطلّب الأمر ذلك.

ليسَ مفروضًا على الخادوم أن يكون رئيسًا (أو تابِعًا) في جميع نطاقات سُلطته. يُخصَّص وضع الخادوم (رئيس أو تابِع) لكل واحد من النطاقات التي هو مسؤول عنها دون أن يُؤثِّر ذلك على وضعه بالنسبة لبقية النطاقات؛ أي أنه يُمكن أن يكون رئيسًا بالنسبة لبعض النطاقات وتابِعا بالنسبة لنطاقات أخرى.

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

الخواديم العامّة والخواديم الخاصّة Public vs Private Servers

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

ذكرنا أثناء الحديث عن الحلول التجميعية أنه يُمكن لخادوم واحد التّعامل مع وظائف عديدة مع التفريق بين الخدمات الموجَّهة للعموم والأخرى الموجَّهة لمستخدمي الشّبكة الدّاخلية. هذه المُقاربة واردة؛ إلا أن توزيع العمل بين خادومين منفصليْن - عامّ وخاص - لا يعلمُ أي منهما شيئا عن الآخر يخفِّف حِمل العمل كما أنه أفضَل من وجهة نظر أمنية حيثُ لا وجود لسجلّات records عن الجزء الخاص لدى الخادوم العام. يعني هذا أن الخادوم العام لا يملك في ملفات النّطاق لديه أي سجلات من نوع NS عن خواديم الأسماء الخاصّة بالشبكة الدّاخلية.

بالحديث عن الأمان توجد بعض الاعتبارات التي ينبغي أخذها في الحسبان. العلاقة من نوع رئيس-تابِع هي الطّريقة السّهلة لتشارك بيانات النّطاق بين الخواديم العامّة والخاصّة، ولكنّ ذلك قد يُسرِّب معلومات عن بنية الشّبكة الداخليّة ويجعلها مُتاحةً للجميع.

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

خاتمة

تُدرك الآن وجود قدر لا بأس به من المرونة في خيارات إعداد DNS. يعتمد الخيار المُناسِب على حاجات مؤسستك: هل تمنح الأولوية لإعداد نظام DNS سريع لعدد محدّد من العملاء (خواديم مخبّئة أو خواديم إعادة التوجيه)، أم لتوفير خدمة تعيين نطاقاتك على الإنترنت بأكملها (خواديم مُقتصِرة على السّلطة). المقاربات التجميعية شائعة ويجب أخذ طريقتَي عمل DNS السّالفتي الذِّكر بالحسبان.

سنوضّح لك في المقالات اللّاحقة كيف تبدأ مع بعض هذه الإعدادات؛ حيثُ سنقوم أولا بضبط خادوم ليعمل إما كمخبِّئ أو لإعادة التوجيه، ثم نأتي بعد ذلك لإعداد خادومَيْ DNS يقتصران على نطاق السلطة. 

ترجمة -وبتصرّف- للمقال: A Comparison of DNS Server Types: How To Choose the Right DNS Configuration