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

📅 آخر تحديث: ٢٢ يوليو ٢٠٢٦
✍️ نُشر في: ٢٢ يوليو ٢٠٢٦
📷 يحتوي على 3 صور
الموسوعة الحرة

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

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

يُدير الإنترنت نطاقين رئيسيين للأسماء ، وهما تسلسل أسماء النطاقات ونطاقات عناوين IP . [ 3 ] يتولى نظام أسماء النطاقات (DNS) إدارة تسلسل أسماء النطاقات، ويُقدّم خدمات الترجمة بينه وبين نطاقات العناوين. وتُنفّذ خوادم أسماء الإنترنت وبروتوكول الاتصال نظام أسماء النطاقات. خادم أسماء DNS هو خادم يُخزّن سجلات DNS لنطاقٍ ما، ويستجيب للاستعلامات المُوجّهة إلى قاعدة بياناته.

أكثر أنواع السجلات شيوعًا في قاعدة بيانات نظام أسماء النطاقات (DNS) هي سجلات بداية السلطة ( SOA )، وعناوين IP ( A و AAAA )، وخوادم تبادل البريد SMTP (MX)، وخوادم الأسماء (NS)، ومؤشرات البحث العكسي لنظام أسماء النطاقات (PTR)، وأسماء النطاقات البديلة (CNAME). وعلى الرغم من أن نظام أسماء النطاقات لم يُصمم في الأصل ليكون قاعدة بيانات عامة الأغراض، فقد تم توسيعه بمرور الوقت لتخزين سجلات لأنواع أخرى من البيانات، سواءً للبحث التلقائي، مثل سجلات DNSSEC ، أو للاستعلامات البشرية، مثل سجلات الشخص المسؤول (RP). وباعتباره قاعدة بيانات عامة الأغراض، يُستخدم نظام أسماء النطاقات أيضًا في مكافحة البريد الإلكتروني غير المرغوب فيه (البريد العشوائي) من خلال تخزين قوائم الحظر . يُخزن نظام أسماء النطاقات عادةً في ملف نصي منظم، وهو ملف المنطقة ، ولكن توجد أنظمة قواعد بيانات أخرى شائعة الاستخدام.

كان نظام أسماء النطاقات يستخدم في الأصل بروتوكول بيانات المستخدم (UDP) كوسيلة نقل عبر بروتوكول الإنترنت (IP). وقد أدت مخاوف الموثوقية والأمان والخصوصية إلى استخدام بروتوكول التحكم في الإرسال (TCP) بالإضافة إلى العديد من التطورات الأخرى في البروتوكولات.

وظيفة

يُستخدم تشبيه شائع لشرح نظام أسماء النطاقات (DNS) بأنه بمثابة دليل الهاتف للإنترنت، حيث يُترجم أسماء مضيفي أجهزة الكمبيوتر سهلة الفهم إلى عناوين IP. على سبيل المثال، يُترجم اسم المضيف www.example.comضمن اسم النطاق example.com إلى العنوانين 93.184.216.34 ( IPv4 ) و 2606:2800:220:1:248:1893:25c8:1946 ( IPv6 ). يتميز نظام أسماء النطاقات بإمكانية تحديثه بسرعة وشفافية، مما يسمح بتغيير موقع الخدمة على الشبكة دون التأثير على المستخدمين النهائيين، الذين يستمرون في استخدام اسم المضيف نفسه. يستفيد المستخدمون من هذه الميزة عند استخدامهم عناوين URL ذات دلالة، وعناوين البريد الإلكتروني ، دون الحاجة إلى معرفة كيفية تحديد الكمبيوتر لموقع الخدمات.

تُعدّ وظيفة نظام أسماء النطاقات (DNS) الأساسية والشاملة في خدمات الإنترنت الموزعة، مثل الخدمات السحابية وشبكات توصيل المحتوى . [ 4 ] فعندما يصل المستخدم إلى خدمة إنترنت موزعة باستخدام عنوان URL، يُترجم اسم نطاق عنوان URL إلى عنوان IP لخادم قريب من المستخدم. وتكمن الوظيفة الرئيسية لنظام أسماء النطاقات المُستغلة هنا في إمكانية حصول مستخدمين مختلفين في الوقت نفسه على ترجمات مختلفة لنفس اسم النطاق، وهو ما يُمثل نقطة اختلاف جوهرية عن النظرة التقليدية لنظام أسماء النطاقات القائمة على دليل الهاتف. وتُعدّ عملية استخدام نظام أسماء النطاقات لتخصيص خوادم قريبة للمستخدمين أساسية لتوفير استجابات أسرع وأكثر موثوقية على الإنترنت ، وهي شائعة الاستخدام في معظم خدمات الإنترنت الرئيسية. [ 5 ]

يعكس نظام أسماء النطاقات (DNS) هيكل المسؤولية الإدارية على الإنترنت. [ 6 ] كل نطاق فرعي هو منطقة تتمتع باستقلالية إدارية مُفوضة إلى مدير. بالنسبة للمناطق التي تُشغلها جهة تسجيل ، غالبًا ما تُستكمل المعلومات الإدارية بخدمات RDAP و WHOIS الخاصة بتلك الجهة . يمكن استخدام هذه البيانات لفهم وتتبع مسؤولية أي مضيف على الإنترنت. [ 7 ]

تاريخ

يعود استخدام اسم أبسط وأسهل تذكراً بدلاً من العنوان الرقمي للجهاز المضيف إلى عصر شبكة أربانت . احتفظ معهد ستانفورد للأبحاث (الذي يُعرف الآن باسم SRI International ) بملف نصي باسم HOSTS.TXT يربط أسماء الأجهزة المضيفة بالعناوين الرقمية لأجهزة الكمبيوتر على شبكة أربانت. [ 8 ] [ 9 ] طورت إليزابيث فاينلر أول دليل لشبكة أربانت وأشرفت على صيانته. [ 10 ] [ 11 ] تولى جون بوستل في معهد علوم المعلومات بجامعة جنوب كاليفورنيا (ISI) صيانة العناوين الرقمية، والتي تُسمى قائمة الأرقام المُخصصة، وكان فريقه يعمل بتعاون وثيق مع معهد ستانفورد للأبحاث. [ 12 ]

تم تخصيص العناوين يدويًا. أُضيفت أجهزة الكمبيوتر، بما في ذلك أسماء مضيفيها وعناوينها، إلى الملف الرئيسي عن طريق الاتصال بمركز معلومات شبكة معهد ستانفورد للأبحاث (SRI)، بإدارة فاينلر، عبر الهاتف خلال ساعات العمل. [ 13 ] لاحقًا، أنشأت فاينلر دليل WHOIS على خادم في مركز معلومات الشبكة لاسترجاع المعلومات حول الموارد وجهات الاتصال والكيانات. [ 14 ] طورت هي وفريقها مفهوم النطاقات. [ 14 ] اقترحت فاينلر أن تُبنى النطاقات على موقع العنوان الفعلي لجهاز الكمبيوتر. [ 15 ] على سبيل المثال ، ستكون لأجهزة الكمبيوتر في المؤسسات التعليمية النطاق edu . [ 16 ] أدارت هي وفريقها سجل أسماء المضيفين من عام 1972 إلى عام 1989. [ 17 ]

بحلول أوائل ثمانينيات القرن العشرين، أصبح الحفاظ على جدول مضيف مركزي واحد عملية بطيئة ومعقدة، واحتاجت الشبكة الناشئة إلى نظام تسمية آلي لمعالجة المشكلات التقنية والبشرية. كلف بوستل بول موكابيتريس بمهمة التوصل إلى حل وسط بين خمسة مقترحات متنافسة . لكن موكابيتريس ابتكر نظام أسماء النطاقات (DNS) عام ١٩٨٣ أثناء عمله في جامعة جنوب كاليفورنيا . [ ١٣ ] [ ١٨ ]

نشرت فرقة عمل هندسة الإنترنت المواصفات الأصلية في RFC 882 و RFC 883 في نوفمبر 1983. [ 19 ] [ 20 ] وتم تحديثها في RFC 973 في يناير 1986. [ 21 ]

في عام ١٩٨٤، قام أربعة طلاب من جامعة كاليفورنيا في بيركلي ، وهم دوغلاس تيري، ومارك بينتر، وديفيد ريغل، وسونغنيان تشو، بكتابة أول تطبيق لخادم أسماء يونكس لنطاق أسماء الإنترنت في بيركلي، والمعروف اختصارًا باسم BIND . [ ٢٢ ] في عام ١٩٨٥، قام كيفن دنلاب من شركة DEC بمراجعة شاملة لتطبيق نظام أسماء النطاقات (DNS). ثم تولى مايك كاريلز ، وفيل ألمكويست، وبول فيكسي صيانة BIND. تأسس اتحاد أنظمة الإنترنت (ISC) في عام ١٩٩٤ على يد ريك آدامز ، وبول فيكسي ، وكارل مالامود ، خصيصًا لتوفير بيئة لتطوير وصيانة BIND. وقد تولى ISC تطوير وصيانة إصدارات BIND بدءًا من الإصدار ٤.٩.٣، بدعم من الجهات الراعية لـ ISC. بصفتهما مهندسين معماريين/مبرمجين مشاركين، أصدر بوب هالي وبول فيكسي أول نسخة جاهزة للإنتاج من BIND الإصدار 8 في مايو 1997. ومنذ عام 2000، عمل أكثر من 43 مطورًا أساسيًا مختلفًا على BIND. [ 23 ]

في نوفمبر 1987، حلّت المواصفتان RFC 1034 [ 24 ] وRFC 1035 [ 6 ] محلّ مواصفات نظام أسماء النطاقات (DNS) لعام 1983. وقد اقترحت العديد من طلبات التعليقات الإضافية امتدادات لبروتوكولات نظام أسماء النطاقات الأساسية. [ 25 ]

بناء

مساحة اسم النطاق

يتكون نطاق أسماء النطاقات من بنية بيانات شجرية . لكل عقدة أو ورقة في الشجرة تسمية وصفر أو أكثر من سجلات الموارد (RR)، التي تحتوي على معلومات مرتبطة باسم النطاق. يتكون اسم النطاق نفسه من التسمية، متبوعة باسم العقدة الأصلية على اليمين، مفصولة بنقطة. [ 24 ] : §3.1

ينقسم هيكل الشجرة إلى مناطق فرعية بدءًا من المنطقة الجذرية . قد تتكون منطقة نظام أسماء النطاقات (DNS) من عدد من النطاقات والنطاقات الفرعية حسب اختيار مدير المنطقة. كما يمكن تقسيم نظام أسماء النطاقات (DNS) وفقًا للفئة ، حيث يمكن اعتبار الفئات المنفصلة بمثابة مصفوفة من أشجار مساحات الأسماء المتوازية. [ 24 ] : §4.2

نظام أسماء النطاقات الهرمي لفئة الإنترنت ، مُنظّم في مناطق، كل منها مُخدّم بواسطة خادم أسماء

يمكن تقسيم المسؤولية الإدارية لأي نطاق عن طريق إنشاء نطاقات إضافية. ويُقال إن السلطة على النطاق الجديد تُفوض إلى خادم أسماء مُعين. ويتوقف النطاق الأصلي عن كونه مرجعًا للنطاق الجديد. [ 24 ] : §4.2

بناء جملة اسم النطاق، والتدويل

تظهر الأوصاف النهائية لقواعد تكوين أسماء النطاقات في RFC 1035 و RFC 1123 و RFC 2181 و RFC 5892. يتكون اسم النطاق من جزء واحد أو أكثر، تسمى تقنيًا بالعلامات ، والتي يتم ربطها بشكل تقليدي ، ويتم تحديدها بنقاط، مثل example.com.

يشير الملصق الموجود في أقصى اليمين إلى نطاق المستوى الأعلى ؛ على سبيل المثال، اسم النطاق www.example.com ينتمي إلى نطاق المستوى الأعلى com .

ينحدر التسلسل الهرمي للنطاقات من اليمين إلى اليسار؛ حيث يُشير كل تصنيف على اليسار إلى قسم فرعي، أو نطاق فرعي ، من النطاق الموجود على اليمين. على سبيل المثال، يُشير التصنيف example إلى نطاق فرعي من النطاق com ، و www هو نطاق فرعي من example.com. قد يصل عدد مستويات هذا التسلسل الهرمي للتقسيمات الفرعية إلى 127 مستوى. [ 26 ]

قد يحتوي الوسم على ما بين صفر و63 حرفًا، لأن الطول المسموح به لا يتجاوز 6 بتات. الوسم الفارغ ذو الطول صفر محجوز لمنطقة الجذر. لا يجوز أن يتجاوز طول اسم النطاق الكامل 253 حرفًا في تمثيله النصي (أو 254 حرفًا مع النقطة الأخيرة). [ 24 ] في التمثيل الثنائي الداخلي لنظام أسماء النطاقات (DNS)، يتطلب هذا الطول الأقصى البالغ 253 حرفًا مساحة تخزين تبلغ 255 بايت، حيث يتم تخزين طول أول وسم من بين العديد من الوسوم، بالإضافة إلى البايت الفارغ الأخير. [ 6 ] لا يتحقق الطول 255 إلا بوجود 6 وسوم على الأقل (بما في ذلك الوسم الفارغ الأخير). [ 6 ]

على الرغم من عدم وجود قيود تقنية تمنع استخدام أي حرف يمكن تمثيله بثمانية أحرف في أسماء النطاقات، إلا أن أسماء المضيفين تستخدم تنسيقًا ومجموعة أحرف مفضلة. الأحرف المسموح بها في أسماء النطاقات هي مجموعة فرعية من مجموعة أحرف ASCII ، وتتكون من الأحرف من a إلى z ، ومن A إلى Z ، والأرقام من 0 إلى 9 ، والواصلة. تُعرف هذه القاعدة بقاعدة LDH (الأحرف، الأرقام، الواصلة). تُفسَّر أسماء النطاقات بغض النظر عن حالة الأحرف. [ 27 ] لا يجوز أن تبدأ أسماء النطاقات أو تنتهي بواصلة. [ 28 ] وتنص قاعدة إضافية على ألا تكون أسماء نطاقات المستوى الأعلى رقمية بالكامل. [ 28 ]

حالت مجموعة الأحرف ASCII المحدودة المسموح بها في نظام أسماء النطاقات (DNS) دون تمثيل أسماء وكلمات العديد من اللغات بأبجدياتها أو نصوصها الأصلية. ولتيسير ذلك، أقرت مؤسسة الإنترنت للأسماء والأرقام المُخصصة (ICANN) نظام تدويل أسماء النطاقات في التطبيقات (IDNA)، والذي بموجبه تقوم تطبيقات المستخدم، مثل متصفحات الويب، بربط سلاسل Unicode بمجموعة أحرف DNS الصالحة باستخدام Punycode . وفي عام 2009، أقرت ICANN تثبيت نطاقات المستوى الأعلى لرموز الدول ( ccTLDs ) ذات أسماء النطاقات المُدوّلة . إضافةً إلى ذلك، اعتمدت العديد من سجلات نطاقات المستوى الأعلى ( TLDs ) الحالية نظام IDNA، استنادًا إلى RFC 5890 وRFC 5891 وRFC 5892 وRFC 5893.

وفد

تُسمى الآلية التي يتم بموجبها إسناد مسؤولية أجزاء مختلفة من نطاق أسماء نظام أسماء النطاقات (DNS) إلى خوادم أسماء مختلفة بالتفويض . يتم تفويض كل نطاق شبكة عامة ضمن نطاقات المستوى الأعلى ، وذلك من خلال وجود سجل NS في النطاق الأصل يشير إلى أسماء DNS لخوادم أسماء النطاق المُفوَّض (أو النطاق الفرعي). إذا كانت خوادم الأسماء هذه موجودة في النطاق المُفوَّض، فيجب أن يحتوي النطاق الأصل أيضًا على سجلات ربط (glue records ) تتضمن عناوين IP لخوادم أسماء النطاق الفرعي. [ 29 ]

خوادم الأسماء

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

خادم أسماء موثوق

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

يمكن أن يكون خادم الأسماء الموثوق خادمًا رئيسيًا أو خادمًا ثانويًا . تاريخيًا، استُخدم مصطلحا "الرئيسي/التابع" و "الرئيسي/الثانوي" أحيانًا بشكل متبادل [ 30 ]، ولكن الممارسة الحالية هي استخدام الصيغة الثانية. الخادم الرئيسي هو الخادم الذي يخزن النسخ الأصلية لجميع سجلات النطاق. أما الخادم الثانوي، فيستخدم آلية تحديث تلقائي خاصة في بروتوكول نظام أسماء النطاقات (DNS) للتواصل مع خادمه الرئيسي، وذلك للحفاظ على نسخة مطابقة من سجلات الخادم الرئيسي.

يجب تخصيص مجموعة من خوادم الأسماء الموثوقة لكل منطقة DNS. يتم تخزين هذه المجموعة من الخوادم في منطقة النطاق الأصل مع سجلات خادم الأسماء (NS).

يُشير الخادم الموثوق إلى قدرته على تقديم إجابات نهائية، تُعتبر موثوقة ، من خلال تعيين علامة بروتوكول تُسمى " بت الإجابة الموثوقة " ( AA ) في استجاباته. [ 6 ] عادةً ما تظهر هذه العلامة بشكل بارز في مخرجات أدوات استعلام إدارة نظام أسماء النطاقات (DNS)، مثل dig ، للدلالة على أن خادم الأسماء المُستجيب هو جهة موثوقة لاسم النطاق المعني. [ 6 ]

عندما يُعيّن خادم أسماء كخادم موثوق لاسم نطاق لا يملك بيانات موثوقة عنه، فإنه يُظهر نوعًا من الأخطاء يُسمى "التفويض غير الصحيح" أو "الاستجابة غير الصحيحة". [ 31 ] [ 32 ]

عملية

آليات حل العناوين

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

محلل DNS الذي ينفذ النهج التكراري المنصوص عليه في RFC 1034؛ في هذه الحالة، يستشير المحلل ثلاثة خوادم أسماء لحل اسم النطاق المؤهل بالكامل "www.wikipedia.org".

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

بافتراض عدم وجود سجلات مخزنة مؤقتًا لدى المُحلِّل لتسريع العملية، تبدأ عملية التحليل باستعلام إلى أحد خوادم الجذر. في الوضع الطبيعي، لا تُجيب خوادم الجذر مباشرةً، بل تُحيل الاستعلام إلى خوادم أكثر موثوقية، على سبيل المثال، يُحال الاستعلام عن "www.wikipedia.org" إلى خوادم org . يستعلم المُحلِّل الآن من الخوادم المُشار إليها، ويُكرر هذه العملية بشكل متكرر حتى يتلقى إجابة موثوقة. يُوضح الرسم التخطيطي هذه العملية للمضيف المُسمى باسم النطاق المؤهل بالكامل "www.wikipedia.org".

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

خادم أسماء متكرر ومخزن مؤقتًا

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

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

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

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

خوادم نظام أسماء النطاقات (DNS)

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

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

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

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

التبعيات الدائرية وسجلات الربط

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

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

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

تخزين السجلات مؤقتًا

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

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

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

البحث العكسي

البحث العكسي في نظام أسماء النطاقات (DNS) هو استعلام يُجرى على نظام أسماء النطاقات (DNS) للحصول على أسماء النطاقات عندما يكون عنوان IP معروفًا. قد يرتبط عنوان IP واحد بأكثر من اسم نطاق. يخزن نظام أسماء النطاقات عناوين IP على شكل أسماء نطاقات، مُنسقة بشكل خاص في سجلات المؤشر (PTR) ضمن نطاق المستوى الأعلى للبنية التحتية arpa . بالنسبة لبروتوكول IPv4، يكون النطاق هو in-addr.arpa. أما بالنسبة لبروتوكول IPv6، فيكون نطاق البحث العكسي هو ip6.arpa. يُمثل عنوان IP باسم مُرتب عكسيًا باستخدام تمثيل البايتات الثمانية في IPv4، وباستخدام تمثيل البايتات النصفية في IPv6.

عند إجراء بحث عكسي، يقوم عميل نظام أسماء النطاقات (DNS) بتحويل العنوان إلى هذه التنسيقات قبل الاستعلام عن الاسم للحصول على سجل PTR وفقًا لسلسلة التفويض كما هو الحال في أي استعلام DNS. على سبيل المثال، بافتراض أن عنوان IPv4 208.80.152.2 مُخصص لويكيميديا، فإنه يُمثل كاسم DNS بترتيب عكسي: 2.152.80.208.in-addr.arpa. عندما يتلقى مُحلل DNS طلب مؤشر (PTR)، يبدأ بالاستعلام من خوادم الجذر، التي تُشير إلى خوادم السجل الأمريكي لأرقام الإنترنت (ARIN) لمنطقة 208.in-addr.arpa. تُفوض خوادم ARIN العنوان 152.80.208.in-addr.arpa إلى ويكيميديا، حيث يُرسل المُحلل استعلامًا آخر عن 2.152.80.208.in-addr.arpa، مما ينتج عنه استجابة موثوقة.

البحث عن العملاء

تسلسل تحليل نظام أسماء النطاقات (DNS)

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

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

محللات معطلة

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

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

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

تطبيقات أخرى

يتضمن نظام أسماء النطاقات العديد من الوظائف والميزات الأخرى.

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

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

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

على سبيل المثال:

  • تم إدراج العنوان 203.0.113.5 في قائمة الحظر. وهو يشير إلى 5.113.0.203.blocklist.example ، والذي يتم حله إلى 127.0.0.1 .
  • العنوان 203.0.113.6 غير مدرج في قائمة الحظر، ويشير إلى 6.113.0.203.blocklist.example . اسم المضيف هذا إما غير مُهيأ، أو أنه يُحلّل إلى 127.0.0.2 .

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

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

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

تنسيق رسالة نظام أسماء النطاقات (DNS)

يستخدم بروتوكول نظام أسماء النطاقات (DNS) نوعين من الرسائل: الاستعلامات والاستجابات؛ وكلاهما لهما نفس التنسيق. تتكون كل رسالة من رأس وأربعة أقسام: السؤال، والجواب، والسلطة، ومساحة إضافية. يتحكم حقل الرأس ( flags ) في محتوى هذه الأقسام الأربعة. [ 24 ]

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

رأس نظام أسماء النطاقات (DNS)
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00رقم المعاملةرمز الاستجابة السريعةرمز العمليةAATCأخصائي تغذية معتمدRAZإعلانقرص مضغوطRCODE
432عدد الأسئلةعدد الإجابات
864عدد سلطات المواردعدد التقارير الإضافية
معرّف المعاملة : 16 بت
رقم المعاملة
الرايات : 16 بت
يتكون حقل العلم من حقول فرعية كما يلي:
رمز الاستجابة السريعة : 1 بت
يشير إلى ما إذا كانت الرسالة استفسارًا (0) أو ردًا (1).
رمز العملية : 4 بتات
يمكن أن يكون النوع QUERY (استعلام قياسي، 0)، أو IQUERY (استعلام عكسي، 1)، أو STATUS (طلب حالة الخادم، 2).
AA : 1 بت
يشير الرد الموثوق، في الاستجابة، إلى ما إذا كان خادم نظام أسماء النطاقات (DNS) موثوقًا به لاسم المضيف المستعلم عنه.
TC : 1 بت
يشير TrunCation إلى أن هذه الرسالة قد تم اقتطاعها بسبب طولها الزائد.
RD : 1 بت
يشير "الاستعلام المتكرر المطلوب" إلى ما إذا كان العميل يقصد استعلامًا متكررًا.
RA : 1 بت
يشير مصطلح "التكرار متاح" في الاستجابة إلى ما إذا كان خادم DNS المُجيب يدعم التكرار.
Z : بت واحد ؛ (Z) == 0
صفر، محجوز للاستخدام المستقبلي.
AD : 1 بت
تشير البيانات الأصلية، في الرد، إلى ما إذا كان خادم DNS المجيب قد تحقق من البيانات.
قرص مضغوط : 1 بت
يشير تحديد "معطل" في الاستعلام إلى أن البيانات غير الموثقة مقبولة في الاستجابة.
RCODE : 4 بتات
يمكن أن يكون رمز الاستجابة NOERROR (0)، FORMERR (1، خطأ في التنسيق)، SERVFAIL (2)، NXDOMAIN (3، نطاق غير موجود)، إلخ. [ 37 ]
عدد الأسئلة : 16 بت
عدد الأسئلة.
عدد الإجابات : 16 بت
عدد الإجابات.
عدد سجلات الموارد المرجعية : 16 بت
عدد سجلات موارد السلطة.
عدد سجلات الموارد الإضافية : 16 بت
عدد سجلات الموارد الإضافية.

قسم الأسئلة

يتميز قسم الأسئلة بتنسيق أبسط من تنسيق سجل الموارد المستخدم في الأقسام الأخرى. يحتوي كل سجل سؤال (عادةً ما يكون هناك سجل سؤال واحد فقط في القسم) على الحقول التالية:

حقول سجل الموارد (RR)
مجالوصفالطول ( ثمانيات )
اسماسم المورد المطلوبعامل
يكتبنوع RR (A، AAAA، MX، TXT، إلخ.)2
فصلرمز الفصل2

يُقسّم اسم النطاق إلى تسميات منفصلة يتم دمجها؛ وتُسبق كل تسمية بطول تلك التسمية. [ 38 ]

سجلات الموارد

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

عند إرسالها عبر شبكة بروتوكول الإنترنت ، تستخدم جميع السجلات (الإجابة، والسلطة، والأقسام الإضافية) التنسيق الشائع المحدد في RFC 1035: [ 39 ] : §3

حقول سجل الموارد (RR)
مجالوصفالطول ( ثمانيات )
اسماسم العقدة التي ينتمي إليها هذا السجلعامل
يكتبنوع RR في شكل رقمي (على سبيل المثال، 15 لـ MX RRs)2
فصلرمز الفصل2
TTLعدد الثواني التي يظل فيها سجل القيادة ساري المفعول (الحد الأقصى هو 2 31 −1، أي حوالي 68 عامًا)4
طول الشعاعطول حقل RDATA (محدد بالوحدات الثمانية)2
بياناتبيانات إضافية خاصة بـ RRمتغير، حسب RDLENGTH

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

يُشير TYPE إلى نوع السجل. فهو يُحدد تنسيق البيانات ويُعطي لمحة عن استخدامها المقصود. على سبيل المثال، يُستخدم سجل A لترجمة اسم النطاق إلى عنوان IPv4 ، ويُدرج سجل NS خوادم الأسماء التي يُمكنها الاستجابة لطلبات البحث في منطقة DNS ، ويُحدد سجل MX خادم البريد المُستخدم لمعالجة البريد لنطاق مُحدد في عنوان بريد إلكتروني.

بيانات RDATA هي بيانات ذات صلة خاصة بنوع معين، مثل عنوان IP لسجلات العناوين، أو الأولوية واسم المضيف لسجلات MX. يمكن لأنواع السجلات المعروفة استخدام ضغط التسميات في حقل RDATA، ولكن لا يجوز ذلك لأنواع السجلات "غير المعروفة" (RFC 3597).

يُعيّن نوع السجل ( CLASS ) إلى "IN" (اختصارًا لـ "إنترنت" ) لسجلات نظام أسماء النطاقات (DNS) الشائعة التي تتضمن أسماء مضيفي الإنترنت أو الخوادم أو عناوين IP. بالإضافة إلى ذلك، توجد فئتا "Chaos" (CH) و "Hesiod" (HS). [ 39 ] : 11 كل فئة عبارة عن مساحة اسم مستقلة ذات تفويضات مختلفة محتملة لمناطق نظام أسماء النطاقات.

بالإضافة إلى سجلات الموارد المحددة في ملف المنطقة ، يحدد نظام أسماء النطاقات أيضًا عدة أنواع من الطلبات التي تُستخدم فقط في الاتصال مع عقد DNS الأخرى ( عبر الشبكة )، كما هو الحال عند إجراء عمليات نقل المناطق (AXFR/IXFR) أو لـ EDNS (OPT).

سجلات وايلدكارد

يدعم نظام أسماء النطاقات سجلات DNS ذات الأحرف البديلة ، والتي تحدد أسماء تبدأ بعلامة النجمة (*) ، *على سبيل المثال، *.example. [ 24 ] [ 40 ]. تحدد سجلات DNS التابعة لأسماء النطاقات ذات الأحرف البديلة قواعد إنشاء سجلات الموارد ضمن منطقة DNS واحدة، وذلك باستبدال العلامات الكاملة بمكونات مطابقة لاسم الاستعلام، بما في ذلك أي نطاقات فرعية محددة. على سبيل المثال، في التكوين التالي، تحدد منطقة DNS x.example أن جميع النطاقات الفرعية، بما في ذلك النطاقات الفرعية للنطاقات الفرعية، لـ x.example تستخدم خادم البريد (MX) axexample . يلزم وجود سجل AAAA لـ axexample لتحديد عنوان IP لخادم البريد. ولأن هذا يؤدي إلى استبعاد اسم النطاق هذا ونطاقاته الفرعية من مطابقة الأحرف البديلة، يجب أيضًا تعريف سجل MX إضافي للنطاق الفرعي axexample ، بالإضافة إلى سجل MX ذي أحرف بديلة لجميع نطاقاته الفرعية، في منطقة DNS.

x.example. MX 10 a.x.example. *.x.example. MX 10 a.x.example. axexample. MX 10 a.x.example. *.axexample. MX 10 a.x.example. axexample. AAAA 2001:db8::1

تم تحسين دور سجلات الأحرف البديلة في RFC 4592 ، لأن التعريف الأصلي في RFC 1034 كان غير مكتمل وأدى إلى سوء تفسير من قبل المنفذين. [ 40 ]  

امتدادات البروتوكول

كان بروتوكول نظام أسماء النطاقات (DNS) الأصلي محدود الإمكانيات لإضافة ميزات جديدة. في عام ١٩٩٩، نشر بول فيكسي في RFC ٢٦٧١ (الذي حل محله RFC ٦٨٩١) آلية توسيع تُسمى آليات توسيع نظام أسماء النطاقات (EDNS)، والتي أدخلت عناصر بروتوكول اختيارية دون زيادة الحمل الزائد عند عدم استخدامها. وقد تحقق ذلك من خلال سجل الموارد الوهمي OPT الموجود فقط في عمليات نقل البروتوكول عبر الشبكة، وليس في أي ملفات نطاق. كما اقتُرحت امتدادات أولية (EDNS٠)، مثل زيادة حجم رسالة نظام أسماء النطاقات في حزم بيانات UDP.

تحديثات المنطقة الديناميكية

تستخدم تحديثات نظام أسماء النطاقات الديناميكية (DNS) رمز العملية UPDATE DNS لإضافة أو إزالة سجلات الموارد ديناميكيًا من قاعدة بيانات المنطقة المُدارة على خادم DNS موثوق. [ 41 ] تُفيد هذه الخاصية في تسجيل عملاء الشبكة في نظام أسماء النطاقات عند بدء تشغيلهم أو عند توفرهم على الشبكة. ونظرًا لأن العميل الذي يبدأ التشغيل قد يحصل على عنوان IP مختلف في كل مرة من خادم DHCP ، فإنه لا يُمكن توفير عناوين IP ثابتة لهؤلاء العملاء.

بروتوكولات النقل

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

تقليدي: نظام أسماء النطاقات عبر بروتوكول UDP ومنفذ TCP رقم 53 (Do53)

يحجز بروتوكول UDP المنفذ رقم 53 للخوادم التي تستمع إلى الاستعلامات. [ 6 ] يتكون هذا الاستعلام من طلب نصي واضح يُرسل في حزمة UDP واحدة من العميل، ويُرد عليه برد نصي واضح يُرسل في حزمة UDP واحدة من الخادم. عندما يتجاوز طول الرد 512 بايت، ويدعم كل من العميل والخادم آليات التمديد لنظام أسماء النطاقات (EDNS)، يمكن استخدام حزم UDP أكبر. [ 42 ] يحد من استخدام نظام أسماء النطاقات عبر UDP، من بين أمور أخرى، افتقاره إلى تشفير طبقة النقل، والمصادقة، والتسليم الموثوق، وطول الرسالة. في عام 1989، حددت RFC 1123 بروتوكول التحكم بالنقل (TCP) الاختياري لاستعلامات نظام أسماء النطاقات، والردود، وخاصةً عمليات نقل المناطق . من خلال تجزئة الردود الطويلة، يسمح بروتوكول TCP باستجابات أطول، وتسليم موثوق، وإعادة استخدام الاتصالات طويلة الأمد بين العملاء والخوادم. بالنسبة للردود الأكبر حجمًا، يُحيل الخادم العميل إلى بروتوكول TCP.

نظام أسماء النطاقات عبر بروتوكول TLS (DoT)

ظهر نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل ( DNS over TLS) كمعيار من قِبل فريق هندسة الإنترنت (IETF) لتشفير نظام أسماء النطاقات في عام 2016، حيث يستخدم بروتوكول أمان طبقة النقل (TLS) لحماية الاتصال بأكمله، وليس فقط حمولة بيانات نظام أسماء النطاقات. تستمع خوادم DNS عبر بروتوكول TCP على المنفذ 853. وينص RFC 7858 على إمكانية دعم التشفير التلقائي والتشفير الموثق، ولكنه لم يجعل توثيق الخادم أو العميل إلزاميًا. 

نظام أسماء النطاقات عبر بروتوكول HTTPS (DoH)

طُوِّر نظام أسماء النطاقات عبر بروتوكول HTTPS كمعيار منافس لنقل استعلامات نظام أسماء النطاقات في عام 2018، حيث يقوم بتمرير بيانات استعلامات نظام أسماء النطاقات عبر بروتوكول HTTPS، الذي ينقل بيانات HTTP عبر بروتوكول TLS. وقد رُوِّج لنظام DoH كبديل أكثر ملاءمةً للويب لنظام DNS، لأنه، مثل DNSCrypt، يستخدم منفذ TCP 443، وبالتالي يبدو مشابهًا لحركة مرور الويب، على الرغم من سهولة التمييز بينهما عمليًا دون الحاجة إلى حشو مناسب. [ 43 ]

نظام أسماء النطاقات عبر بروتوكول QUIC (DoQ)

يصف RFC 9250، الذي نشرته فرقة عمل هندسة الإنترنت عام 2022 ، نظام أسماء النطاقات عبر بروتوكول QUIC . يتميز هذا النظام بخصائص خصوصية مشابهة لنظام أسماء النطاقات عبر بروتوكول TLS (DoT)، وخصائص زمن استجابة مشابهة لنظام أسماء النطاقات التقليدي عبر بروتوكول UDP. يختلف هذا الأسلوب عن نظام أسماء النطاقات عبر بروتوكول HTTP/3 . [ 44 ]

نظام أسماء النطاقات عبر بروتوكول CoAP (DoC)

يصف RFC 9953، الذي نشرته فرقة عمل هندسة الإنترنت عام 2026 ، بروتوكول DNS عبر CoAP . يستلهم استخدام DoC من DNS عبر HTTPS (DoH) (RFC 8484). مع ذلك، يهدف DoC إلى النشر في بيئات إنترنت الأشياء (IoT) ذات الموارد المحدودة، وهو ما يتعارض عادةً مع متطلبات HTTPS. [ 45 ] يتفوق DoC على آليات تحليل أسماء النطاقات الأخرى في البيئات ذات الموارد المحدودة. [ 46 ]

بروتوكول الإنترنت غير الواعي (ODoH) وسابقه بروتوكول الإنترنت غير الواعي (ODNS)

ابتكر باحثون من جامعة برينستون وجامعة شيكاغو نظام أسماء النطاقات غير المُشفّر (ODNS) وطبّقوه كامتداد لنظام أسماء النطاقات غير المُشفّر، [ 47 ] قبل توحيد بروتوكول DoH ونشره على نطاق واسع. ثمّ قامت شركتا آبل وكلاود فلير بتطبيق هذه التقنية في سياق DoH، تحت اسم Oblivious DoH (ODoH). [ 48 ] يجمع ODoH بين فصل الدخول/الخروج (المُبتكر في ODNS) مع نفق HTTPS الخاص بـ DoH وتشفير طبقة النقل TLS في بروتوكول واحد. [ 49 ]

نظام أسماء النطاقات عبر تور

يمكن تشغيل نظام أسماء النطاقات (DNS) عبر الشبكات الخاصة الافتراضية (VPN) وبروتوكولات الأنفاق . ويمكن تحقيق مكاسب الخصوصية لنظام أسماء النطاقات غير الواعي (Oblivious DNS) من خلال استخدام شبكة Tor الموجودة مسبقًا لعقد الدخول والخروج، بالإضافة إلى تشفير طبقة النقل الذي يوفره بروتوكول أمان طبقة النقل (TLS). [ 50 ]

DNSCrypt

أدخل بروتوكول DNSCrypt ، الذي طُوّر عام 2011 خارج إطار معايير IETF ، تشفير نظام أسماء النطاقات (DNS) على جانب المُستقبِل من المُحلِّلات التكرارية، حيث يقوم العملاء بتشفير حمولات الاستعلام باستخدام المفاتيح العامة للخوادم، المنشورة في نظام أسماء النطاقات (بدلاً من الاعتماد على جهات إصدار الشهادات الخارجية)، والتي يمكن حمايتها بدورها بواسطة توقيعات DNSSEC . [ 51 ] يستخدم DNSCrypt إما منفذ TCP 443، وهو نفس منفذ حركة مرور الويب المُشفَّرة عبر HTTPS ، أو منفذ UDP 443. لم يُضف هذا فقط خصوصية لمحتوى الاستعلام، بل وفّر أيضًا قدرة كبيرة على اختراق جدران الحماية. في عام 2019، تم توسيع نطاق DNSCrypt لدعم وضع "مجهول الهوية"، على غرار "نظام أسماء النطاقات الغافل" المُقترح، حيث تستقبل عقدة الدخول استعلامًا مُشفَّرًا باستخدام المفتاح العام لخادم آخر، وتُعيد توجيهه إلى ذلك الخادم، الذي يعمل كعقدة خروج، ويُجري عملية التحليل التكراري. [ 52 ] يتم ضمان خصوصية أزواج المستخدم/الاستعلام، حيث لا تعرف عقدة الدخول محتوى الاستعلام، بينما لا تعرف عقدة الخروج هوية العميل. تم تطبيق DNSCrypt لأول مرة في بيئة إنتاجية بواسطة OpenDNS في ديسمبر 2011. توجد العديد من تطبيقات البرمجيات المجانية والمفتوحة المصدر التي تدمج ODoH أيضًا. [ 53 ] وهو متوفر لأنظمة تشغيل متنوعة، بما في ذلك Unix وApple iOS وLinux وAndroid وWindows.

قضايا أمنية

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

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

لا تحتوي استجابات نظام أسماء النطاقات (DNS) تقليديًا على توقيع تشفيري ، مما يُتيح العديد من إمكانيات الهجوم؛ لذا تُعدّل امتدادات أمان نظام أسماء النطاقات (DNSSEC) نظام DNS لإضافة دعم للاستجابات الموقعة تشفيريًا. [ 54 ] وقد اقتُرح DNSCurve كبديل لـ DNSSEC. تُضيف امتدادات أخرى، مثل TSIG ، دعمًا للمصادقة التشفيرية بين النظراء الموثوق بهم، وتُستخدم عادةً لتفويض عمليات نقل النطاقات أو التحديثات الديناميكية.

يمكن أيضًا استخدام تقنيات مثل نظام أسماء النطاقات العكسي المؤكد للأمام للمساعدة في التحقق من صحة نتائج نظام أسماء النطاقات.

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

انتحال نظام أسماء النطاقات (DNS)

قد تُستخدم بعض أسماء النطاقات لتحقيق تأثيرات التزييف. على سبيل المثال، paypal.com و paypa1.com اسمان مختلفان، ومع ذلك قد لا يتمكن المستخدمون من التمييز بينهما في واجهة المستخدم الرسومية اعتمادًا على نوع الخط المُختار . في العديد من الخطوط، يبدو الحرف l والرقم 1 متشابهين جدًا أو حتى متطابقين. تُعرف هذه المشكلة بهجوم التجانس في أسماء النطاقات الدولية ، وهي حادة في الأنظمة التي تدعم أسماء النطاقات الدولية ، حيث قد تبدو العديد من رموز الأحرف في معيار ISO 10646 متطابقة على شاشات الكمبيوتر العادية. تُستغل هذه الثغرة الأمنية أحيانًا في عمليات التصيد الاحتيالي . [ 55 ]

DNSMessenger

يُعدّ DNSMessenger [ 56 ] [ 57 ] [ 58 ] [ 59 ] نوعًا من تقنيات الهجوم الإلكتروني التي تستخدم نظام أسماء النطاقات (DNS) للتواصل مع البرامج الضارة والتحكم بها عن بُعد دون الاعتماد على البروتوكولات التقليدية التي قد تُثير الشكوك. ويُعتبر هجوم DNSMessenger خفيًا لأن نظام أسماء النطاقات يُستخدم بشكل أساسي لحلّ أسماء النطاقات، وغالبًا ما لا تخضع أدوات أمن الشبكات لمراقبة دقيقة، مما يجعله قناة فعّالة للمهاجمين لاستغلالها.

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

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

مشاكل الخصوصية والتتبع

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

وتتعرض خصوصية المستخدم للخطر بشكل أكبر من خلال المقترحات المتعلقة بزيادة مستوى معلومات عنوان IP الخاص بالعميل في استعلامات نظام أسماء النطاقات (RFC 7871) لصالح شبكات توصيل المحتوى .

تشمل الأساليب الرئيسية المستخدمة لمواجهة مشكلات الخصوصية المتعلقة بنظام أسماء النطاقات (DNS) ما يلي:

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

تعرضت الحلول التي تمنع فحص نظام أسماء النطاقات (DNS) من قِبل مُشغّل الشبكة المحلية لانتقاداتٍ بسبب إعاقتها لسياسات أمن الشبكات المؤسسية والرقابة على الإنترنت. كما تُنتقد خوادم DNS العامة لمساهمتها في مركزية الإنترنت من خلال وضع السيطرة على تحليل أسماء النطاقات في أيدي عدد قليل من الشركات الكبيرة القادرة على تشغيل خوادم تحليل عامة. [ 60 ]

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

— خصوصية نظام أسماء النطاقات (DNS) وفريق هندسة الإنترنت (IETF)

تسجيل اسم النطاق

يُمنح حق استخدام اسم النطاق من قِبل مسجلي أسماء النطاقات المعتمدين من قِبل مؤسسة الإنترنت للأسماء والأرقام المُخصصة (ICANN) أو منظمات أخرى مثل OpenNIC ، والمسؤولة عن الإشراف على أنظمة أسماء وأرقام الإنترنت. بالإضافة إلى ICANN، تتولى جهة إدارية، تُشغّل سجلًا، صيانة كل نطاق من نطاقات المستوى الأعلى (TLD) وتقديم خدمات الدعم الفني له. يتولى السجل مسؤولية إدارة قاعدة بيانات الأسماء ضمن نطاقه المُعتمد، مع العلم أن هذا المصطلح يُستخدم غالبًا للإشارة إلى نطاقات المستوى الأعلى. المُسجِّل هو الشخص أو المؤسسة التي طلبت تسجيل النطاق. [ 25 ] يتلقى السجل معلومات التسجيل من كل مسجل أسماء نطاقات مُصرَّح له (معتمد) بتخصيص الأسماء في النطاق المُناسب، وينشر هذه المعلومات باستخدام بروتوكول WHOIS . اعتبارًا من عام 2015، يجري النظر في استخدام بروتوكول RDAP . [ 61 ]

تنشر مؤسسة ICANN القائمة الكاملة لنطاقات المستوى الأعلى (TLDs) وسجلاتها ومسجلي أسماء النطاقات. تُحفظ معلومات المسجلين المرتبطة بأسماء النطاقات في قاعدة بيانات إلكترونية متاحة عبر خدمة WHOIS. بالنسبة لمعظم نطاقات المستوى الأعلى لرموز الدول (ccTLDs) التي يزيد عددها عن 290 نطاقًا، تحتفظ سجلات النطاقات بمعلومات WHOIS (المسجل، وخوادم الأسماء، وتواريخ انتهاء الصلاحية، إلخ). على سبيل المثال، يحتفظ مركز معلومات الشبكة الألماني ( DENIC ) ببيانات نطاق DE. منذ عام 2001 تقريبًا، اعتمدت معظم سجلات نطاقات المستوى الأعلى العامة (gTLDs) ما يُعرف بنهج السجل المركزي ، أي الاحتفاظ ببيانات WHOIS في سجلات مركزية بدلًا من قواعد بيانات المسجلين.

بالنسبة لنطاقات المستوى الأعلى على COM وNET، يُستخدم نموذج تسجيل مبسط . يحتفظ سجل النطاقات ( GoDaddy و BigRock وPDR و VeriSign وغيرها) ببيانات WHOIS الأساسية (أي، المسجل وخوادم الأسماء، وما إلى ذلك). من ناحية أخرى، تُسجل المنظمات، أي الجهات المسجلة باستخدام ORG، حصريًا في سجل المصلحة العامة .

تُقدّم بعض سجلات أسماء النطاقات، والتي تُعرف غالبًا بمراكز معلومات الشبكة (NIC)، خدمات تسجيل النطاقات للمستخدمين النهائيين، بالإضافة إلى توفير الوصول إلى مجموعات بيانات WHOIS. وتستخدم سجلات النطاقات العليا، مثل نطاقات COM وNET وORG، نموذجًا يتألف من العديد من مسجلي أسماء النطاقات. [ 62 ] في هذه الطريقة الإدارية، يقتصر دور السجل على إدارة قاعدة بيانات أسماء النطاقات والعلاقة مع المسجلين. أما المسجلون (مستخدمو اسم النطاق) فهم عملاء المسجل، وفي بعض الحالات من خلال التعاقد من الباطن مع موزعين.

انظر أيضاً

مراجع

  1. وو ، هاو؛ دانغ، شيانغلي؛ وانغ، ليدونغ؛ هي، لونغتاو (2016). "طريقة قائمة على دمج المعلومات للكشف عن هجمات تسميم ذاكرة التخزين المؤقت لنظام أسماء النطاقات الموزعة وتحديدها" . أمن المعلومات IET . 10 (1): 37-44 . doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .  
  2. ↑ غودوين، كريستال ر. تشاينا، مايكل (4 نوفمبر 2025). "ما هو نظام أسماء النطاقات (DNS)؟ | آي بي إم" . www.ibm.com . تاريخ الاسترجاع: 10 يوليو 2026 .{{cite web}}: صيانة CS1: أسماء متعددة: قائمة المؤلفين ( رابط )
  3. ↑ ج. بوستل ، محرر (سبتمبر 1981). بروتوكول الإنترنت - مواصفات بروتوكول برنامج داربا للإنترنت . IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128، 123، 111، 80، 54، 44، 41، 28، 26.المعيار الخامس للإنترنت. يلغي RFC 760. تم تحديثه بواسطة RFC 1349 و 2474 و 6864 .  
  4. ↑ ج. ديلي، ب. ماغز، ج. باريك، هـ. بروكوب، ر. سيتارامان، وب. ويل. "توصيل المحتوى الموزع عالميًا، مؤتمر IEEE للحوسبة عبر الإنترنت، سبتمبر/أكتوبر 2002، الصفحات 50-58" (ملف PDF) . مؤرشف (ملف PDF) من النسخة الأصلية بتاريخ 17 أبريل 2015.
  5. ↑ نيغرين، إي.؛ سيتارامان، آر. كيه.؛ صن، جيه. (2010). "شبكة أكاماي: منصة لتطبيقات الإنترنت عالية الأداء" ( ملف PDF) . مجلة ACM SIGOPS لأنظمة التشغيل . 44 (3): 2-19 . doi : 10.1145/1842733.1842736 . S2CID 207181702. مؤرشف (ملف PDF) من النسخة الأصلية بتاريخ 2 ديسمبر 2010. تم الاطلاع عليه بتاريخ 19 نوفمبر 2012 . 
  6. 1 2 3 4 5 6 7 ب. موكابيتريس (نوفمبر 1987). أسماء النطاقات - التنفيذ والمواصفات . مجموعة عمل الشبكة. doi : 10.17487/RFC1035 . STD 13. RFC 1035 .المعيار 13 للإنترنت . يلغي المعايير RFC 882 و 883 و 973 . تم تحديثه بواسطة المعايير RFC 1101 و 1183 و 1348 و 1876 و 1982 و 1995 و 1996 و 2065 و 2136 و 2137 و 2181 و 2308 و 2535 و 2673 و 2845 و 3425 و 3658 و 4033 و 4034 و 4035 و 4343 و 5936 و 5966 و 6604 و 7766 و 8482 و 8490 و 8767 .  
  7. ^ تشامبيكا ويجاياتونجا (فبراير 2015). “التعامل مع إساءة استخدام نظام أسماء النطاقات” (PDF) . APNIC . أرشفة (PDF) من النسخة الأصلية بتاريخ 22-12-2015 . تم الاسترجاع 18 ديسمبر 2016 .
  8. ↑ ج. كلينسين (فبراير 2003). دور نظام أسماء النطاقات (DNS) . مجموعة عمل الشبكة. doi : 10.17487/RFC3467 . RFC 3467 .معلوماتي.
  9. ↑ ليو، كريكيت؛ ألبيتز، بول (2006). نظام أسماء النطاقات (DNS) وBIND ( الطبعة الخامسة). دار نشر أورايلي. ص 3. ISBN   978-0-596-10057-5.
  10. ↑ إيفانز 2018 ، ص 112.
  11. ↑ إيفانز 2018 ، ص 113.
  12. ↑ حوليات IEEE [3B2-9] man2011030074.3d 29/7/2011 11:54 الصفحة 74
  13. 1 2 "لماذا لا يزال الإنترنت يعمل في عيد الميلاد؟ بول موكابيتريس - قاعة مشاهير الإنترنت" . internethalloffame.org . 23 يوليو 2012.
  14. 1 2 إيفانز 2018 ، ص. 119.
  15. ↑ إيفانز 2018 ، ص 120.
  16. ↑ إيفانز 2018 ، ص 120-121.
  17. ↑ "إليزابيث فاينلر" . قاعة مشاهير الإنترنت . مؤرشف من الأصل في 14 سبتمبر 2018. تم الاسترجاع في 25 نوفمبر 2018 .
  18. ↑ "بول موكابتريس | قاعة مشاهير الإنترنت" . internethalloffame.org . تم الاطلاع عليه بتاريخ 12 فبراير 2020 .
  19. ↑ أندريه روباتشيفسكي (26 نوفمبر 2013). "عيد ميلاد سعيد يا نظام أسماء النطاقات (DNS) بمناسبة مرور 30 ​​عامًا!" . جمعية الإنترنت . تم الاطلاع عليه بتاريخ 18 ديسمبر 2015 .
  20. ↑ إليزابيث فاينلر، حوليات معهد مهندسي الكهرباء والإلكترونيات، 3B2-9 man2011030074.3d 29/7/2011 11:54 الصفحة 74
  21. ↑ ب. موكابيتريس (فبراير 1986). تغييرات وملاحظات نظام النطاق . مجموعة عمل الشبكة. doi : 10.17487/RFC0973 . RFC 973 .مُلغى. تم إلغاؤه بموجب RFC 1034 و 1035 . تحديثات RFC 882 و 883 .  
  22. ↑ تيري، دوغلاس ب.؛ وآخرون . (12-15 يونيو 1984). "خادم أسماء نطاقات الإنترنت في بيركلي" . المؤتمر الصيفي، سولت ليك سيتي 1984: وقائع المؤتمر . مجموعة مستخدمي أدوات البرمجيات التابعة لجمعية USENIX. الصفحات 23-31 .  
  23. ↑ اتحاد أنظمة الإنترنت. "تاريخ BIND" . تاريخ BIND. مؤرشف من الأصل بتاريخ 30 يونيو 2019. تم الاطلاع عليه بتاريخ 4 أبريل 2022 .
  24. 1 2 3 4 5 6 7 8 ب. موكابيتريس (نوفمبر 1987). أسماء النطاقات - المفاهيم والتسهيلات . مجموعة عمل الشبكة. doi : 10.17487/RFC1034 . STD 13. RFC 1034 .المعيار 13 للإنترنت . يلغي المعايير RFC 882 و 883 و 973 . تم تحديثه بواسطة المعايير RFC 1101 و 1183 و 1348 و 1876 و 1982 و 2065 و 2181 و 2308 و 2535 و 4033 و 4034 و 4035 و 4343 و 4592 و 5936 و 8020 و 8482 و 8767 .  
  25. 1 2 ب. هوفمان؛ أ. سوليفان؛ ك. فوجيوارا (ديسمبر 2015). مصطلحات نظام أسماء النطاقات (DNS ). فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7719 . ISSN 2070-1721 . RFC 7719 . قديم. تم إلغاؤه بموجب RFC 8499 . 
  26. ↑ ليندسي، ديفيد (2007). قانون أسماء النطاقات الدولي: ICANN وUDRP . دار بلومزبري للنشر. ص 8. ISBN  978-1-84113-584-7.
  27. ↑ د. إيستليك الثالث (يناير 2006). توضيح عدم حساسية نظام أسماء النطاقات (DNS) لحالة الأحرف . مجموعة عمل الشبكة. doi : 10.17487/RFC4343 . RFC 4343 .معيار مقترح. تم تحديثه بواسطة RFC 5890. تحديثات RFC 1034 و 1035 و 2181 .  
  28. 1 2 ج. كلينسين (فبراير 2004). تقنيات تطبيقية للتحقق من الأسماء وتحويلها . مجموعة عمل الشبكة. doi : 10.17487/RFC3696 . RFC 3696 .معلوماتي.
  29. ↑ لوي، كريكيت؛ ألبيتز، بول (1993). DNS وBIND . أورايلي وشركاؤه. ص 183. ISBN  1-56592-010-4.
  30. ↑ فوجيوارا، كازونوري؛ سوليفان، أندرو؛ هوفمان، بول (2024). "مصطلحات نظام أسماء النطاقات" . tools.ietf.org . doi : 10.17487/RFC9499 . تاريخ الاسترجاع: 1 يوليو 2024 .
  31. ↑ نيميث، إيفي؛ سنايدر، غارث؛ هاين، ترينت ر. (30-10-2006). دليل إدارة لينكس . أديسون-ويسلي بروفيشنال. ISBN 978-0-13-700275-7.
  32. ^ بيسياندي، تيجاويندي ف. سي أومارو (2017/10/09). البنية التحتية والخدمات الإلكترونية للدول النامية: المؤتمر الدولي الثامن، أفريكوم 2016، واغادوغو، بوركينا فاسو، 6-7 ديسمبر 2016، وقائع . سبرينغر. رقم ISBN 978-3-319-66742-3.
  33. ↑ "منطقة نظام أسماء النطاقات" . دليل IONOS الرقمي . 27 يناير 2022. تم الاطلاع عليه بتاريخ 31 مارس 2022 .
  34. ↑ "ما هو انتشار نظام أسماء النطاقات؟" . دليل IONOS الرقمي . تم الاطلاع عليه بتاريخ 22-04-2022 .
  35. ↑ "هل يتجاهل مزودو الخدمة مدة صلاحية نظام أسماء النطاقات (DNS TTL)؟" . سلاش دوت . 2005. تم الاطلاع عليه بتاريخ 7 أبريل 2012 .
  36. ↑ بن أندرسون (7 سبتمبر 2011). "بن أندرسون: لماذا يُعدّ تخزين نظام أسماء النطاقات (DNS) مؤقتًا في متصفح الويب أمرًا سيئًا" . تم الاطلاع عليه بتاريخ 20 أكتوبر 2014 .
  37. ↑ "معلمات نظام أسماء النطاقات (DNS)" . هيئة الأرقام المخصصة للإنترنت (IANA ). رموز استجابة نظام أسماء النطاقات (DNS RCODEs ). تم الاطلاع عليه بتاريخ 14 يونيو 2019 .
  38. ↑ جيمس ف. كوروز وكيث و. روس، شبكات الحاسوب: منهج من أعلى إلى أسفل، الطبعة السادسة. إسيكس، إنجلترا: بيرسون إديوك. ليمتد، 2012
  39. 1 2 د. إيستليك الثالث (أبريل 2013). اعتبارات نظام أسماء النطاقات (DNS) من هيئة تخصيص أرقام الإنترنت (IANA) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6895 . ISSN 2070-1721 . BCP 42. RFC 6895 . أفضل الممارسات الحالية 42. تلغي RFC 6195. تحديثات RFC 2845 و 2930 و 1183 و 3597 .  
  40. 1 2 إي. لويس (يوليو 2006). دور الأحرف البديلة في نظام أسماء النطاقات . مجموعة عمل الشبكة. doi : 10.17487/RFC4592 . RFC 4592 .المعيار المقترح. تحديثات RFC 2672 و 1034 . 
  41. ↑ إس. طومسون؛ واي. ريختر ؛ جيه. باوند (أبريل 1997). بي. فيكسي (محرر). التحديثات الديناميكية في نظام أسماء النطاقات (DNS UPDATE) . مجموعة عمل الشبكة التابعة لـ IETF . doi : 10.17487/RFC2136 . RFC 2136 .معيار مقترح. تحديثات RFC 1035. تم تحديثه بواسطة RFC 3007 و 4033 و 4034 و 4035 .  
  42. ↑ RFC 2671 ، آليات التمديد لنظام أسماء النطاقات (EDNS0) ، بقلم ب. فيكسي (أغسطس 1999) 
  43. ↑ سيكور، ليفينتي؛ ديفاكاران، دينيل مون (فبراير 2021). "خصوصية نظام أسماء النطاقات عبر بروتوكول HTTPS: هل هي رثاء لحلم؟" (ملف PDF) . الجامعة الوطنية في سنغافورة. نبحث فيما إذا كان بالإمكان التمييز بين حركة مرور بروتوكول DoH وحركة مرور الويب المشفرة. ولتحقيق هذه الغاية، ندرب نموذجًا للتعلم الآلي لتصنيف حركة مرور HTTPS إما على أنها ويب أو DoH. وباستخدام نموذج تحديد DoH الخاص بنا، نُظهر أن مزود خدمة إنترنت استبداديًا يمكنه تحديد ما يقارب 97.4% من حزم DoH بشكل صحيح، بينما يخطئ في تصنيف حزمة واحدة فقط من بين كل 10000 حزمة ويب.
  44. ↑ هويتيما، كريستيان؛ ديكنسون، سارة؛ مانكين، أليسون (مايو 2022). نظام أسماء النطاقات عبر اتصالات QUIC المخصصة . فريق عمل هندسة الإنترنت. doi : 10.17487/RFC9250 . RFC 9250 .
  45. ↑ ليندرز، مارتين صوفي؛ أمسوس، كريستيان؛ غوندوغان، سينك؛ شميدت، توماس سي؛ فاليش، ماتياس (مارس 2026). نظام أسماء النطاقات عبر بروتوكول CoAP (وثيقة المطابقة) (تقرير). فريق عمل هندسة الإنترنت. doi : 10.17487/RFC9953 .
  46. ↑ ليندرز، مارتين س.؛ أمسوس، كريستيان؛ غوندوغان، سينك؛ ناووركي، مارسين؛ شميدت، توماس س.؛ فاليش، ماتياس (28-09-2023). "تأمين حل أسماء النطاقات في إنترنت الأشياء: نظام أسماء النطاقات عبر بروتوكول CoAP" . وقائع مؤتمر ACM للشبكات . 1 (CoNEXT2): 1-25 . doi : 10.1145/3609423 . ISSN 2834-5509 . 
  47. ↑ شميت، بول؛ إدموندسون، آن؛ فيمستر، نيك (2019). "نظام أسماء النطاقات الخفي: خصوصية عملية لاستعلامات نظام أسماء النطاقات" ( ملف PDF) . تقنيات تعزيز الخصوصية . 2019 (2): 228-244 . arXiv : 1806.00276 . doi : 10.2478/popets-2019-0028 . S2CID 44126163. مؤرشف (ملف PDF) من النسخة الأصلية بتاريخ 21 يناير 2022. 
  48. ↑ "نظام أسماء النطاقات غير الواعي الذي نشرته شركتا كلاود فلير وآبل" . 9 ديسمبر 2020. تم الاطلاع عليه بتاريخ 27 يوليو 2022 .
  49. ↑ باولي، تومي (2 سبتمبر 2021). "نظام أسماء النطاقات غير الواعي عبر بروتوكول HTTPS" . IETF.
  50. ↑ موفيت، أليك (فبراير 2021). ""لا يوجد منفذ 53، من هذا؟ عام من نظام أسماء النطاقات عبر HTTPS عبر تور" (ملف PDF) . ندوة أمن الشبكات والأنظمة الموزعة. مؤرشف (ملف PDF) من الأصل بتاريخ 21 مارس 2021. يُزيل نظام أسماء النطاقات عبر HTTPS (DoH) العديد من المخاطر، ولكن ليس جميعها، كما أن بروتوكول النقل الخاص به (أي HTTPS) يُثير مخاوف بشأن الخصوصية بسبب (على سبيل المثال) ملفات تعريف الارتباط. وُجدت شبكة تور لتوفير بعض الحرية لدوائر TCP من التتبع والمراقبة والحظر. وبالتالي: بالاشتراك مع تور، وDoH، ومبدأ "لا تفعل ذلك، إذن" (DDTT) للتخفيف من بصمات الطلبات، أصف نظام أسماء النطاقات عبر HTTPS عبر تور (DoHoT).
  51. ↑ أوليفيتش، ديفيد (6 ديسمبر 2011). "DNSCrypt - أمر بالغ الأهمية، وأساسي، وفي وقته المناسب" . سيسكو أمبريلا . مؤرشف من الأصل في 1 يوليو 2020.
  52. ↑ "مواصفات DNSCrypt المجهولة" . GitHub . DNSCrypt. مؤرشف من الأصل في 25 أكتوبر 2019.
  53. ↑ "Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki" . GitHub . مشروع DNSCrypt . تم الاطلاع عليه بتاريخ 28 يوليو 2022 .
  54. ↑ هيرزبيرغ، أمير؛ شولمان، هايا (1 يناير 2014). "تحديث بروتوكولات الشبكة الأمنية: حالة DNSSEC". مجلة IEEE للحوسبة عبر الإنترنت . 18 (1): 66-71 . Bibcode : 2014IIC....18a..66H . doi : 10.1109/MIC.2014.14 . ISSN 1089-7801 . S2CID 12230888 .  
  55. ↑ APWG. "دراسة استقصائية عالمية حول التصيد الاحتيالي: استخدام أسماء النطاقات والاتجاهات في النصف الأول من عام 2010." 15/10/2010 apwg.org مؤرشف في 3 أكتوبر 2012 على موقع Wayback Machine
  56. ↑ "DNSMessenger (عائلة البرامج الضارة)" . malpedia.caad.fkie.fraunhofer.de . تم الاطلاع عليه بتاريخ 11-12-2024 .
  57. ↑ خانديلوال، سواتي (2017-03-06). "برمجيات خبيثة جديدة لا تستخدم الملفات تستغل استعلامات نظام أسماء النطاقات (DNS) لتلقي أوامر باور شيل" . ذا هاكر نيوز . تم الاطلاع عليه بتاريخ 2024-12-11 .
  58. ↑ بروماجين، إدموند (2017-03-02). "قنوات سرية وقرارات خاطئة: قصة DNSMessenger" . مدونة سيسكو تالوس . تم الاطلاع عليه بتاريخ 2024-12-11 .
  59. ↑ بومبال، ديفيد (26 مايو 2023). مشكلة نظام أسماء النطاقات (DNS) مجدداً 😢 هل تعلم بهذا الاختراق البرمجي الخبيث؟ . تم الاطلاع عليه بتاريخ 11 ديسمبر 2024 – عبر يوتيوب.
  60. 1 2 هيوستن، جيف (يوليو 2019). "خصوصية نظام أسماء النطاقات وفريق عمل هندسة الإنترنت" (ملف PDF) . مجلة بروتوكول الإنترنت . مؤرشف (ملف PDF) من الأصل بتاريخ 30 سبتمبر 2019.
  61. ↑ "الملف التعريفي التشغيلي لبروتوكول الوصول إلى بيانات التسجيل (RDAP) لسجلات ومسجلي نطاقات المستوى الأعلى العامة" . ICANN . 3 ديسمبر 2015. مؤرشف من الأصل في 22 ديسمبر 2015. تم الاطلاع عليه في 18 ديسمبر 2015 .
  62. ↑ "ابحث عن مسجل نطاقات" . شركة VeriSign . تم الاطلاع عليه بتاريخ 18 ديسمبر 2015 .

مصادر

للمزيد من القراءة

مسار المعايير

  • RFC 1034 – " أسماء النطاقات - المفاهيم والمرافق " ، معيار الإنترنت 13. 
  • RFC 1035 – " أسماء النطاقات - التنفيذ والمواصفات " ، معيار الإنترنت 13. 
  • RFC 1123 – " متطلبات مضيفي الإنترنت - التطبيق والدعم " ، معيار الإنترنت 3. 
  • RFC 1995 – " نقل المنطقة التدريجي في نظام أسماء النطاقات " ، المعيار المقترح. 
  • RFC 1996 – " آلية للإخطار الفوري بتغييرات المنطقة (DNS NOTIFY) " ، معيار مقترح. 
  • RFC 2136 – " التحديثات الديناميكية في نظام أسماء النطاقات (DNS UPDATE) " ، المعيار المقترح. 
  • RFC 2181 – " توضيحات لمواصفات نظام أسماء النطاقات " ، المعيار المقترح. 
  • RFC 2308 – " التخزين المؤقت السلبي لاستعلامات نظام أسماء النطاقات (DNS NCACHE) " ، معيار مقترح. 
  • RFC 3225 – " الإشارة إلى دعم محلل DNSSEC " ، المعيار المقترح. 
  • RFC 3226 – " متطلبات حجم رسالة الخادم/المحلل المدركة لـ DNSSEC و IPv6 A6، " معيار مقترح. 
  • RFC 3596 – " امتدادات DNS لدعم الإصدار 6 من IP، " معيار الإنترنت 88. 
  • RFC 3597 – " معالجة أنواع سجلات موارد نظام أسماء النطاقات غير المعروفة (RR) " ، معيار مقترح. 
  • RFC 4343 – " توضيح عدم حساسية حالة الأحرف في نظام أسماء النطاقات (DNS) " ، المعيار المقترح. 
  • RFC 4592 – " دور الأحرف البديلة في نظام أسماء النطاقات " ، معيار مقترح. 
  • RFC 5001 – " خيار معرف خادم اسم نظام أسماء النطاقات (NSID) " ، المعيار المقترح. 
  • RFC 5011 – " التحديثات التلقائية لمرساة الثقة لأمان نظام أسماء النطاقات (DNSSEC) " ، معيار الإنترنت 74. 
  • RFC 5452 – " تدابير لجعل نظام أسماء النطاقات أكثر مرونة ضد الإجابات المزيفة، " معيار مقترح. 
  • RFC 5890 – " أسماء النطاقات الدولية للتطبيقات (IDNA): التعريفات وإطار الوثائق، " المعيار المقترح. 
  • RFC 5891 – " أسماء النطاقات الدولية في التطبيقات (IDNA): البروتوكول، " المعيار المقترح. 
  • RFC 5892 – " نقاط ترميز Unicode وأسماء النطاقات الدولية للتطبيقات (IDNA) " ، المعيار المقترح. 
  • RFC 5893 – " النصوص من اليمين إلى اليسار لأسماء النطاقات الدولية للتطبيقات (IDNA) " ، المعيار المقترح. 
  • RFC 6672 – " إعادة توجيه DNAME في نظام أسماء النطاقات " ، معيار مقترح. 
  • RFC 6891 – " آليات التمديد لنظام أسماء النطاقات (EDNS(0))، " معيار الإنترنت 75. 
  • RFC 7766 – " نقل DNS عبر TCP - متطلبات التنفيذ، " معيار مقترح. 
  • RFC 8490 – " عمليات DNS ذات الحالة " ، معيار مقترح. 
  • RFC 8945 – " مصادقة المعاملات باستخدام المفتاح السري لنظام أسماء النطاقات (TSIG) " ، معيار الإنترنت 93. 
  • RFC 9103 – " نقل منطقة DNS عبر TLS، " معيار مقترح. 
  • RFC 9156 – " تقليل اسم استعلام DNS لتحسين الخصوصية " ، معيار مقترح. 

معايير الأمان المقترحة

  • RFC 4033 – " مقدمة ومتطلبات أمان نظام أسماء النطاقات " ، المعيار المقترح. 
  • RFC 4034 – " سجلات الموارد لملحقات أمان نظام أسماء النطاقات " ، معيار مقترح. 
  • RFC 4035 – " تعديلات البروتوكول لملحقات أمان نظام أسماء النطاقات " ، المعيار المقترح. 
  • RFC 4470 – " تغطية سجلات NSEC بشكل محدود وتوقيع DNSSEC عبر الإنترنت، " معيار مقترح. 
  • RFC 4509 – " استخدام SHA-256 في سجلات موارد التوقيع التفويضي لـ DNSSEC (DS) (RRs) " ، المعيار المقترح. 
  • RFC 5155 – " أمن نظام أسماء النطاقات (DNSSEC) رفض الوجود الموثق المجزأ، " معيار مقترح. 
  • RFC 5702 – " استخدام خوارزميات SHA-2 مع RSA في سجلات موارد DNSKEY وRRSIG لـ DNSSEC، " معيار مقترح. 
  • RFC 5910 – " تعيين ملحقات أمان نظام أسماء النطاقات (DNS) لبروتوكول التزويد القابل للتوسيع (EPP) " ، معيار مقترح. 
  • RFC 5933 – " استخدام خوارزميات توقيع GOST في سجلات موارد DNSKEY وRRSIG لبروتوكول DNSSEC " ، تاريخي. تم تغيير حالته إلى تاريخي في عام 2024 بموجب RFC 9558. تم تحديثه بموجب RFC 6944. (انظر قسم RFCs المعلوماتية )   
  • RFC 7830 – " خيار الحشو EDNS(0) " ، المعيار المقترح. 
  • RFC 7858 – " مواصفات نظام أسماء النطاقات عبر أمان طبقة النقل (TLS) " ، المعيار المقترح. 
  • RFC 8310 – " ملفات تعريف الاستخدام لـ DNS عبر TLS و DNS عبر DTLS، " معيار مقترح. 
  • RFC 8484 – " استعلامات نظام أسماء النطاقات عبر HTTPS (DoH) " ، المعيار المقترح. 

نماذج RFC تجريبية

  • RFC 1183 – " تعريفات سجلات DNS الجديدة، " تجريبي. 

أفضل الممارسات الحالية

  • RFC 2182 – " اختيار وتشغيل خوادم DNS الثانوية، " أفضل الممارسات الحالية 16. 
  • RFC 2317 – " تفويض IN-ADDR.ARPA بدون فئات، " أفضل الممارسات الحالية 20. 
  • RFC 5625 – " إرشادات تنفيذ وكيل DNS، " أفضل الممارسات الحالية 152. 
  • RFC 6895 – " اعتبارات نظام أسماء النطاقات (DNS) IANA، " أفضل الممارسات الحالية 42. 
  • RFC 7720 – " بروتوكول خدمة اسم الجذر لنظام أسماء النطاقات ومتطلبات النشر، " أفضل الممارسات الحالية 40. 
  • RFC 9499 – " مصطلحات نظام أسماء النطاقات"، " أفضل الممارسات الحالية 219. 

طلبات التعليقات الإعلامية

تُعتبر هذه التعليقات المرجعية استشارية بطبيعتها، ولكنها قد توفر معلومات مفيدة على الرغم من أنها لا تحدد معيارًا أو خطة استمرارية الأعمال. [ 1 ]

  • RFC 1178 – " اختيار اسم لجهاز الكمبيوتر الخاص بك " ، معلوماتي، لمعلوماتك 5. 
  • RFC 1591 – " هيكل نظام أسماء النطاقات والتفويض، " معلوماتي. 
  • RFC 1912 – " أخطاء التشغيل والتكوين الشائعة لنظام أسماء النطاقات " ، معلوماتي. 
  • RFC 2100 – " تسمية المضيفين " ، معلوماتي. 
  • RFC 3696 – " تقنيات التطبيق للتحقق من الأسماء وتحويلها، " معلوماتي. 
  • RFC 3833 – " تحليل التهديدات لنظام أسماء النطاقات (DNS) " ، معلوماتي. 
  • RFC 4892 – " مصادقة التشفير RIPv2، " إعلامي. 
  • RFC 5894 – " أسماء النطاقات الدولية للتطبيقات (IDNA): الخلفية والشرح والأساس المنطقي، " معلوماتي. 
  • RFC 5895 – " تعيين الأحرف لأسماء النطاقات الدولية في التطبيقات (IDNA) 2008، " معلوماتي. 
  • RFC 8806 – " تشغيل خادم الجذر محليًا بالنسبة إلى محلل " ، معلوماتي. 
  • RFC 9076 – " اعتبارات خصوصية نظام أسماء النطاقات " ، معلوماتي. 
  • RFC 9558 – " استخدام خوارزميات التوقيع GOST 2012 في سجلات موارد DNSKEY وRRSIG لـ DNSSEC، " معلوماتي. 

مجهول

تتمتع هذه التعليقات (RFCs) بوضع رسمي غير معروف ، ولكن نظرًا لقدمها، لا يتم تصنيفها بوضوح على هذا النحو.

  • RFC 920 – " متطلبات النطاق " ، الحالة غير معروفة. – نطاقات المستوى الأعلى الأصلية المحددة 
  • RFC 1032 – " دليل مسؤولي النطاق " ، الحالة غير معروفة. 
  • RFC 1033 – " دليل عمليات مسؤولي النطاق " ، الحالة غير معروفة. 
  • RFC 1101 – " ترميز DNS لأسماء الشبكات وأنواع أخرى، " الحالة غير معروفة.