نظام اسم النطاق

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

خدمة اسم النطاق
بروتوكول الاتصالات
اختصارنظام اسم النطاق
غايةلتحديد الموارد على الشبكات
مقدمةنوفمبر 1983 ؛ منذ 41 عامًا (1983-11)
طبقة OSIطبقة التطبيق
المنفذ(ات)53
طلبات التعليقاتطلب التعليقات رقم 1034، طلب التعليقات رقم 1035
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer
  • v
  • t
  • e
الجدول الزمني لتاريخ الإنترنت

البحث والتطوير المبكر:

دمج الشبكات وإنشاء الإنترنت:

التسويق والخصخصة وتوسيع نطاق الوصول يؤدي إلى الإنترنت الحديث:

أمثلة على خدمات الإنترنت:

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

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

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

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

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

وظيفة

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

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

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

تاريخ

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

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

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

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

في عام 1984، كتب أربعة طلاب من جامعة كاليفورنيا في بيركلي ، وهم دوغلاس تيري ومارك بينتر وديفيد ريجلي وسونغنيان تشو، أول تنفيذ لخادم اسم يونكس لنطاق اسم الإنترنت في بيركلي، والذي يُشار إليه عادةً باسم BIND . [20] في عام 1985، قام كيفن دنلاب من DEC بمراجعة تنفيذ DNS بشكل كبير. ثم تولى مايك كارلز وفيل ألمكويست وبول فيكسي صيانة BIND. تم تأسيس Internet Systems Consortium في عام 1994 بواسطة ريك آدامز وبول فيكسي وكارل مالامود ، خصيصًا لتوفير موطن لتطوير وصيانة BIND. تم تطوير إصدارات BIND من 4.9.3 فصاعدًا وصيانتها بواسطة ISC، بدعم من رعاة ISC. بصفتهما مهندسين معماريين/مبرمجين مشاركين، أصدر بوب هالي وبول فيكسي أول إصدار جاهز للإنتاج من BIND الإصدار 8 في مايو 1997. ومنذ عام 2000، عمل أكثر من 43 مطورًا أساسيًا مختلفًا على BIND. [21]

في نوفمبر 1987، حلت RFC 1034 [22] وRFC 1035 [5] محل مواصفات DNS لعام 1983. واقترحت العديد من طلبات التعليقات الإضافية توسعات لبروتوكولات DNS الأساسية. [23]

بناء

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

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

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

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

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

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

تظهر الأوصاف النهائية لقواعد تشكيل أسماء النطاقات في 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 مع النقطة الخلفية). [22] في التمثيل الثنائي الداخلي لنظام أسماء النطاقات، يتطلب هذا الطول الأقصى البالغ 253 255 بايت من التخزين، لأنه يخزن أيضًا طول أول العديد من العلامات ويضيف آخر بايت فارغ. [5] يتم تحقيق الطول 255 فقط مع 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 معتمد واحد على الأقل ينشر معلومات حول هذا النطاق وخوادم الأسماء لأي نطاقات تابعة له. يتم تقديم الجزء العلوي من التسلسل الهرمي بواسطة خوادم الأسماء الجذرية ، وهي الخوادم التي يتم الاستعلام عنها عند البحث عن ( حل ) نطاق المستوى الأعلى .

خادم الاسم المعتمد

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

يمكن أن يكون خادم الأسماء المعتمد إما خادمًا أساسيًا أو خادمًا ثانويًا . تاريخيًا، كانت المصطلحات master/slave و primary/secondary تُستخدم أحيانًا بالتبادل [29] ولكن الممارسة الحالية هي استخدام الشكل الأخير. الخادم الأساسي هو خادم يخزن النسخ الأصلية لجميع سجلات المنطقة. يستخدم الخادم الثانوي آلية تحديث تلقائية خاصة في بروتوكول DNS في التواصل مع خادمه الأساسي للحفاظ على نسخة متطابقة من السجلات الأساسية.

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

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

عندما يتم تعيين خادم اسم كخادم معتمد لاسم نطاق لا يحتوي على بيانات معتمدة له، فإنه يعرض نوعًا من الخطأ يسمى "التفويض الضعيف" أو "الاستجابة الضعيفة". [30] [31]

عملية

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

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

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

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

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

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

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

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

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

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

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

مُحللات DNS

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

في الاستعلام غير المتكرر ، يستعلم مُحلل DNS عن خادم DNS الذي يوفر سجلاً يكون الخادم معتمدًا عليه، أو يوفر نتيجة جزئية دون الاستعلام عن خوادم أخرى. في حالة مُحلل 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 مادة لاصقة مع التفويض لـ example.org. وسجلات المادة اللاصقة هي سجلات عناوين توفر عناوين IP لـ ns1.example.org. ويستخدم المحلل عنوان IP واحدًا أو أكثر من هذه العناوين للاستعلام من أحد خوادم النطاق المعتمدة، مما يسمح له بإكمال استعلام DNS.

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

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

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

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

البحث العكسي

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

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

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

تسلسل حل DNS

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

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

الحلول المكسورة

لقد قامت بعض شركات تقديم خدمات الإنترنت الكبيرة بتكوين خوادم DNS الخاصة بها لانتهاك القواعد، مثل عدم الامتثال لـ TTLs، أو الإشارة إلى أن اسم المجال غير موجود لمجرد أن أحد خوادم الأسماء الخاصة به لا يستجيب. [34]

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

يمثل Internet Explorer استثناءً ملحوظًا: حيث تقوم الإصدارات حتى IE 3.x بتخزين سجلات DNS مؤقتًا لمدة 24 ساعة افتراضيًا. يقوم Internet Explorer 4.x والإصدارات الأحدث (حتى IE 8) بخفض قيمة مهلة الانتظار الافتراضية إلى نصف ساعة، والتي يمكن تغييرها عن طريق تعديل التكوين الافتراضي. [36]

عندما يكتشف Google Chrome مشكلات في خادم DNS، فإنه يعرض رسالة خطأ محددة.

تطبيقات أخرى

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

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

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

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

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

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

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

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

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

تنسيق رسالة DNS

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

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

تنسيق أعلام الرأس
مجال وصف الطول ( بت )
رمز الاستجابة السريعة يشير إلى ما إذا كانت الرسالة عبارة عن استعلام (0) أو رد (1) 1
رمز التشغيل يمكن أن يكون النوع QUERY (استعلام قياسي، 0)، أو IQUERY (استعلام عكسي، 1)، أو STATUS (طلب حالة الخادم، 2) 4
أأ الإجابة المعتمدة، في الاستجابة، تشير إلى ما إذا كان خادم DNS معتمدًا لاسم المضيف المطلوب الاستعلام عنه 1
تي سي يشير TrunCation إلى أن هذه الرسالة تم اقتطاعها بسبب الطول الزائد 1
ر د التكرار المرغوب فيه، يشير إلى ما إذا كان العميل يقصد استعلامًا متكررًا 1
را يشير "التكرار المتاح"، في الاستجابة، إلى ما إذا كان خادم DNS الذي يرد يدعم التكرار 1
ز صفر، محجوز للاستخدام في المستقبل 3
رمز R يمكن أن يكون رمز الاستجابة NOERROR (0)، FORMERR (1، خطأ في التنسيق)، SERVFAIL (2)، NXDOMAIN (3، مجال غير موجود)، وما إلى ذلك. [37] 4

بعد كلمة الأعلام، ينتهي الرأس بأربعة أعداد صحيحة مكونة من 16 بت تحتوي على عدد السجلات في كل قسم من الأقسام التالية، بنفس الترتيب.

رأس DNS
الإزاحات 0 1 2 3
ثماني بتات قليل 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
0 0 معرف المعاملة الأعلام
رمز الاستجابة السريعة رمز التشغيل أأ تي سي ر د را ز رمز R
4 32 عدد الأسئلة عدد الاجابات
8 64 عدد سلطات RR عدد RRs الإضافية

قسم الأسئلة

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

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

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

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

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

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

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

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

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

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

يتم تعيين فئة السجل على IN (بالنسبة للإنترنت ) لسجلات DNS الشائعة التي تتضمن أسماء مضيفين للإنترنت أو خوادم أو عناوين IP. بالإضافة إلى ذلك، توجد فئات Chaos ( CH) و Hesiod (HS). [40] كل فئة عبارة عن مساحة اسم مستقلة مع تفويضات مختلفة محتملة لمناطق DNS.

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

سجلات البطاقة البرية

يدعم نظام اسم المجال سجلات DNS ذات الأحرف البدل والتي تحدد الأسماء التي تبدأ بعلامة النجمة ، *، على سبيل المثال، *.example. [22] [41] تحدد سجلات DNS التي تنتمي إلى أسماء المجالات ذات الأحرف البدل قواعد إنشاء سجلات الموارد داخل منطقة DNS واحدة عن طريق استبدال العلامات الكاملة بمكونات مطابقة لاسم الاستعلام، بما في ذلك أي أحفاد محددين. على سبيل المثال، في التكوين التالي، تحدد منطقة DNS x.example أن جميع المجالات الفرعية، بما في ذلك المجالات الفرعية للمجالات الفرعية، في x.example تستخدم مبادل البريد (MX) axexample . السجل A لـ 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 كان غير مكتمل وأدى إلى تفسيرات خاطئة من قبل المنفذين. [41]

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

كان بروتوكول DNS الأصلي يحتوي على أحكام محدودة للتمديد بميزات جديدة. في عام 1999، نشر بول فيكسي في RFC 2671 (الذي حل محله RFC 6891) آلية تمديد، تسمى آليات التمديد لـ DNS (EDNS) والتي قدمت عناصر بروتوكول اختيارية دون زيادة النفقات العامة عند عدم الاستخدام. تم تحقيق ذلك من خلال سجل الموارد الزائف OPT الذي يوجد فقط في عمليات النقل السلكية للبروتوكول، ولكن ليس في أي ملفات منطقة. تم اقتراح التمديدات الأولية أيضًا (EDNS0)، مثل زيادة حجم رسالة DNS في بيانات UDP.

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

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

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

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

DNS عبر UDP/TCP/53 (Do53)

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

DNS عبر TLS (DoT)

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

DNS عبر HTTPS (DoH)

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

DNS عبر QUIC (DoQ)

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

Oblivious DoH (ODoH) وOblivious DNS (ODNS) السابق

تم اختراع وتنفيذ نظام DNS غير المشفر (ODNS) من قبل باحثين في جامعة برينستون وجامعة شيكاغو كامتداد لنظام DNS غير المشفر، [46] قبل توحيد DoH ونشره على نطاق واسع. قامت Apple وCloudflare بعد ذلك بنشر التكنولوجيا في سياق DoH، باسم Oblivious DoH (ODoH). [47] يجمع ODoH بين فصل الدخول والخروج (اخترع في ODNS) مع نفق HTTPS الخاص بـ DoH وتشفير طبقة النقل TLS في بروتوكول واحد. [48]

DNS عبر Tor

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

دي إن إس كريبت

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

القضايا الأمنية

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

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

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

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

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

انتحال DNS

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

برنامج DNSMessenger

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

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

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

قضايا الخصوصية والتتبع

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

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

الأساليب الرئيسية المستخدمة لمواجهة مشكلات الخصوصية مع DNS:

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

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

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

—  خصوصية DNS و IETF

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

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

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

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

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

انظر أيضا

مراجع

  1. ^ وو، هاو؛ دانج، شيانجلي؛ وانج، ليدونج؛ هي، لونجتاو (2016). "طريقة تعتمد على دمج المعلومات للكشف عن هجمات تسميم ذاكرة التخزين المؤقت لنظام أسماء النطاقات الموزعة وتحديد هويتها". أمن معلومات IET . 10 (1): 37– 44. doi :10.1049/iet-ifs.2014.0386. ISSN  1751-8717. S2CID  45091791.
  2. ^ RFC 781، مواصفات بروتوكول برنامج الإنترنت التابع لوكالة مشاريع الأبحاث الدفاعية المتقدمة (DARPA) ، معهد علوم المعلومات، جيه بوستل (المحرر)، جمعية الإنترنت (سبتمبر 1981)
  3. ^ J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, and B. Weihl. "Globally Distributed Content Delivery, IEEE Internet Computing, September/October 2002, pp. 50–58" (PDF) . مؤرشف من الأصل (PDF) في 17 أبريل 2015.
  4. ^ Nygren., E.; Sitaraman RK; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" (PDF) . مراجعة أنظمة التشغيل ACM SIGOPS . 44 (3): 2– 19. doi :10.1145/1842733.1842736. S2CID  207181702. مؤرشف من الأصل (PDF) في 2010-12-02 . تم الاسترجاع في 19 نوفمبر 2012 .
  5. ^ abcdef Mockapetris, Paul (نوفمبر 1987). أسماء النطاقات - التنفيذ والمواصفات. IETF . doi : 10.17487/RFC1035 . RFC 1035.
  6. ^ تشامبيكا ويجاياتونجا (فبراير 2015). “التعامل مع إساءة استخدام نظام أسماء النطاقات” (PDF) . APNIC . أرشفة (PDF) من النسخة الأصلية بتاريخ 22-12-2015 . تم الاسترجاع 18 ديسمبر 2016 .
  7. ^ J. Klensin (فبراير 2003). دور نظام أسماء النطاقات (DNS). مجموعة عمل الشبكة. doi : 10.17487/RFC3467 . RFC 3467. إعلامية.
  8. ^ ليو، كريكيت؛ ألبيتز، بول (2006). DNS وBIND (الطبعة الخامسة). أوريلي ميديا. ص. 3. ISBN 978-0-596-10057-5.
  9. ^ إيفانز 2018، ص 112.
  10. ^ إيفانز 2018، ص 113.
  11. ^ IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 صفحة 74
  12. ^ "لماذا لا تزال الشبكة تعمل في عيد الميلاد؟ بول موكابيتريس - قاعة مشاهير الإنترنت". internethalloffame.org . 23 يوليو 2012.
  13. ^ ab Evans 2018، ص 119.
  14. ^ إيفانز 2018، ص 120.
  15. ^ إيفانز 2018، ص 120-121.
  16. ^ "إليزابيث فينلر". قاعة مشاهير الإنترنت . مؤرشف من الأصل في 14 سبتمبر 2018. تم الاسترجاع 2018-11-25 .
  17. ^ "بول موكابيتريس | قاعة مشاهير الإنترنت". internethalloffame.org . تم الاسترجاع في 12 فبراير 2020 .
  18. ^ أندريه روباتشيفسكي (26 نوفمبر 2013). "عيد ميلاد سعيد الثلاثين، DNS!". جمعية الإنترنت . تم الاسترجاع في 18 ديسمبر 2015 .
  19. ^ إليزابيث فينلر، IEEE Annals، 3B2-9 man2011030074.3d 29/7/011 11:54 صفحة 74
  20. ^ تيري، دوغلاس ب.؛ وآخرون. (12-15 يونيو 1984). "خادم اسم النطاق على الإنترنت في بيركلي". المؤتمر الصيفي، سولت ليك سيتي 1984: الإجراءات . مجموعة مستخدمي أدوات برمجيات رابطة USENIX. ص  23-31 .
  21. ^ اتحاد أنظمة الإنترنت. "تاريخ BIND". تاريخ BIND. مؤرشف من الأصل في 2019-06-30 . تم الاسترجاع 4 أبريل 2022 .
  22. ^ abcde Mockapetris, Paul (نوفمبر 1987). أسماء النطاقات - مفاهيم النطاقات والمرافق. IETF . doi : 10.17487/RFC1034 . RFC 1034.
  23. ^ أب بول هوفمان. أندرو سوليفان؛ كازونوري فوجيوارا (ديسمبر 2015). مصطلحات DNS. فريق عمل الإنترنت . دوى : 10.17487/RFC7719 . آر إف سي 7719 . تم الاسترجاع 18 ديسمبر 2015 .
  24. ^ بول موكابيتريس (نوفمبر 1987). "مواصفات ومصطلحات مساحة الأسماء". أسماء النطاقات - مفاهيم النطاقات والمرافق. IETF . القسم 3.1. doi : 10.17487/RFC1034 . RFC 1034 . تم الاسترجاع في 17 ديسمبر 2015 .
  25. ^ ab Paul Mockapetris (نوفمبر 1987). "كيف يتم تقسيم قاعدة البيانات إلى مناطق". أسماء النطاقات - مفاهيم النطاقات والمرافق. IETF . القسم 4.2. doi : 10.17487/RFC1034 . RFC 1034 . تم الاسترجاع في 17 ديسمبر 2015 .
  26. ^ ليندسي، ديفيد (2007). قانون أسماء النطاقات الدولي: ICANN وUDRP . دار بلومزبري للنشر. ص. 8. ISBN 978-1-84113-584-7.
  27. ^ D. Eastlake, 3rd (January 2006). توضيح عدم حساسية نظام أسماء النطاقات (DNS) لحالة الأحرف. مجموعة عمل الشبكة. doi : 10.17487/RFC4343 . RFC 4343. المعيار المقترح. تم تحديثه بموجب RFC 5890. تحديثات RFC 1034 و1035 و2181.
  28. ^ ab J. Klensin (فبراير 2004). تقنيات التطبيق للتحقق من الأسماء وتحويلها. مجموعة عمل الشبكة. doi : 10.17487/RFC3696 . RFC 3696. إعلامية.
  29. ^ فوجيوارا، كازونوري؛ سوليفان، أندرو؛ هوفمان، بول (2024). "مصطلحات DNS". tools.ietf.org . doi :10.17487/RFC9499 . تم الاسترجاع في 2024-07-01 .
  30. ^ Nemeth, Evi; Snyder, Garth; Hein, Trent R. (2006-10-30). دليل إدارة لينكس. Addison-Wesley Professional. ISBN 978-0-13-700275-7.
  31. ^ بيسياندي ، تيجاويندي ف. سي أومارو (2017/10/09). البنية التحتية الإلكترونية والخدمات الإلكترونية للبلدان النامية: المؤتمر الدولي الثامن، أفريكوم 2016، واغادوغو، بوركينا فاسو، 6-7 ديسمبر 2016، وقائع. سبرينغر. رقم ISBN 978-3-319-66742-3.
  32. ^ "منطقة DNS". IONOS Digitalguide . 27 يناير 2022 . تم الاسترجاع في 2022-03-31 .
  33. ^ "ما هو انتشار DNS؟". IONOS Digitalguide . تم الاسترجاع في 2022-04-22 .
  34. ^ "مقدمو الخدمة يتجاهلون مدة صلاحية DNS؟". Slashdot . 2005 . تم الاسترجاع في 2012-04-07 .
  35. ^ بن أندرسون (7 سبتمبر 2011). "بن أندرسون: لماذا يمكن أن يكون التخزين المؤقت لـ DNS في متصفح الويب أمرًا سيئًا" . تم الاسترجاع في 20 أكتوبر 2014 .
  36. ^ "كيف يستخدم Internet Explorer ذاكرة التخزين المؤقت لإدخالات مضيف DNS". Microsoft Corporation . 2004. تم الاسترجاع في 2010-07-25 .
  37. ^ "معلمات نظام اسم النطاق (DNS)". IANA . DNS RCODEs . تم الاسترجاع في 14 يونيو 2019 .
  38. ^ جيمس ف. كوروز وكيث دبليو روس، الشبكات الحاسوبية: نهج من أعلى إلى أسفل، الطبعة السادسة، إسيكس، إنجلترا: بيرسون للتعليم المحدودة، 2012
  39. ^ RFC 5395، اعتبارات نظام اسم النطاق (DNS) IANA ، D. Eastlake 3rd (نوفمبر 2008)، القسم 3
  40. ^ RFC 5395، اعتبارات نظام اسم النطاق (DNS) IANA ، D. Eastlake 3rd (نوفمبر 2008)، ص. 11
  41. ^ ab RFC  4592، دور الأحرف البدل في نظام اسم النطاق ، إي لويس (يوليو 2006)
  42. ^ S. Thomson; Y. Rekhter; J. Bound (أبريل 1997). P. Vixie (محرر). التحديثات الديناميكية في نظام أسماء النطاقات (DNS UPDATE). Network Working Group. doi : 10.17487/RFC2136 . RFC 2136. المعيار المقترح. تحديثات RFC 1035. تم تحديثه بواسطة RFC 3007 و4033 و4034 و4035.
  43. ^ RFC  2671، آليات التمديد لنظام أسماء النطاقات (EDNS0) ، P. Vixie (أغسطس 1999)
  44. ^ Csikor, Levente; Divakaran, Dinil Mon (فبراير 2021). "خصوصية DNS عبر HTTPS: رثاء حلم؟" (PDF) . جامعة سنغافورة الوطنية. نحن نحقق فيما إذا كان من الممكن تمييز حركة مرور DoH عن حركة مرور الويب المشفرة. ولتحقيق هذه الغاية، نقوم بتدريب نموذج التعلم الآلي لتصنيف حركة مرور HTTPS على أنها ويب أو DoH. مع وجود نموذج تعريف DoH الخاص بنا، نظهر أن مزود خدمة الإنترنت الاستبدادي يمكنه تحديد ≈97.4٪ من حزم DoH بشكل صحيح بينما يصنف خطأً 1 فقط من كل 10000 حزمة ويب.
  45. ^ Huitema, Christian; Dickinson, Sara; Mankin, Allison (مايو 2022). DNS عبر اتصالات QUIC المخصصة. فريق عمل هندسة الإنترنت. doi : 10.17487/RFC9250 . RFC 9250.
  46. ^ شميت، بول؛ إدموندسون، آن؛ فيمستر، نيك (2019). "نظام أسماء النطاقات الخفي: الخصوصية العملية لاستعلامات نظام أسماء النطاقات" (PDF) . تقنيات تعزيز الخصوصية . 2019 (2): 228– 244. arXiv : 1806.00276 . doi :10.2478/popets-2019-0028. S2CID  44126163. مؤرشف من الأصل (PDF) في 2022-01-21.
  47. ^ "نظام DNS غير واضح تم نشره بواسطة Cloudflare وApple". 9 ديسمبر 2020. تم الاسترجاع في 27 يوليو 2022 .
  48. ^ باولي، تومي (2 سبتمبر 2021). "DNS غير المبالي عبر HTTPS". IETF.
  49. ^ Muffett, Alec (فبراير 2021). ""No Port 53, Who Dis؟" A Year of DNS over HTTPS over Tor" (PDF) . ندوة أمن الشبكات والأنظمة الموزعة. مؤرشف (PDF) من الأصل في 2021-03-21. DNS over HTTPS (DoH) يزيل العديد من المخاطر ولكن ليس كلها، ويثير بروتوكول النقل الخاص به (أي HTTPS) مخاوف بشأن الخصوصية بسبب (مثل) "ملفات تعريف الارتباط". توجد شبكة Tor لتزويد دوائر TCP ببعض الحرية من التتبع والمراقبة والحظر. وبالتالي: بالاقتران مع Tor وDoH ومبدأ "لا تفعل ذلك، ثم" (DDTT) للتخفيف من بصمة الطلب، أصف DNS عبر HTTPS عبر Tor (DoHoT).
  50. ^ Ulevitch, David (6 December 2011). "DNSCrypt – Critical, fundamental, and about time". Cisco Umbrella . مؤرشف من الأصل في 1 يوليو 2020.
  51. ^ "مواصفات DNSCrypt المجهولة". GitHub . DNSCrypt. مؤرشف من الأصل في 25 أكتوبر 2019.
  52. ^ "Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki". GitHub . مشروع DNSCrypt . تم الاسترجاع في 28 يوليو 2022 .
  53. ^ هيرزبيرج، أمير؛ شولمان، هيا (2014-01-01). "إعادة تركيب الأمان في بروتوكولات الشبكة: حالة DNSSEC". IEEE Internet Computing . 18 (1): 66– 71. doi :10.1109/MIC.2014.14. ISSN  1089-7801. S2CID  12230888.
  54. ^ APWG. "Global Phishing Survey: Domain Name Use and Trends in 1H2010." 15/10/2010 apwg.org أرشيف 2012-10-03 على موقع Wayback Machine
  55. ^ "DNSMessenger (عائلة البرامج الضارة)". malpedia.caad.fkie.fraunhofer.de . تم الاسترجاع في 2024-12-11 .
  56. ^ Khandelwal, Swati (2017-03-06). "برنامج ضار جديد بدون ملفات يستخدم استعلامات DNS لتلقي أوامر PowerShell". The Hacker News . تم الاسترجاع في 2024-12-11 .
  57. ^ Brumaghin, Edmund (2017-03-02). "Covert Channels and Poor Decisions: The Tale of DNSMessenger". مدونة Cisco Talos . تم الاسترجاع في 2024-12-11 .
  58. ^ Bombal, David (2023-05-26). إنه DNS مرة أخرى 😢 هل تعلم هذا الاختراق الخبيث؟ . تم الاسترجاع في 2024-12-11 – عبر YouTube.
  59. ^ ab Huston, Geoff (يوليو 2019). "خصوصية DNS وIETF" (PDF) . مجلة بروتوكول الإنترنت . مؤرشف من الأصل (PDF) في 30 سبتمبر 2019.
  60. ^ "ملف تعريف تشغيلي لبروتوكول الوصول إلى بيانات التسجيل (RDAP) لسجلات gTLD ومسجلي النطاقات العامة ذات المستوى الأعلى". ICANN . 3 ديسمبر 2015. مؤرشف من الأصل في 22 ديسمبر 2015. تم الاسترجاع في 18 ديسمبر 2015 .
  61. ^ "البحث عن مسجل". VeriSign, Inc. تم الاسترجاع في 18 ديسمبر 2015 .

مصادر

  • إيفانز، كلير إل. (2018). النطاق العريض: القصة غير المروية عن النساء اللاتي صنعن الإنترنت. نيويورك: بورتفوليو/بنغوين. رقم ISBN 9780735211759.

قراءة إضافية

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

  • RFC 1034، أسماء النطاقات - المفاهيم والمرافق
  • RFC 1035، أسماء النطاقات - التنفيذ والمواصفات
  • RFC 1123، متطلبات مضيفات الإنترنت - التطبيق والدعم
  • RFC 1995، نقل المنطقة التدريجي في DNS
  • RFC 1996، آلية الإخطار الفوري بتغييرات المنطقة (DNS NOTIFY)
  • RFC 2136، التحديثات الديناميكية في نظام اسم المجال (تحديث DNS)
  • RFC 2181، توضيحات حول مواصفات DNS
  • RFC 2308، التخزين المؤقت السلبي لاستعلامات DNS (DNS NCACHE)
  • RFC 3225، يشير إلى دعم المُحلل لـ DNSSEC
  • متطلبات حجم الرسالة الخاصة بالخادم/المحلل وفقًا لـ RFC 3226 و DNSSEC وIPv6 A6
  • RFC 3596، ملحقات DNS لدعم إصدار IP 6
  • RFC 3597، التعامل مع أنواع سجلات موارد DNS (RR) غير المعروفة
  • RFC 4343، توضيح عدم حساسية نظام اسم النطاق (DNS) لحالة الأحرف
  • RFC 4592، دور الأحرف البدل في نظام اسم النطاق
  • RFC 4635، معرفات خوارزمية HMAC SHA TSIG
  • RFC 5001، خيار معرف خادم اسم DNS (NSID)
  • RFC 5011، التحديثات التلقائية لمرسيات الثقة الخاصة بأمان DNS (DNSSEC)
  • RFC 5452، تدابير لجعل DNS أكثر مرونة ضد الإجابات المزورة
  • RFC 5890، أسماء النطاقات الدولية للتطبيقات (IDNA): التعاريف وإطار العمل المستندي
  • RFC 5891، أسماء النطاقات الدولية في التطبيقات (IDNA): البروتوكول
  • RFC 5892، نقاط ترميز Unicode وأسماء النطاقات الدولية للتطبيقات (IDNA)
  • RFC 5893، نصوص من اليمين إلى اليسار لأسماء النطاقات الدولية للتطبيقات (IDNA)
  • RFC 6672، إعادة توجيه اسم DNS غير الطرفي
  • RFC 6891، آليات التمديد لنظام DNS (EDNS0)
  • RFC 7766، نقل DNS عبر TCP - متطلبات التنفيذ
  • RFC 8945، مصادقة معاملات المفتاح السري لـ DNS (TSIG)

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

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

RFCs التجريبية

  • RFC 1183، تعريفات DNS RR الجديدة

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

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

RFCs المعلوماتية

تعتبر هذه RFCs استشارية بطبيعتها، ولكنها قد توفر معلومات مفيدة على الرغم من عدم تحديد معيار أو خطة استمرارية العمل. (RFC 1796)

  • RFC 1178، اختيار اسم لجهاز الكمبيوتر الخاص بك (FYI 5)
  • RFC 1591، هيكل نظام اسم النطاق والتفويض
  • RFC 1912، أخطاء تشغيل وتكوين DNS الشائعة
  • RFC 2100، تسمية المضيفين
  • RFC 3696، تقنيات التطبيق للتحقق من الأسماء وتحويلها
  • RFC 3833. تحليل التهديدات لنظام اسم النطاق (DNS)
  • RFC 4892، متطلبات آلية تحديد مثيل خادم الأسماء
  • RFC 5894، أسماء النطاقات الدولية للتطبيقات (IDNA): الخلفية والتفسير والأساس المنطقي
  • RFC 5895، تعيين الأحرف لأسماء النطاقات الدولية في التطبيقات (IDNA) 2008
  • RFC 8806، تشغيل خادم جذر محلي على مُحلل
  • RFC 9076، اعتبارات خصوصية DNS
  • RFC 9156، تقليل اسم استعلام DNS لتحسين الخصوصية
  • RFC 9499، مصطلحات DNS

مجهول

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

  • RFC 920، متطلبات النطاق – نطاقات المستوى الأعلى الأصلية المحددة
  • RFC 1032، دليل مسؤولي المجال
  • RFC 1033، دليل عمليات مسؤولي المجال
  • RFC 1101، ترميزات DNS لأسماء الشبكات وأنواع أخرى
تحتوي ويكي الجامعة على مصادر تعليمية حول نظام اسم النطاق
  • فيكسي، بول (4 مايو 2007). "تعقيد DNS". قائمة انتظار ACM . مؤرشف من الأصل في 29 مارس 2023.
  • بول، جيمس (28 فبراير 2014). "تعرف على الأشخاص السبعة الذين يحملون مفاتيح أمن الإنترنت في جميع أنحاء العالم". الجارديان . الجارديان نيوز آند ميديا ​​ليميتد . تم الاسترجاع في 28 فبراير 2014 .
  • كروجر، لينارد ج. (18 نوفمبر 2016). "حوكمة الإنترنت ونظام أسماء النطاقات: قضايا مطروحة على الكونجرس" (ملف PDF) . خدمة أبحاث الكونجرس . تم الاسترجاع في 27 يوليو 2024 .
  • Zytrax.com، دليل المصدر المفتوح – DNS لعلماء الصواريخ.
  • العبث مع DNS – موقع حيث يمكنك إجراء تجارب مع DNS.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Domain_Name_System&oldid=1266913637"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate