مقدمة
نظام أسماء النطاقات، أو DNS، غالبًا ما يكون جزءًا صعبًا جدًا من تعلم كيفية تكوين مواقع الويب والخوادم. فهم كيفية عمل DNS سيساعدك على تشخيص المشاكل في تكوين الوصول إلى مواقع الويب الخاصة بك وسيسمح لك بتوسيع فهمك لما يحدث خلف الكواليس.
في هذا الدليل، سنناقش بعض المفاهيم الأساسية لنظام أسماء النطاقات التي ستساعدك في البدء السريع مع تكوين DNS الخاص بك. بعد التغلب على هذا الدليل، يجب أن تكون جاهزًا لـ إعداد اسم النطاق الخاص بك مع DigitalOcean أو إعداد خادم DNS الخاص بك بنفسك.
قبل أن نقوم بإعداد الخوادم الخاصة بك لحل نطاقك أو إعداد نطاقاتنا في لوحة التحكم، دعنا نستعرض بعض المفاهيم الأساسية حول كيفية عمل كل هذا في الواقع.
مصطلحات النطاق
يجب أن نبدأ بتحديد مصطلحاتنا. بينما قد تكون بعض هذه المواضيع مألوفة من سياقات أخرى، هناك العديد من المصطلحات المستخدمة عند الحديث عن أسماء النطاقات و DNS التي لا تستخدم كثيرًا في مجالات أخرى من الحوسبة.
لنبدأ بسهولة:
نظام اسم النطاق
نظام اسم النطاق، المعروف بشكل أكبر باسم “DNS”، هو النظام الشبكي الموجود الذي يتيح لنا حل الأسماء المفهومة للإنسان إلى عناوين IP فريدة.
اسم النطاق
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
عنوان URL “google.com” مرتبط بخوادم تمتلكها شركة Google Inc. يتيح لنا نظام اسم النطاق الوصول إلى خوادم Google عند كتابة “google.com” في متصفحاتنا.
عنوان IP
عنوان IP هو ما نسميه بموقع قابل للوصول عبر الشبكة. يجب أن يكون كل عنوان IP فريدًا ضمن شبكته. عندما نتحدث عن المواقع الإلكترونية، فإن هذه الشبكة هي الإنترنت بأكمله.
تُكتب عناوين IPv4، الأكثر شيوعًا، على شكل أربع مجموعات من الأرقام، وكل مجموعة تحتوي على ما يصل إلى ثلاثة أرقام، مع فصل كل مجموعة بنقطة. على سبيل المثال، يمكن أن يكون “111.222.111.222” عنوان IP IPv4 صالحًا. مع DNS، نقوم بتعيين اسم لهذا العنوان بحيث لا يتعين عليك تذكر مجموعة معقدة من الأرقام لكل مكان ترغب في زيارته على الشبكة.
نطاق المستوى الأعلى
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
النطاقات الرئيسية في القمة من أعلى الهرم من حيث أسماء النطاقات. يتم منح بعض الأطراف السيطرة على إدارة النطاقات الرئيسية عن طريق ICANN (الشركة الدولية لتخصيص الأسماء والأرقام على الإنترنت). يمكن لهذه الأطراف بعد ذلك توزيع أسماء النطاقات تحت TLD، عادة من خلال مسجل النطاقات.
المضيفون
ضمن نطاق معين، يمكن لمالك النطاق تعريف المضيفين الفرديين، والذين يشير كل منهم إلى أجهزة كمبيوتر أو خدمات منفصلة يمكن الوصول إليها من خلال النطاق. على سبيل المثال، يجعل معظم مالكي النطاقات خوادمهم عبر النطاق العاري (example.com) وأيضًا من خلال تعريف “المضيف” “www” (www.example.com).
يمكنك أن تمتلك تعريفات مضيف أخرى ضمن النطاق العام. يمكنك الحصول على وصول إلى واجهة برمجة التطبيقات عبر مضيف “api” (api.example.com) أو يمكنك الحصول على وصول إلى خدمة نقل الملفات عن طريق تعريف مضيف يسمى “ftp” أو “files” (ftp.example.com أو files.example.com). يمكن أن تكون أسماء المضيفين تعسفية طالما كانت فريدة للنطاق.
النطاق الفرعي
A subject related to hosts are subdomains.
يعمل DNS بتسلسل هرمي. يمكن أن تحتوي TLDs على العديد من النطاقات تحتها. على سبيل المثال، لــ “com” TLD تحتها كل من “google.com” و “ubuntu.com”. يشير “subdomain” إلى أي نطاق يكون جزءًا من نطاق أكبر. في هذه الحالة، يمكن القول أن “ubuntu.com” هو subdomain من “com”. عادةً ما يُشار إليه باسم النطاق أو يُسمى الجزء “ubuntu” SLD، والذي يعني النطاق من المستوى الثاني.
بالمثل، يمكن لكل نطاق التحكم في “subdomains” الموجودة تحته. عادةً ما نعني بها الsubdomains. على سبيل المثال يمكنك أن تمتلك subdomain لقسم التاريخ في مدرستك على “www.history.school.edu”. الجزء “history” هو subdomain.
الفرق بين اسم المضيف و subdomain هو أن المضيف يحدد جهاز الكمبيوتر أو المورد، بينما يمتد subdomain إلى النطاق الأصلي. إنها طريقة لتقسيم النطاق نفسه.
سواء كنت تتحدث عن subdomains أو hosts، يمكنك أن تبدأ في رؤية أن الأجزاء الأكثر يسارًا من النطاق هي الأكثر تحديدًا. هذه هي طريقة عمل DNS: من الأكثر تحديدًا إلى الأقل تحديدًا أثناء القراءة من اليسار إلى اليمين.
اسم النطاق المؤهل بالكامل
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
هذا يعني أنه يحدد كل نطاق أبوي بما في ذلك TLD. FQDN صحيح ينتهي بنقطة، مشيراً إلى جذر تسلسل الأسماء في نظام أسماء النطاقات. مثال على FQDN هو “mail.google.com.“. في بعض الأحيان، البرمجيات التي تطلب FQDN لا تتطلب النقطة النهائية، ولكن النقطة العائمة مطلوبة للامتثال لمعايير ICANN.
خادم الأسماء
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
يمكن أن تكون خوادم الأسماء “مخولة”، مما يعني أنها تقدم إجابات للاستفسارات حول النطاقات تحت سيطرتها. في حال عدم ذلك، قد تشير إلى خوادم أخرى، أو تقدم نسخًا مخزنة من بيانات خوادم أسماء أخرى.
ملف المنطقة
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
تتواجد ملفات المناطق في خوادم الأسماء وتعرف عادة الموارد المتاحة تحت نطاق معين، أو المكان الذي يمكن للشخص الذهاب إليه للحصول على تلك المعلومات.
السجلات
داخل ملف المنطقة، يتم الاحتفاظ بالسجلات. في أبسط شكل لها، تعد السجلات أساسًا تعيينًا فرديًا بين مورد واسم. يمكن أن تقوم هذه السجلات بتعيين اسم نطاق إلى عنوان IP، أو تعريف خوادم الأسماء للنطاق، أو تعريف خوادم البريد للنطاق، إلخ.
كيف يعمل نظام DNS
الآن بعد أن أصبحت ملمًا ببعض المصطلحات المتعلقة بـ DNS، كيف يعمل النظام فعليًا؟
النظام بسيط جدًا عند النظر السريع، ولكنه معقد جدًا عند النظر في التفاصيل. عمومًا، إنه بنية تحتية موثوقة للغاية ولا غنى عنها لتبني الإنترنت كما نعرفه اليوم.
الخوادم الجذرية
كما ذكرنا أعلاه، يعتبر DNS في جوهره نظامًا تسلسليًا. في أعلى هذا النظام توجد ما يُعرف بـ “الخوادم الجذرية”. يتحكم في هذه الخوادم مختلف المنظمات وتتم تفويض سلطتها من قبل ICANN (الشركة الدولية لتعيين الأسماء والأرقام على الإنترنت).
يوجد حاليًا 13 خادمًا جذريًا في العمل. ومع ذلك، نظرًا لوجود عدد لا يصدق من الأسماء التي يتعين حلها كل دقيقة، فإن كل هذه الخوادم تكون معادية فعليًا. الشيء المثير للاهتمام في هذا النظام هو أن كل من مرايا خادم جذري واحدة تشترك في نفس عنوان IP. عندما يتم تقديم طلبات لخادم جذري معين، سيتم توجيه الطلب إلى المرآة الأقرب لهذا الخادم الجذري.
ما الذي تقوم به هذه الخوادم الجذرية؟ الخوادم الجذرية تتعامل مع طلبات المعلومات حول النطاقات الأعلى في التسلسل الهرمي. لذا، إذا تم إرسال طلب لمعلومات لا يمكن لخادم اسم مستوى أدنى حله، يتم إجراء استعلام إلى الخادم الجذري للنطاق.
لا تعرف الخوادم الجذرية بالفعل مكان استضافة النطاق. ومع ذلك، سيكون بإمكانها توجيه الطالب إلى خوادم الأسماء التي تتعامل بشكل خاص مع النطاق الأعلى المطلوب بالتحديد.
لذا، إذا تم إرسال طلب لـ “www.wikipedia.org” إلى الخادم الجذري، فإن الخادم الجذري لن يجد النتيجة في سجلاته. سيتحقق من ملفات المنطقة الخاصة به عن قائمة تتطابق مع “www.wikipedia.org”. ولن يجد واحدة.
بدلاً من ذلك، سيجد سجلًا لنطاق TLD “org” وسيعطي الكيان الطالب عنوان خادم الأسماء المسؤول عن عناوين “org”.
خوادم TLD
يقوم الطالب بعد ذلك بإرسال طلب جديد إلى عنوان IP (الذي أعطاه له الخادم الجذري) الذي يتحمل مسؤولية النطاق الأعلى للطلب.
لذا، لمتابعة مثالنا، سيقوم بإرسال طلب إلى خادم الأسماء المسؤول عن معرفة النطاقات “org” لمعرفة مكان “www.wikipedia.org”.
مرة أخرى، سيراجع الطالب “www.wikipedia.org” في ملفات المنطقة الخاصة به. ولن يجد هذا السجل في ملفاته.
ومع ذلك، ستجد سجلًا يحتوي على عنوان IP لخادم الأسماء المسؤول عن “wikipedia.org“. هذا يقترب كثيرًا من الإجابة التي نريدها.
خوادم الأسماء على مستوى النطاق
في هذه المرحلة، لدى الطالب عنوان IP لخادم الأسماء المسؤول عن معرفة العنوان الفعلي للمورد. يرسل طلبًا جديدًا إلى خادم الأسماء يسأل مرة أخرى إذا كان يمكنه حل “www.wikipedia.org“.
يقوم خادم الأسماء بفحص ملفات المنطقة الخاصة به ويجد أن لديه ملف منطقة مرتبط بـ “wikipedia.org“. داخل هذا الملف، هناك سجل لمضيف “www”. يخبر هذا السجل بالعنوان IP حيث يوجد هذا المضيف. يقوم خادم الأسماء بإرجاع الإجابة النهائية إلى الطالب.
ما هو خادم الأسماء الذي يحل الأسماء؟
في السيناريو أعلاه، أشرنا إلى “الطالب”. من هو الطالب في هذا الوضع؟
في معظم الحالات، سيكون المُطلب ما نُسميه “خادم اسم تحليلي”. خادم الاسم التحليلي هو الذي يُعدَّل لطلب الاستفسارات من خوادم أخرى. ببساطة، فهو وسيط للمستخدم يقوم بتخزين نتائج الاستعلامات السابقة لتحسين السرعة ويعرف عناوين الخوادم الجذرية ليكون قادرًا على “حل” الطلبات التي يُطلب معرفتها.
ببساطة، فإن المستخدم عادة ما يكون لديه عدة خوادم اسم تحليلي مُعدَّة على نظام الكمبيوتر الخاص به. وعادةً ما يتم توفير خوادم اسم تحليلي من قِبَل مزود خدمة الإنترنت أو منظمات أخرى. على سبيل المثال، تقدم شركة جوجل خوادم DNS تحليلية يمكنك الاستفسار عنها. يمكن تكوين هذه إما تلقائيًا في جهاز الكمبيوتر الخاص بك أو يدويًا.
عندما تكتب عنوان URL في شريط العنوان لمتصفحك، يبحث جهاز الكمبيوتر أولاً لمعرفة ما إذا كان يمكنه العثور محليًا على موقع المورد. يتحقق من ملف “المضيفين” على الكمبيوتر ومن بعض المواقع الأخرى. ثم يرسل الطلب إلى خادم الاسم التحليلي وينتظر الرد لاستقبال عنوان IP للمورد.
يتحقق بعد ذلك خادم الاسم التحليلي من ذاكرته المؤقتة للإجابة. إذا لم يجدها، يقوم بمراجعة الخطوات المذكورة أعلاه.
ببساطة، يضغط خوادم الاسم التحليلي عملية الطلب للمستخدم النهائي. فالعملاء يتعين عليهم فقط معرفة طلب خوادم الاسم التحليلي لمعرفة موقع المورد والثقة بأنها ستقوم بالتحقيق وإعادة الإجابة النهائية.
ملفات المنطقة
لقد ذكرنا في العملية أعلاه فكرة “ملفات المنطقة” و “السجلات”.
ملفات المنطقة هي الطريقة التي تخزن بها خوادم الأسماء المعلومات حول النطاقات التي تعرف عنها. يتم تخزين كل نطاق يعرفه خادم الأسماء في ملف منطقة. معظم الطلبات التي تصل إلى خادم الأسماء العادي ليست شيئًا يمكن أن يكون للخادم ملفات منطقة لها.
إذا تم تكوينه للتعامل مع الاستعلامات التكرارية، مثل خادم الأسماء الحاسم، فسيجد الجواب ويعيده. وإلا، فسيخبر الطرف الطالب أين ينبغي البحث بعد ذلك.
كلما كان لدى خادم الأسماء ملفات منطقة أكثر، كلما كان قادرًا على الإجابة بشكل موثوق عن المزيد من الطلبات.
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
منشأ المنطقة هو معلم يساوي مستوى السلطة الأعلى للمنطقة افتراضيًا.
لذا، إذا تم استخدام ملف منطقة لتكوين نطاق “example.com.”، سيتم تعيين المنشأ إلى “example.com.”.
يتم تكوين هذا إما في أعلى ملف المنطقة أو يمكن تحديده في ملف تكوين خادم DNS الذي يشير إلى ملف المنطقة. وبأي حال من الأحوال، يصف هذا المعلم ما ستكون عنه المنطقة موثوقة.
بالمثل، يقوم المعلم $TTL بتكوين “وقت الحياة” للمعلومات التي يقدمها. إنه عبارة ببساطة عن مؤقت. يمكن لخادم الأسماء ذو الذاكرة المؤقتة استخدام النتائج التي تم الاستعلام عنها سابقًا للإجابة عن الأسئلة حتى ينتهي وقت الحياة.
أنواع السجلات
يمكن أن تحتوي ملفات المنطقة على العديد من أنواع السجلات المختلفة. سنتناول بعض الأنواع الأكثر شيوعًا (أو الإلزامية) هنا.
سجلات SOA
سجل بداية السلطة، أو SOA، هو سجل إلزامي في جميع ملفات المناطق. يجب أن يكون أول سجل حقيقي في الملف (على الرغم من أن تعليمات $ORIGIN أو $TTL قد تظهر أعلى منه). إنه أيضًا واحد من أصعب السجلات لفهمها.
يبدو سجل بداية السلطة مثل هذا:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
لنشرح ما هي كل جزء له:
-
domain.com.: هذا هو جذر المنطقة. يُحدد أن ملف المنطقة هو لنطاقdomain.com.. في كثير من الأحيان، سترى هذا المكان يتم استبداله بـ@، وهو مجرد علامة تعويض تحل محل محتويات المتغير$ORIGINالذي تعلمنا عنه أعلاه. -
IN SOA: الجزء “IN” يعني الإنترنت (وسيكون موجودًا في العديد من السجلات). SOA هو المؤشر على أن هذا سجل بداية السلطة.
-
ns1.domain.com.: هذا يعرف الخادم الرئيسي للأسماء لهذا النطاق. يمكن أن تكون خوادم الأسماء إما رئيسية أو ثانوية، وإذا تم تكوين DNS الديناميكي، فيجب أن يكون خادم واحد “أساسي”، والذي يتم وضعه هنا. إذا لم تكن قد قمت بتكوين DNS الديناميكي، فإن هذا مجرد أحد خوادم الأسماء الرئيسية الخاصة بك. -
admin.domain.com.: هذا هو عنوان البريد الإلكتروني للمسؤول لهذه المنطقة. يتم استبدال “@” بنقطة في عنوان البريد الإلكتروني. إذا كانت جزء الاسم من عنوان البريد الإلكتروني عادةً ما يحتوي على نقطة فيه، يتم استبدالها بـ “\” في هذا الجزء ([email protected]يصبحyour\name.domain.com). -
12083: هذا هو الرقم التسلسلي لملف المجال. في كل مرة تقوم فيها بتحرير ملف المجال، يجب عليك زيادة هذا الرقم التسلسلي ليتم انتشار ملف المجال بشكل صحيح. سيتحقق الخوادم الثانوية مما إذا كان الرقم التسلسلي للخادم الأساسي للمجال أكبر من الرقم الذي يمتلكونه في نظامهم. إذا كان كذلك، فإنها تطلب ملف المجال الجديد، إذا لم يكن كذلك، فإنها تواصل تقديم الملف الأصلي.
-
3h: هذه هي فترة التحديث للمجال. هذه هي المدة التي سينتظرها الثانوي قبل التحقق من الخادم الأساسي لتغييرات ملف المجال.
-
30 دقيقة: هذا هو فترة إعادة المحاولة لهذا النطاق. إذا لم يتمكن الثانوي من الاتصال بالرئيسي عندما ينتهي الفترة المحددة للتحديث، فسينتظر هذا المقدار من الوقت ثم يعيد المحاولة للاستفتاء على الرئيسي.
-
3 أسابيع: هذه هي فترة الانتهاء. إذا لم يتمكن خادم اسم ثانوي من الاتصال بالرئيسي لهذا الوقت، فإنه لا يعود يرد بالردود كمصدر موثوق به لهذا النطاق.
-
1 ساعة: هذا هو المقدار الزمني الذي سيحتفظ فيه خادم الأسماء بخطأ الاسم إذا لم يتم العثور على الاسم المطلوب في هذا الملف.
A and AAAA Records
كلا هذه السجلات ترتبط بمضيف إلى عنوان IP. يتم استخدام سجل “A” لربط مضيف بعنوان IP IPv4، بينما يتم استخدام سجلات “AAAA” لربط مضيف بعنوان IPv6.
التنسيق العام لهذه السجلات هو:
host IN A IPv4_address
host IN AAAA IPv6_address
لذلك، نظرًا لأن سجل SOA الخاص بنا يشير إلى خادم أساسي على “ns1.domain.com”، فسنحتاج إلى ربط هذا بعنوان IP نظرًا لأن “ns1.domain.com” تقع ضمن منطقة “domain.com” التي يقوم هذا الملف بتعريفها.
يمكن أن يبدو السجل مثل هذا:
ns1 IN A 111.222.111.222
لاحظ أنه ليس علينا أن نعطي الاسم الكامل. يمكننا فقط تقديم اسم المضيف، دون FQDN وسيقوم خادم DNS بملء الباقي باستخدام قيمة $ORIGIN. ومع ذلك، يمكننا بسهولة استخدام FQDN بالكامل إذا شعرنا بالرغبة في أن نكون دقيقين:
ns1.domain.com. IN A 111.222.111.222
في معظم الحالات، هنا حيث ستقوم بتعريف خادم الويب الخاص بك بـ “www”:
www IN A 222.222.222.222
يجب أيضًا أن نحدد أين يتم حل المجال الأساسي. يمكننا القيام بذلك بهذه الطريقة:
domain.com. IN A 222.222.222.222
كان بإمكاننا استخدام “@” للإشارة إلى المجال الأساسي بدلاً من ذلك:
@ IN A 222.222.222.222
لدينا أيضًا خيار حل أي شيء تحت هذا المجال والذي لم يُعرف بوضوح إلى هذا الخادم أيضًا. يمكننا القيام بذلك باستخدام البطاقة النمطية “*”:
* IN A 222.222.222.222
كل هذه الخيارات تعمل بنفس الكفاءة مع سجلات AAAA لعناوين IPv6.
سجلات CNAME
تعرف سجلات CNAME اسمًا بديلاً للاسم القانوني لخادمك (الذي يتم تعريفه بواسطة سجل A أو AAAA).
على سبيل المثال، يمكن أن يكون لدينا سجل اسم A يعرف المضيف “server1” ثم نستخدم “www” كاسم بديل لهذا المضيف:
server1 IN A 111.111.111.111
www IN CNAME server1
كن على علم بأن هذه الأسماء المستعارة تأتي مع بعض الخسائر في الأداء لأنها تتطلب استعلامًا إضافيًا إلى الخادم. في معظم الأحيان، يمكن تحقيق نفس النتيجة باستخدام سجلات A أو AAAA إضافية.
واحدة من الحالات التي يُوصى فيها باستخدام الاسم المستعار هي توفير اسم مستعار لمورد خارج النطاق الحالي.
سجلات MX
تُستخدم سجلات MX لتحديد تبادلات البريد التي يتم استخدامها للنطاق. يساعد ذلك في وصول رسائل البريد الإلكتروني إلى خادم البريد الخاص بك بشكل صحيح.
على عكس العديد من أنواع السجلات الأخرى، لا تقوم سجلات البريد عمومًا بتعيين مضيف لشيء ما، لأنها تنطبق على النطاق بأكمله. وبالتالي، غالبًا ما تبدو مثل هذا:
IN MX 10 mail.domain.com.
لاحظ أنه لا يوجد اسم مضيف في البداية.
كما لاحظ أنه يوجد رقم إضافي هناك. هذا هو رقم التفضيل الذي يساعد الحواسيب على تحديد أي خادم لإرسال البريد إليه في حال وجود عدة خوادم بريد محددة. الأرقام الأقل لها الأولوية.
يجب أن تشير سجلات MX بشكل عام إلى مضيف محدد بواسطة سجل A أو AAAA، وليس إلى مضيف محدد بواسطة اسم مستعار.
لذلك، دعونا نفترض أن لدينا خادمي بريد. يجب أن تكون هناك سجلات تبدو مثل هذا:
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” هو خادم تبادل البريد المفضل.
يمكننا أيضًا كتابة ذلك على النحو التالي:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
سجلات NS
نوع هذا السجل يحدد خوادم الأسماء التي يتم استخدامها لهذا النطاق.
قد تتساءل، “إذا كان ملف النطاق يتواجد على خادم الأسماء، فلماذا يحتاج إلى الإشارة إلى نفسه؟”. جزء مما يجعل DNS ناجحًا هو مستوياته المتعددة من التخزين المؤقت. أحد الأسباب لتحديد خوادم الأسماء داخل ملف النطاق هو أن ملف النطاق قد يتم تقديمه فعليًا من نسخة مخزنة على خادم أسماء آخر. هناك أسباب أخرى لضرورة تحديد خوادم الأسماء على خادم الأسماء نفسه، لكننا لن ندخل في ذلك هنا.
مثل سجلات MX، هذه هي معلمات للنطاق بأكمله، لذا فهي لا تأخذ مضيفات. بشكل عام، تبدو على النحو التالي:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
يجب أن يكون لديك ما لا يقل عن خادمي اسمين محددين في كل ملف نطاق من أجل التشغيل بشكل صحيح في حالة حدوث مشكلة مع خادم واحد. معظم برامج خوادم DNS تعتبر ملف النطاق غير صالح إذا كان هناك خادم أسماء واحد فقط.
كما هو الحال دائمًا، ضع تعيين المضيفات بسجلات A أو AAAA:
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 لتعريف اسم مرتبط بعنوان IP. تعتبر سجلات PTR العكسية لسجل A أو AAAA. تعتبر سجلات PTR فريدة من نوعها حيث تبدأ في الجذر .arpa وتُفوض إلى أصحاب عناوين الآي بي. تدير السجلات الإقليمية للإنترنت (RIRs) تفويض عناوين الآي بي للمؤسسات ومقدمي الخدمات. تشمل السجلات الإقليمية للإنترنت APNIC و ARIN و RIPE NCC و LACNIC و AFRINIC.
إليك مثال على سجل PTR لـ 111.222.333.444:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
يوضح هذا المثال لسجل PTR لعنوان IPv6 تنسيق nibble للعكس من خادم DNS IPv6 لـ Google 2001:4860:4860::8888.
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.
إليك مثال على أمر dig. يتم إضافة +short لتقليل الناتج إلى الاسم العكسي DNS.
سيكون الناتج لأمر dig أعلاه اسم المجال في سجل PTR لعنوان IP:
google-public-dns-b.google.com.
يستخدم الخوادم على الإنترنت سجلات PTR لوضع أسماء المجالات داخل سجلات السجل، واتخاذ قرارات معلوماتية حول التعامل مع البريد العشوائي، وعرض تفاصيل سهلة القراءة حول الأجهزة الأخرى.
معظم خوادم البريد الإلكتروني المستخدمة بشكل شائع ستبحث عن سجل PTR لعنوان IP الذي تتلقى منه البريد الإلكتروني. إذا لم يكن لعنوان IP المصدري سجل PTR مرتبط به، فقد يتم معاملة الرسائل الصادرة على أنها رسائل غير مرغوب فيها ورفضها. ليس من الأهمية أن يتطابق FQDN في سجل PTR مع اسم النطاق للبريد الإلكتروني الذي يتم إرساله. ما هو مهم هو وجود سجل PTR صالح مع سجل A متوافق ومطابق.
عادةً ما يتم تعيين سجلات PTR لموجهات الشبكة على الإنترنت بحيث تتطابق مع موقعها الفعلي. على سبيل المثال، قد ترى إشارات إلى “NYC” أو “CHI” لموجه في مدينة نيويورك أو شيكاغو. يكون هذا مفيدًا عند تشغيل عمليات تتبع المسار أو MTR واستعراض مسار حركة المرور عبر الإنترنت.
معظم مزودي خوادم مخصصة أو خدمات VPS سيمنحون العملاء القدرة على تعيين سجل PTR لعنوان IP الخاص بهم. سوف تقوم DigitalOcean تلقائيًا بتعيين سجل PTR لأي Droplet عندما يتم تسمية الـ Droplet بواسطة اسم نطاق. يتم تعيين اسم الـ Droplet أثناء الإنشاء ويمكن تعديله لاحقًا باستخدام صفحة الإعدادات في لوحة تحكم الـ Droplet.
ملاحظة: من المهم أن يكون لدى FQDN في سجل PTR سجل A متوافق ومطابق. مثال: 111.222.333.444 لديه PTR لـ server.example.com و server.example.com هو سجل A الذي يشير إلى 111.222.333.444.
سجلات CAA
تستخدم سجلات CAA لتحديد أي سلطات الشهادات (CAs) مسموح لها بإصدار شهادات SSL/TLS لنطاقك. اعتبارًا من 8 سبتمبر 2017 ، يتعين على جميع CAs التحقق من هذه السجلات قبل إصدار الشهادة. إذا لم يكن هناك سجل موجودًا ، يمكن لأي CA إصدار شهادة. وإلا ، فقط يمكن للCAs المحددة إصدار الشهادات. يمكن تطبيق سجلات CAA على مضيف واحد أو على نطاقات كاملة.
يتبع مثال لسجل CAA:
example.com. IN CAA 0 issue "letsencrypt.org"
المضيف، IN، ونوع السجل (CAA) هي حقول DNS شائعة. المعلومات الخاصة بـ CAA أعلاه هي الجزء 0 issue "letsencrypt.org". يتكون من ثلاثة أجزاء: العلامات (issue) والقيم ("letsencrypt.org").
- العلامات هي عدد صحيح يشير إلى كيفية معالجة CA للعلامات التي لا تفهمها. إذا كانت العلامة
0، فسيتم تجاهل السجل. إذا كانت1، يجب على CA رفض إصدار الشهادة. - العلامات هي سلاسل تدل على غرض سجل CAA. يمكن أن تكون حاليًا
issueلتخول CA بإنشاء شهادات لاسم مضيف محدد،issuewildلتخول الشهادات البديلة، أوiodefلتحديد عنوان URL حيث يمكن للCA أن تبلغ عن انتهاكات السياسة. - القيم هي سلسلة مرتبطة بوسم السجل. بالنسبة للـ
issueوissuewild، سيكون هذا عادةً نطاق السلطة الشهادة التي تمنحها الإذن لها. بالنسبة لـiodef، قد يكون هذا عنوان URL لنموذج اتصال، أو رابطmailto:للردود عبر البريد الإلكتروني.
يمكنك استخدام dig لاسترداد سجلات CAA باستخدام الخيارات التالية:
لمزيد من المعلومات التفصيلية حول سجلات CAA، يمكنك قراءة RFC 6844، أو البرنامج التعليمي الخاص بنا كيفية إنشاء وإدارة سجلات CAA باستخدام DNS DigitalOcean
الاستنتاج
يجب أن تكون الآن لديك فهم جيد لكيفية عمل DNS. بينما فكرة العمل العامة نسبيا سهلة بمجرد أن تصبح على دراية بالاستراتيجية، إلا أن هذا لا يزال شيئًا يمكن أن يكون صعبًا بالنسبة للمسؤولين غير المتمرسين في تطبيقها.
للحصول على نظرة عامة، راجع كيفية إعداد النطاقات داخل لوحة التحكم DigitalOcean.