DNS (Domain Name System) هو أحد المكونات الحاسمة التي تدير الإنترنت. إن الفهم الصحيح لكيفية عمل DNS يمكن أن يساعد في تشخيص المشكلات المتعلقة بتهيئة موقع الويب وتوسيع فهمك لما يجري خلف الكواليس.
في هذا الدليل، سنتحدث عن بعض المفاهيم الأساسية لـ DNS لتزويدك بأرضية صلبة أثناء العمل مع تهيئة DNS الخاصة بك. سيساعدك هذا الدليل أيضًا في إعداد اسم النطاق الخاص بك أو خادم DNS.
فلنبدأ!
مصطلحات النطاق
أولاً، نحتاج إلى بناء فهم للمصطلحات التي سنستخدمها. قد تكون على دراية ببعضها بالفعل من سياقات أخرى. ومع ذلك، هناك العديد من المصطلحات المحددة عند الحديث عن أسماء النطاقات و DNS والتي لا تتم مناقشتها كثيرًا في مجالات الحوسبة الأخرى.
-
نظام أسماء النطاقات
نظام أسماء النطاقات (DNS اختصارًا) هو نظام شبكي قائم يترجم أسماء النطاقات الصديقة للبشر إلى عناوين IP فريدة.
-
اسم النطاق
يشير اسم النطاق إلى الاسم الصديق للبشر المستخدم للارتباط بمورد على الإنترنت. على سبيل المثال، “cloudsigma.com” هو اسم نطاق. قد يجادل البعض بأن جزء “cloudsigma” فقط هو اسم النطاق، ولكنه يشير عمومًا إلى الكل.
يرتبط عنوان URL “cloudsigma.com” بالخوادم المملوكة لـ CloudSigma. عند إدخال عنوان URL في متصفح الويب، فإنه يتصل بـ DNS للاتصال بعنوان IP الخاص بالخادم المستهدف.
-
عنوان IP
يعمل عنوان IP كعنوان شبكة لجهاز متصل بالشبكة. يجب أن يكون كل عنوان IP فريدًا داخل الشبكة. في سياق مواقع الويب، تكون الشبكة، في معظم الأوقات، هي الإنترنت بأكمله.
هناك نوعان من عناوين IP:
-
- IPv4: هذا هو الشكل الأكثر شيوعًا لعنوان IP. يتم كتابته كمجموعة من أربعة أرقام، وتحتوي كل مجموعة على ما يصل إلى 3 أرقام. يتم فصل كل مجموعة بنقطة. يتراوح نطاق IPv4 من 0.0.0.0 إلى 255.255.255.255.
-
IPv6: هو معيار أكثر حداثة تم تطويره لحل مشكلة نفاد عناوين IPv4. يدعم IPv4 ما يصل إلى 232 عنوانًا فريدًا بينما يدعم IPv6 ما يصل إلى 2128 عنوانًا. يتم كتابة أي عنوان IPv6 بأرقام سداسية عشرية. ويمكن أن يحتوي على ما يصل إلى 32 رقمًا، مقسمة إلى 8 أقسام (4 أرقام في كل قسم). يتم فصل كل قسم بنقطتين رئيسيتين (:).
نطاق المستوى الأعلى
نطاق المستوى الأعلى (TLD اختصارًا) هو الجزء الأكثر عمومية في النطاق. وهو يشير إلى الجزء الأقصى من اليمين (مفصولاً بنقطة). تشمل بعض نطاقات المستوى الأعلى الشائعة ما يلي:
-
“com”
-
“net”
-
“org”
-
“edu”
-
“io”
-
“gov”
من حيث أسماء النطاقات، تقع هذه النطاقات في قمة التسلسل الهرمي. يمكن لـ ICANN (هيئة الإنترنت للأسماء والأرقام المخصصة) إصدار تصريح لسيطرة أطراف معينة على نطاقات المستوى الأعلى. وبموجب هذا الإذن، يمكن لهذه الأطراف توزيع أسماء النطاقات تحت TLD (عادةً عبر مسجل النطاق).
-
المضيفون
في النطاق، يمكن للمالك تحديد مضيفين فرديين، مما يشير إلى أجهزة/خدمات منفصلة يمكن الوصول إليها من خلال النطاق. على سبيل المثال، من الممارسات الشائعة إتاحة الوصول إلى خوادم الويب من خلال النطاق المجرد ( example.com) وتعريف “المضيف” “www ( www.example.com).
من الممكن وجود مضيفين إضافيين تحت النطاق العام، على سبيل المثال، الوصول إلى API من خلال مضيف “api” ( api.example.com)، والوصول إلى FTP من خلال مضيف “ftp” أو “files” ( ftp.example.com أو files.example.com).
لاحظ أنه يُسمح بأن تكون أسماء النطاقات عشوائية طالما أنها فريدة داخل النطاق.
-
النطاق الفرعي
النطاق الفرعي هو موضوع متعلق بالمضيفين. يعمل DNS في تسلسل هرمي. يمكن أن يحتوي TLD على العديد من النطاقات تحته. على سبيل المثال، “ example.com”, “ cloudsigma.com”، وما إلى ذلك، تقع جميعها تحت نطاق المستوى الأعلى “com”. وفي هذا الصدد، فإن النطاق الفرعي هو إشارة إلى أي نطاق يمثل جزءًا من النطاق المستهدف. وبالتالي، يمكننا القول إن “example.com” هو نطاق فرعي لـ “com”. وبشكل عام، يُشار إلى جزء “example” باسم SLD (نطاق المستوى الثاني).
وبالمثل، يمكن للنطاق التحكم في جميع “النطاقات الفرعية” الواقعة تحته. وهذا عادةً ما يُستخدم مصطلح “النطاق الفرعي” للإشارة إليه. على سبيل المثال، “ history.example.com” هو نطاق فرعي لـ “ example.com”.
الفرق الرئيسي بين اسم المضيف والنطاق الفرعي هو أن المضيف يحدد جهاز كمبيوتر/موردًا بينما يوسع النطاق الفرعي النطاق الأب. كلما تحدثنا عن النطاقات الفرعية أو المضيفين، يمكنك التأكد من ذلك من خلال النظر إلى الجزء الأقصى من اليسار في النطاق لأنه الأكثر تحديدًا. هذه هي طريقة عمل DNS: من الأكثر تحديدًا (الجانب الأقصى من اليسار) إلى الأقل تحديدًا (الجانب الأقصى من اليمين).
-
اسم النطاق المؤهل بالكامل
يشير اسم النطاق المؤهل بالكامل (FQDN اختصارًا) إلى اسم نطاق مطلق. في نظام DNS، يمكن إعطاء النطاقات بالنسبة لبعضها البعض. قد يؤدي هذا إلى بعض الغموض. ومع ذلك، فإن FQDN هو اسم مطلق يشير إلى الجذر المطلق لنظام أسماء النطاقات.
هذا يعني أن FQDN يحدد كل نطاق أب بما في ذلك TLD. ومثال مناسب على ذلك سيكون “ mail.google.com”. وفي حالات معينة، قد لا ينتهي FQDN بنقطة ولكن يجب أن يحتوي على نقطة لاحقة (مطلوبة بموجب معايير ICANN).
-
خادم الأسماء
خادم الأسماء هو كمبيوتر مخصص لترجمة أسماء النطاقات إلى عناوين IP. وتتحمل خوادم الأسماء معظم الأحمال في نظام DNS. ونظرًا لأن العدد الإجمالي لطلبات ترجمة النطاقات كبير جدًا بحيث لا يمكن لخادم واحد التعامل معه، فغالبًا ما يتم إعادة توجيه الطلبات إلى خوادم أسماء أخرى لتخفيف الضغط.
يمكن أن يكون خادم الأسماء “مخوَّلًا”، مما يعني أنه يقدم إجابات فقط للاستعلامات المتعلقة بالنطاقات الخاضعة لسيطرته. ويمكن لمثل هذه الخوادم ترحيل الطلب إلى خوادم أسماء أخرى أو تقديم نسخة مخبأة من بيانات خوادم الأسماء الأخرى.
-
ملف المنطقة
ملف المنطقة هو ملف نصي يحتوي على عمليات المطابقة بين أسماء النطاقات وعناوين IP. وهو بمثابة قاعدة بيانات لنظام DNS. هذا هو الفهرس الذي يستخدمه DNS للعثور على عنوان IP الذي يجب الاتصال به عند إكمال طلب مستخدم لاسم نطاق معين.
بشكل عام، تستضيف خوادم الأسماء ملفات المنطقة وتحدد الموارد المتاحة تحت نطاق واحد. ويمكنها أيضًا الاحتفاظ بمعلومات حول المكان الذي يجب الذهاب إليه للحصول على تلك المعلومات.
-
السجلات
يتكون ملف المنطقة من سجلات عديدة. هنا، يتم تعريف السجل على أنه مطابقة واحدة بين مورد واسم. يمكن أن تكون السجلات عبارة عن مطابقة اسم نطاق لعنوان IP، أو موارد متاحة تحت نطاق معين، أو مراجع لأماكن للحصول على المعلومات.
نظام DNS قيد العمل
حتى الآن، تعرفنا على بعض المصطلحات الشائعة المتعلقة بنظام DNS. ومع ذلك، كيف يعمل النظام بالفعل؟ قد يبدو النظام بسيطًا للغاية من منظور عام. ومع ذلك، فإن التعمق في التفاصيل سيكشف عن تعقيده الحقيقي. وبشكل عام، يعد نظام DNS مهمًا للانتشار الواسع للإنترنت.
-
خوادم الجذر
يعمل DNS، في جوهره، ضمن تسلسل هرمي. وفي قمة النظام توجد “خوادم الجذر”. وتخضع هذه الخوادم لسيطرة منظمات مختلفة. ويتم تفويض سلطة هذه الخوادم من قِبل ICANN.
حتى الآن، هناك حوالي 13 خادم جذر قيد التشغيل. ونظرًا للحمل، يتم عمل نسخ متطابقة لكل من هذه الخوادم. ومن المهم ملاحظة أن جميع الخوادم المتطابقة تشترك في نفس عنوان IP الخاص بخادم الجذر. وكلما تم تقديم أي طلب إلى خادم الجذر، يتم إعادة توجيه الطلب إلى أقرب نسخة متطابقة من ذلك الخادم.
ما هي وظائف خوادم الجذر؟ إنها تقدم معلومات حول نطاقات المستوى الأعلى. وكلما فشل خادم أسماء من مستوى منخفض في حل طلب ما، يتم إعادة توجيهه إلى خادم الجذر الخاص بالنطاق.
ومع ذلك، فإن خادم الجذر لا يعرف في الواقع موقع النطاق. بل يقوم فقط بإعادة توجيه الطلب الذي سيتعامل مع نطاق المستوى الأعلى المطلوب تحديدًا. على سبيل المثال، إذا تم تقديم طلب لـ “ blog.cloudsigma.com”، فلن يكون لدى خادم الجذر هذا الطلب في سجلاته. سيبحث في ملفات المنطقة الخاصة به ولكن لن يكون هناك أي سجل له. بدلاً من ذلك، سيتعرف على نطاق المستوى الأعلى “com” ويعيد توجيه الجهة الطالبة إلى خادم الأسماء الذي يتعامل مع عناوين “com”.
-
خوادم نطاقات المستوى الأعلى (TLD)
استمرارًا لمثالنا السابق، ستقوم الجهة الطالبة الآن بإرسال الطلب إلى عنوان IP (الذي قدمه خادم الجذر). في حالة “ blog.cloudsigma.com”، سيبحث خادم أسماء “com” في سجلاته في ملفات المنطقة الخاصة به.
لن يكون هناك سجل مطابق للطلب. ومع ذلك، سيجد سجلاً يسرد عنوان IP لخادم الأسماء المسؤول عن “ cloudsigma.com”.
-
خادم أسماء على مستوى النطاق
الآن، تمتلك الجهة الطالبة عنوان IP لخادم الأسماء الذي يستضيف بالفعل المعلومات حول “ blog.cloudsigma.com”. وسيقوم الآن بإرسال طلب جديد إلى الخادم، يطلب فيه تحليل “www.cloudsigma.com”.
تمامًا كما حدث من قبل، سيتحقق خادم الأسماء من ملفات المنطقة الخاصة به ويعثر على الملف المرتبط بـ “ cloudsigma.com”. وداخل هذا الملف سيكون هناك إدخال للمضيف “www”. يصف هذا السجل مكان وجود المضيف. ثم يتم نقل الإجابة النهائية إلى الجهة الطالبة.
-
خادم أسماء التحليل
في المثال، ذكرنا جهة طالبة. ما هي؟ في معظم الحالات، سيكون الطالب هو “خادم أسماء التحليل”. وهو خادم تم تكوينه لطرح الأسئلة على خوادم أخرى. وهو يعمل كخادم وسيط للمستخدمين. ويقوم بتخزين النتائج مؤقتًا لتحسين السرعة.
عادةً ما يكون لدى أي مستخدم خادما أسماء تحليل أو أكثر تم تكوينهما على نظامه. وبشكل عام، يتم تقديم خوادم أسماء التحليل من قِبل مزود خدمة الإنترنت (ISP) أو مؤسسات أخرى. على سبيل المثال، Google تقدم خوادم DNS عامة للتحليل للاستعلام منها. يمكنك تكوينها يدويًا على نظامك.
عند إدخال عنوان URL في متصفح الويب، فإنه يبحث عن موقع المورد. أولاً، يتم إجراء البحث محليًا. يتضمن ذلك ملف “hosts” (وبعض المواقع الأخرى). وإذا لم يتم العثور عليه، فسيتم إرسال الطلب إلى خادم أسماء التحليل. بعد تلقي الطلب، يبحث خادم أسماء التحليل في ذاكرة التخزين المؤقت الخاصة به عن الإجابة. وإذا لم يتم العثور عليها، فإنه يمر بالخطوات المذكورة سابقًا.
تسهل خوادم أسماء التحليل عملية الطلب للمستخدم النهائي. ما على العميل سوى سؤال خوادم أسماء التحليل عن موقع المورد. وسيقوم خادم الأسماء بالتقصي وإرجاع الإجابة النهائية.
-
ملفات المنطقة
لقد ناقشنا بالفعل مفاهيم “ملفات المنطقة” و“السجلات”. حسنًا، كيف تعمل؟
تعمل ملفات المنطقة كقاعدة بيانات لخوادم الأسماء، حيث تخزن معلومات حول النطاقات التي تعرفها. سيتم تخزين جميع النطاقات التي يعرفها خادم الأسماء في ملف المنطقة الخاص به. ومع ذلك، فإن معظم الطلبات الواردة إلى خادم الأسماء لا يتم تحليلها بواسطة ملف المنطقة. إذا كان تكوين الخادم هو معالجة الاستعلامات المتكررة (خوادم أسماء التحليل، على سبيل المثال)، فسيقوم بإرجاع الإجابة. وإلا، فإنه سيعيد توجيه الطرف الطالب إلى مكان آخر للبحث فيه بعد ذلك.
كلما زاد عدد ملفات المنطقة التي يستضيفها خادم الأسماء، زادت موثوقية إجاباته. تصف ملفات المنطقة “منطقة” DNS (مجموعة فرعية من نظام تسمية DNS بأكمله). بشكل عام، يحتوي ملف المنطقة على بيانات التكوين لنطاق واحد فقط. ويمكن أن يحتوي على سجلات عديدة تحدد موقع موارد النطاق المعني.
إن معلمة $ORIGIN الخاصة بالمنطقة تساوي أعلى مستوى من الصلاحية للمنطقة. على سبيل المثال، ملف المنطقة لـ “ cloudsigma.com” سيكون لها $ORIGIN كـ “ cloudsigma.com”. يمكن تخزين قيمة المعلمة في بداية ملف المنطقة أو في تكوين خادم DNS. وفي كلتا الحالتين، تصف المعلمة المنطقة التي يعتبر الملف موثوقًا بها.
إن $TTL تحدد معلمة معلومات “وقت البقاء” للنتيجة التي توفرها. ويمكن وصفها بأنها مؤقت يمكن لخادم التخزين المؤقت استخدامه لتتبع صلاحية الإجابات المخزنة مؤقتًا. إذا انتهت قيمة TTL، فلن تعد الإجابة صالحة ويتم تجاهلها.
-
أنواع السجلات
تتكون ملفات المنطقة من سجلات عديدة. والآن، هناك أنواع مختلفة من السجلات. بعد ذلك، سنستعرض بعضًا من أكثر أنواع السجلات شيوعًا (وإلزامية):
سجلات SOA
يعد سجل بدء الصلاحية (أو SOA باختصار) إلزاميًا في جميع ملفات المنطقة. ويجب أن يكون أول سجل حقيقي في الملف. ومع ذلك، يُسمح لمدخلات مثل $ORIGIN أو $TTL بالظهور مسبقًا.
يعد سجل SOA أحد أكثر أنواع السجلات تعقيدًا. ويبدو هيكله كالتالي تقريبًا:
|
1 2 3 4 5 6 7 |
example.com. IN SOA ns1.example.com. admin.example.com. ( 12083 ; <serial_number> 3h ; <refresh_interval> 30m ; <retry_interval> 3w ; <expiry_time> 1h ; <negative_TTL> ) |
دعونا نقوم بتفكيكه:
-
- example.com: يحدد هذا الجزء أصل المنطقة. في هذا المثال، ملف المنطقة مخصص للنطاق “ example.com”. في بعض الأحيان، قد يتم استبدال القيمة بـ @ (نائب لاستبدال قيمة $ORIGIN).
-
IN SOA: يعني المصطلح “IN” “الإنترنت”. ستجده في العديد من السجلات. ويشير المصطلح “SOA” إلى أنه سجل SOA.
-
ns1.example.com: تحتوي هذه القيمة على خادم الأسماء الرئيسي للنطاق “ example.com”. يمكن أن تكون خوادم الأسماء إما رئيسية أو ثانوية. إذا تم تكوينها باستخدام نظام DNS الديناميكي، فيجب أن يكون هناك خادم “رئيسي” واحد. وإذا لم يتم تكوين نظام DNS ديناميكي، فسيكون أحد خوادم الأسماء الرئيسية.
-
admin.example.com: يوضع عنوان البريد الإلكتروني لمسؤول المنطقة هنا. لاحظ أن @ يتم استبداله بـ . هنا. إذا كان عنوان البريد الإلكتروني الأصلي يحتوي على نقطة، فسيتم استبدالها بـ \. على سبيل المثال، “ my.domain@example.com” ستصبح “ my\domain.example.com”.
-
12083: هو الرقم التسلسلي لملف المنطقة. في كل مرة يتم فيها تعديل ملف المنطقة، يجب تحديث الرقم لينتشر الملف بشكل صحيح. تستخدم الخوادم الثانوية هذا الرقم التسلسلي لتتبع ما إذا كانت ملفات المنطقة الخاصة بها محدثة.
-
3h: يمثل فترة التحديث للمنطقة. ستنتظر الخوادم الثانوية هذه المدة الزمنية قبل التحقق من تحديثات ملف المنطقة.
-
30m: تمثل هذه القيمة فترة إعادة المحاولة للمنطقة. إذا فشل خادم ثانوي في الاتصال بالخادم الرئيسي بمجرد انتهاء فترة التحديث، فسينتظر هذه المدة الزمنية قبل الاستعلام من الخادم الرئيسي مرة أخرى.
-
3w: تمثل هذه القيمة فترة انتهاء الصلاحية. إذا فشل خادم ثانوي في الاتصال بالخادم الرئيسي لهذه المدة الزمنية، فسيتوقف عن إرجاع الاستجابات كـ “موثوقة”.
-
1h: تمثل هذه القيمة مقدار الوقت الذي سيقوم فيه خادم الأسماء بتخزين خطأ الاسم مؤقتًا إذا لم يتم العثور عليه في ملف المنطقة الخاص به.
سجلات A و AAAA
تنشئ هذه السجلات خريطة بين المضيف وعنوان IP. هنا، يشير سجل “A” إلى تعيين IPv4 للمضيف وAAAA إلى تعيين IPv6.
هذا هو الهيكل الأساسي لسجلات A و AAAA:
|
1 2 |
<host> IN A <IPv4_address> <host> IN AAAA <IPv6_address> |
في مثال سجل SOA، أطلقنا على خادم الأسماء اسم “ ns1.exampel.com”. يقع خادم الأسماء تحت النطاق “ example.com”. وإليك كيف سيبدو سجل A الخاص به:
|
1 |
ns1 IN A 111.222.111.222 |
لاحظ أننا لم نضطر إلى تقديم الاسم الكامل. فباستخدام اسم المضيف فقط (بدون FQDN)، يمكن لخادم DNS ملء الباقي بالقيمة من $ORIGIN. ومع ذلك، لا يزال بإمكاننا استخدام FQDN:
|
1 |
ns1.example.com. IN A 222.111.222.111 |
إليك كيفية تعريف خادم الويب كـ “www”:
|
1 |
www IN A 111.111.111.111 |
يجب علينا أيضًا تضمين ربط النطاق الأساسي. سيبدو الإدخال كالتالي:
|
1 |
example.com. IN A 222.222.222.222 |
بدلاً من ذلك، يمكننا استخدام @ الرمز للإشارة إلى النطاق الأساسي (بدلاً من اسمه الكامل):
|
1 |
@ IN A 222.222.222.222 |
من الممارسات الجيدة تضمين إدخال رمز تعميم (wildcard) يتيح خيار تحليل أي شيء تحت هذا النطاق لم يتم تعريفه بشكل صريح:
|
1 |
* IN A 222.222.222.222 |
تنطبق البنية نفسها على سجلات AAAA. الاختلاف الوحيد هو عناوين IPv6.
سجلات CNAME
تعمل سجلات CNAME كاسم مستعار للاسم الأساسي (canonical name) للخادم (المحدد بواسطة سجل A أو AAAA). ألقِ نظرة على المثال التالي:
|
1 2 |
server1 IN A 111.111.111.111 www IN CNAME server1 |
هنا، استخدمنا “server1” كاسم مستعار لتعريف الاسم “www”. لاحظ أن مثل هذه الاختصارات تأتي مع تكاليف في الأداء حيث يتعين على الخادم تشغيل استعلامات إضافية للحصول على الإجابة النهائية. اعتمادًا على عدد طبقات الأسماء المستعارة، يمكن أن يتسبب هذا بسهولة في تكلفة أداء كبيرة. ومع ذلك، هناك حالة محددة تستفيد من استخدام أسماء CNAME المستعارة، على سبيل المثال، توفير مورد خارج المنطقة الحالية.
سجلات MX
تحدد سجلات MX مبادلات البريد للنطاق. وهي تساعد في وصول البريد الإلكتروني إلى الخادم بشكل صحيح. وعلى عكس السجلات الأخرى، لا تقوم سجلات MX بربط مضيف بشيء ما لأنها قابلة للتطبيق على المنطقة بأكملها. ولهذا السبب تبدو سجلات MX كالتالي:
|
1 |
IN MX 10 mail.domain.com |
لاحظ أنه لا يوجد اسم مضيف في بداية الإدخال. ستلاحظ أيضًا وجود قيمة إضافية في السطر. إنها رقم التفضيل (preference number) الذي يساعد في تحديد الخادم الذي سيتم إرسال البريد إليه (في حال تم تحديد خوادم بريد متعددة). كلما انخفض الرقم، زادت الأولوية.
يجب أن يشير سجل MX إلى مضيف محدد بواسطة سجل A أو AAAA (وليس بواسطة CNAME). مع وضع ذلك في الاعتبار، إذا تم تكوين خادمي بريد، فستبدو السجلات كالتالي:
|
1 2 3 4 |
IN MX 10 mail1.domain.com IN MX 50 mail2.domain.com mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222 |
في هذا المثال، وبالحكم من خلال رقم التفضيل، فإن “mail1” هو الخادم المفضل على “mail2”. يمكننا تقصير الكود بشكل أكبر عن طريق حذف اسم النطاق الكامل:
|
1 2 3 4 |
IN MX 10 mail1 IN MX 50 mail2 mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222 |
سجلات NS
تحدد هذه السجلات خوادم الأسماء (nameservers) لمنطقة معينة. الآن، السؤال البديهي هو، إذا كان ملف المنطقة موجودًا داخل خادم الأسماء، فلماذا يتطلب مرجعًا لنفسه؟ أحد الإجابات على هذا السؤال هو آليات التخزين المؤقت المتعددة لنظام DNS. قد يكون ملف المنطقة في الواقع نسخة مخبأة على خوادم أخرى.
على غرار سجلات MX، تنطبق سجلات NS على المنطقة بأكملها. وبالتالي، ليس لديها أي مضيف محدد بشكل افتراضي. ستبدو إدخالات سجل NS كالتالي:
|
1 2 |
IN NS ns1.domain.com. IN NS ns2.domain.com. |
يوصى بتحديد خادمي أسماء في حالة فشل أحد الخوادم في العمل بشكل صحيح. علاوة على ذلك، ستعمل معظم خوادم DNS على رفض ملف المنطقة إذا كان يحتوي على خادم أسماء واحد فقط.
يجب عليك أيضًا تضمين ربط المضيفين بسجلات A أو AAAA:
|
1 2 3 4 |
IN NS ns1.domain.com IN NS ns2.domain.com ns1 IN A 111.222.111.111 ns2 IN A 123.211.111.233 |
سجلات PTR
سجلات PTR هي عكس سجلات A أو AAAA الكلاسيكية. تُستخدم هذه السجلات لتحديد اسم مرتبط بعنوان IP. تتميز هذه السجلات بخاصية فريدة وهي أنها تبدأ عند .arpa الجذر وتمثل مالك عنوان IP. إنها سجلات الإنترنت الإقليمية (RIRs) التي توزع عناوين IP على المؤسسات ومزودي الخدمة. وتشمل سجلات RIR كل من APNIC و AFRINIC و LACNIC و RIPE NCC و ARIN.
على سبيل المثال، سجل PTR لـ 111.222.333.444 سيبدو كالتالي:
|
1 |
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com |
في مثال سجل PTR التالي، ألقِ نظرة على خادم DNS لـ IPv6 الخاص بـ Google’s 2001:4860:4860::8888:
|
1 |
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com |
يمكننا استخدام أداة dig مع العلامة -x للبحث عن اسم DNS العكسي لعنوان IP. على سبيل المثال، تحقق من عنوان IP لـ DNS العكسي لـ 8.8.4.4:
|
1 |
dig -x 8.8.4.4 |
تستخدم خوادم الإنترنت سجلات PTR لتتبع أسماء النطاقات في إدخالات السجل، واتخاذ قرارات مدروسة للتعامل مع الرسائل العشوائية، وعرض معلومات سهلة القراءة حول الأجهزة الأخرى.
ستبحث خوادم البريد الإلكتروني الشائعة الاستخدام عن سجل PTR لعنوان IP الذي تم إرسال البريد الإلكتروني منه. إذا كان سجل PTR فارغًا، فهناك احتمال كبير بأن يكون البريد الإلكتروني رسالة عشوائية (وبالتالي يتم رفضه). لاحظ أن وجود تطابق بين FQDN واسم نطاق سجل PTR ليس هو مكمن القلق. العامل المهم هو ما إذا كان سجل PTR صالح مرتبطًا بسجل A الأمامي المطابق والمقابل له.
بشكل عام، تمتلك أجهزة توجيه الشبكة على الإنترنت سجلات PTR تتوافق مع موقعها الجغرافي. على سبيل المثال، تُعد “NYC” أو “CHI” مراجع صالحة لأجهزة التوجيه الموجودة في نيويورك وشيكاغو. هذه التقنية مفيدة عند إجراء traceroute أو MTR ومراجعة المسار الذي تسلكه الحزم.
سجلات CAA
تحدد هذه السجلات الجهات المصدقة للشهادات (CAs) التي يمكنها إصدار شهادات SSL/TLS لنطاقك. منذ 8 سبتمبر 2017، يُطلب من جميع الجهات المصدقة (CAs) التحقق من سجلات CAA قبل إصدار الشهادة. في حالة عدم وجود سجل CA، يجوز لأي جهة مصدقة إصدار شهادة. بخلاف ذلك، يُسمح فقط لجهات مصدقة محددة بإصدار الشهادات. يمكن تطبيق سجلات CAA إما على مضيفين فرديين أو على نطاق بأكمله.
إليك مثال على سجل CAA:
|
1 |
example.com. IN CAA 0 issue "letsencrypt.org" |
الجزء الخاص بـ CAA في الإدخال هو 0 issue "letsencrypt.org". هناك ثلاثة أجزاء يتضمنها هذا القسم:
- العلامات (Flags): إنها قيمة عددية صحيحة تشير إلى كيفية تعامل الجهة المصدقة (CA) مع العلامات التي لا تفهمها. إذا تم تعيين قيمة العلامة إلى 0، فسيتم تجاهل السجل. إذا كانت القيمة 1، فيجب على الجهة المصدقة رفض إصدار الشهادة.
- الوسوم (Tags): هذه سلاسل نصية تشير إلى الغرض من سجل CAA. حتى الآن، تشمل القيم الصالحة issue (تخويل جهة مصدقة لإصدار شهادات لنطاق معين)، issuewild (تخويل شهادات البدل wildcard)، و iodef تحديد عنوان URL حيث تبلغ الجهات المصدقة عن انتهاكات السياسة).
- القيم (Values): هذه سلاسل نصية مرتبطة بوسم السجل. إذا كان الوسم هو issue أو issuewild، فستكون القيمة عادةً هي نطاق الجهة المصدقة التي تمنحها الإذن. إذا كان الوسم هو iodef، فسيكون عنوان URL لنموذج اتصال أو mailto: رابط لإرسال الملاحظات عبر البريد الإلكتروني.
يمكننا استخدام أداة dig لجلب سجلات CAA:
|
1 |
dig example.com type257 |
لمزيد من المعلومات التفصيلية حول سجلات CAA، راجع RFC 6844.
أفكار نهائية
يصف هذا الدليل المصطلحات المختلفة المتعلقة بنظام DNS. كما يصف كيفية ترابط جميع المكونات معًا. مع وضع هذه النظرة الشاملة في الاعتبار، يجب أن يكون لديك فهم جيد لوظائف نظام DNS. في حين أن الفكرة العامة بسيطة وسهلة الفهم، إلا أن التفاصيل الدقيقة تصبح معقدة بسرعة كبيرة. بالنسبة للمسؤولين عديمي الخبرة، قد يكون من الصعب تطبيق هذه المفاهيم والاستراتيجيات.
هل أنت عميل لـ CloudSigma؟ إذًا تحقق من إدارة وتحديث سجلات DNS/PTR العكسية للبنية التحتية الخاصة بك في CloudSigma.
حوسبة سعيدة!
التعليقات
لا توجد تعليقات بعد. كن أول من يعلق.