اللجنة الاستشارية لنظام خادم الجذر (RSSAC)
بالإضافة إلى لغات ICANN، فإن هذا المحتوى متوفر أيضاً باللغة
الأسئلة الشائعة والأجوبة الخاصة بلجنة RSSAC
تحتوي هذه الصفحة على أسئلة وأجوبة للعديد من الأسئلة الأكثر شيوعًا لدى RSSAC. وسيتم تحديثها كلما تغيرت الإجابات، أو عندما تصبح هناك أسئلة متكررة جديدة.
إذا كانت لديك أي أسئلة غير مدرجة في أدناه، أو لمزيد من المعلومات أو التوضيح، يمكنك التواصل مباشرة عبر البريد الإلكتروني [email protected]. وإذا كنت ترغب بالاشارة إلى سؤال في هذه الأسئلة والأجوبة، فيرجى تضمين رقم السؤال وعنوانه في بريدك الإلكتروني. يحتفظ مشغلو خادم الجذر أيضًا بنسخة من الأسئلة الشائعة والأجوبة.
قائمة الموضوعات
1 عدد خوادم الجذر
1.1 لماذا يوجد 13 خادم لإسم الجذر؟
في عام 1985، كان هناك أربعة خوادم للجذر. ومن 1987-1991 كان هناك سبعة، وجميعها كانت موجودة في الولايات المتحدة الأمريكية. وبحلول عام 1993 كان هناك ثمانية. وفي هذه المرحلة، تمت مواجهة مشكلة. ينص RFC 1035 على أن "رسائل [DNS] التي يحملها بروتوكول مخطط بيانات مستخدم الإنترنت UDP مقيدة بـ 512 بايت". وستؤدي إضافة المزيد من خوادم أسماء الجذر إلى استجابة أولية يمكن أن تتجاوز 512 بايت. لا يقدم تقرير RFC 1035 أساسًا منطقيًا للحد البالغ 512 بايت، ولكن تجدر الإشارة أيضًا إلى أنه في ذلك الوقت، كان هناك شرطًا مألوفاً يحدد مقدار حزم بيانات IP على الإنترنت إلى 576 بايت.
أدرك مشغلو خادم الجذر (RO) أنه يمكنهم إضافة المزيد من خوادم الأسماء إن تمكنوا من الاستفادة من تقليص واختصار اسم DNS. لذلك، تم تقديم الاقتراح لإعطاء أسماء خوادم الجذر في منطقة root-servers.net. وبحلول عام 1995، تمت إعادة تسمية خوادم الجذر التسعة الحالية إلى "a.root-servers.net" و"b.root-servers.net" وما إلى ذلك. وفي عام 1997، تمت إضافة أربعة أخرى، مما رفع إجمالي عدد معرفات خادم الجذر (RSI) إلى 13.
وحتى عام 1998، كان جون بوستل، بصفته مدير IANA، هو المسؤول عن تعيين مشغلي خادم الجذر. وبعد وفاته في عام 1998، لم يتغير عدد المشغلين، على الرغم من أنه كان هناك عددًا صغيرًا من حالات تسليم مهام المشغل لجهات أخرى على مر السنين.
ومنذ عام 1998، تغير المشهد بعدة طرق. حيث أضاف كل خادم جذر عنوان بروتوكول الإنترنت - الإصدار السادس (IPv6) الخاص به، ووقعت ICANN المنطقة مع الامتدادات الأمنية لنظام اسم النطاق (DNSSEC). أيضًا، تم توسيع حجم الرسائل التي تم نقلها عبر بروتوكول مخطط بيانات مستخدم الإنترنت (UDP) باستخدام آلية توسيع نظام اسم النطاق DNS (أي EDNS). وقدمت هذه التغييرات مجتمعة حدًا لبروتوكول مخطط بيانات مستخدم الإنترنت UDP بقيمة 512 بايت و13 لمعرفات خادم الجذر (RSI).
وفي عام 2002، أصبح اتحاد برامجيات الإنترنت (ISC، الآن يُطلق عليه اتحاد أنظمة الإنترنت) أول مشغل خادم جذر (RSO) ينشر IP متعدد الاتجاهات، على الرغم من أن مشروع المنظومة الموزعة المتكاملة على نطاق واسع WIDE قد تم تجريبه مع التكنولوجيا في وقت سابق. وعلى مدار السنين، اتبع مشغلو خادم الجذر الآخرين ذات المنحى. حيث يسمح التوجيه متعدد الاتجاهات لكل مشغل بتقديم الخدمة من معدات منفردة متعددة. وبينما لا يزال هناك اليوم 13 معرف لخادم الجذر (RSI)، إلا أنه هناك في الواقع أكثر من 1500 نموذج من معدات متعددة الاتجاهات تعمل في جميع أنحاء العالم.
ولفهم أفضل لتاريخ نظام خادم الجذر (RSS)، يرجى قراءة RSSAC023v2: تاريخ نظام خادم الجذر. وإن كنت مهتمًا بالتطور المستمر لنظام خادم الجذر (RSS)، فيُرجى قراءة RSSAC037: نموذج حوكمة مقترح لنظام خادم الجذر لنظام DNS.
1.2 ما الحسابات التي أخذت بنظر الاعتبار لتحديد عدد 13 معرف من معرفات خادم الجذر؟
في عام 1997، كانت خوادم الجذر تعمل أيضًا كخوادم رسمية موثوقة لمناطق نطاقات COM. و NET. و ORG.، وقد وضعت هذه الوظيفة المضافة قيودًا مهمة على عدد معرفات خادم الجذر RSI التي يمكن أن تكون متواجدة. وتمامًا كما هو الحال مع الاستعلام التمهيدي لمنطقة الجذر، لا يمكن أن يتجاوز الاستعلام عن مجموعة سجلات الموارد لخادم الاسم NS RRset لمناطق نطاقات COM. و NET. و ORG. حد الـ 512 بايت، وبما أن نفس الخوادم كانت تخدم هذه المناطق، فقد تم تطبيق نفس القيود على جميعها.
تحتوي حزمة استجابة DNS أيضًا على السؤال الكامل الذي تم طرحه في قسم الأسئلة. ستستخدم الاستجابة للاستعلام التمهيدي للجذر دائمًا 5 بايتات لقسم الأسئلة. يأخذ QNAME بايت واحد، ويأخذ كل من QTYPE وQCLASS ما مقدارة 2 بايت ليصبح المجموع 5. ومع ذلك، بالنسبة للاستعلام التمهيدي لنطاق COM.، يمكن أن يكون قسم الأسئلة أكبر بكثير.
| الغرض |
جدول رقم 1: شرح البايتات المستخدمة في الاستجابة التمهيدية للجذر
باستخدام 435 بايت، يتبقى لنا 77 بايت متاحة لقسم أسئلة QName. في ذلك الوقت تم تحديد أن 64 بايت ستكون كافية لاستيعاب معظم الاستعلامات المرسلة لنطاقات COM. و NET. و ORG.. وتتطلب إضافة خادم آخر 25 بايت، وبما أن 435 + 64 + 25> 512، فقد تقرر عدم إضافة خادم آخر.
2 التوجيه متعدد الاتجاهات Anycast
2.1 لماذا يوجد لدى بعض المشغلين العديد من معدات التوجيه متعدد الاتجاهات في حين لا يوجد لدى المشغلين الآخرين إلا القليل؟
إن مشغلي خادم الجذر (RSO) عبارة عن منظمات مستقلة ذات تفويضات مختلفة، ونماذج تشغيلية مختلفة، ومصادر تمويل مختلفة. ويمكن أن تؤثر هذه الاختلافات على عدد معدات التوجيه متعدد الاتجاهات لدى كل منهم، بالإضافة إلى الخيارات التشغيلية الأخرى. ويتمتع مشغلو خادم الجذر بدرجة عالية من الاستقلالية في كيفية نشر شبكتهم؛ راجع RSSAC042: بيان اللجنة الاستشارية لنظام خادم الجذر RSSAC حول استقلالية مشغل خادم الجذر. ويلتزم جميع مشغلي خادم الجذر RO بتقديم خدمة جذر نظام DNS عالية الجودة.
2.2 هل أن عدد عقد التوجيه متعدد الاتجاهات غير محدود أو محدد بعدد معين؟
يتم تعريف عملية التوجيه متعدد الاتجاهات ووصفها في RFC 4786 "تشغيل خدمات التوجيه متعدد الاتجاهات" و RFC 7094 "الاعتبارات التصميمية لتعدد اتجاهات IP". لا يوجد حد متعلق بعدد العقد في خدمة التوجيه متعدد الاتجاهات.
2.3 تعمل خوادم الجذر على تكرار منطقة الجذر الرسمية وتعيد نشرها، ثم تقوم معدات التوجيه متعدد الاتجاهات بإعادة نشر البيانات منها. ما الفرق بين هذين النوعين من إعادة النشر؟
يتلقى مشغلو خوادم الجذر RSO بيانات المنطقة الرسمية الموثوقة من مشرف الصيانة على منطقة الجذر (RZM). ثم يستخدم كل مشغل من مشغلي خادم جذر نظام توزيع داخلي خاص به لتسليم المنطقة إلى جميع مواقعها ومعدات الأجهزة متعددة الاتجاهات الخاصة بها.
2.4 نحن نستضيف معدات التوجيه متعدد الإتجاهات لخادم الجذر في مدينة محلية. ونرى أنها تجيب على الاستعلامات من جميع أنحاء العالم. كيف يمكنني أن أجيب فقط على الاستعلامات من المنطقة المحلية؟
تعتبر هذه بالفعل مسألة تتعلق بتوجيه بروتوكول الإنترنت IP وكيف يدير مشغل خادم الجذر خدمة تعدد الاتجاهات الخاصة به. ويعمل بعض مشغلي خوادم الجذر على تكوين أجهزة التوجيه الخاصة بهم وجلسات الأقران بحيث تتلقى معدات التوجيه متعدد الإتجاهات البيانات المحلية المنتقلة فقط. ويقوم البعض الآخر بتكوينها لاستقبال البيانات المتنقلة عبر العالم، معتمدين على نظام التوجيه لاختيار أفضل مسار للبيانات عبر الشبكة. فإذا لاحظت سلوكًا غير مرغوب به لدى خادم مستضاف، يجب عليك مناقشة هذه المشكلة مع مشغل خادم الجذر الذي يقوم بتوفير الخدمة.
2.5 في عام 2016، كان هناك هجوم كبير على شركة Dyn. هل يمكن أن يحدث الشيء نفسه لجميع معدات التوجيه متعدد الاتجاهات لخادم الجذر؟
نعم، على الأقل نظريًا. هذا هو أحد الأسباب التي تجعل نظام خادم الجذر RSS يحتوي على العديد من معدات أو مثيلات خادم الجذر. يزيد العدد الكبير من معدات التوجيه متعدد الاتجاهات من قدرة نظام خادم الجذر ويساعد بالتأكيد في حالات التعرض لهجوم. وعلى الرغم من تعرض نظام خادم الجذر لهجوم عالمي سابقًا، إلا أنه لم ينجح أي هجوم على الإطلاق في تعطيل النظام بأكمله.
2.6 كيف يمكنني طلب معدات التوجيه متعدد الاتجاهات لخادم الجذر لمؤسستي؟
يرجى التواصل مباشرة مع مشغلي خادم الجذر باستخدام معلومات الاتصال أدناه. على غرار السؤال 3.4، يمكنك أيضًا وبدلاً من ذلك تشغيل نسخة محلية من منطقة الجذر، كما هو موضح في RFC 8806، دون أن تكون رسميًا جزءًا من نظام التوجيه متعدد الاتجاهات لخادم الجذر.
لدى سجل عناوين الإنترنت لأمريكا اللاتينية ومنطقة الكاريبي (LACNIC) أيضًا مشروعًا يُسمى Raices+ للحث على تنصيب معدات التوجيه متعدد الاتجاهات لخادم الجذر في الدول الواقعة ضمن منطقة LACNIC. يمكن إيجاد المزيد من المعلومات هنا.
| مشغل خادم الجذر |
جدول رقم 2: معلومات جهة الاتصال لطلب معدات التوجيه متعدد الإتجاهات
2.7 كيف يمكنني تحديد معدات مُعرّف خادم الجذر التي تستجيب لاستعلاماتي؟
يمكنك استخدام أداة البحث من نظام كمبيوتر يعمل بنظام Unix أو Mac لإرسال استعلامات خاصة إلى مُعرّف خادم الجذر. وستحدد الاستجابة أي موقع من معدات التوجيه متعدد الاتجاهات قد تلقى الاستعلام.
يمكنك استخدام خيار الاستعلام بمعرف فضاء الاسم NSID ثم البحث عن سلسلة NSID المبلغ عنها في مخطط OPT Pseudosection من مخرجات البحث:
$ dig +nsid @a.root-servers.net
…
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
; NSID: 6e 33 2e 75 73 2d 77 61 73 2e 72 6f 6f 74 ("n3.us-was.root")
…
لكل مُعرف خادم جذر حرية اختيار مخطط تسمية موقع التوجيه متعدد الاتجاهات الخاص بها، لكن يتم تسمية المواقع عمومًا باستخدام رموز IATA للمطارات أو قانون الأمم المتحدة لمواقع التجارة والنقل. وأن بعض معرفات خادم الجذر تنشر اتفاقات تسمية الموقع الخاصة بها في قسم "المعرفات" من ملفات YAML ذات الصلة والمتوفرة على https://root-servers.org/.
3. نظام اسم النطاق DNS والشبكات
3.1 كيف تختار الخوادم التكرارية أي خادم جذر للاستعلام، وما مُعرف خادم الجذر الذي يجب أن يفضّله الخادم التكراري الخاص بي؟
هذا يسمى "خوارزمية اختيار الخادم". لا يحدد بروتوكول DNS الكيفية التي يجب أن يختار بها خادم الاسم التكراري من بين مجموعة ما لاستعلام معين. وبالتالي، يحدد كل بائع خوارزمية برمجية تكرارية خاصة به. بعض تطبيقات المُحلِّلات تُقفل على الخادم ذي زمن الوصول الأقل، أو على أحد الخوادم ذي زمن الوصول المُشابه للأسرع. وتختار بعض تطبيقات وحدة الحل الخادم بشكل عشوائي في كل مرة، ويوزع البعض الآخر الاستعلامات بناءً على معادلات معقدة.
وربما يكون أكثر موثوقية السماح لبرنامجك التكراري بأداء وظيفته على النحو المصمم، بدلاً من محاولة التأثير عليه لتفضيل أو تجنب خوادم معينة.
3.2 هل يمكنك توضيح كيف يستخدم نظام DNS بروتوكول UDP و TCP port 53؟
يستخدم جميع عملاء DNS تقريبًا بروتوكول UDP بشكل تلقائي للاستعلامات. ومع ذلك، هناك بعض الحالات التي تحتاج إلى استخدام بروتوكول التحكم في الإرسال TCP بدلاً من ذلك.
يحدث الاستخدام الأكثر شيوعًا لبروتوكول TCP عندما يتم قطع استجابة بروتوكول UDP. ويحدث مثل هذا الاقتطاع عندما تكون استجابة الخادم كبيرة جدًا بحيث لا تتناسب مع رسالة بروتوكول UDP. ويعتمد ذلك على حجم ذاكرة التخزين المؤقت المُعلن عنها لبروتوكول UDP الخاصة بالعميل، وأي حدود لحجم الاستجابة التي قد يفرضها الخادم على نفسه. وعندما يتلقى العميل استجابة مع مجموعة البتات المقتطعة، يعطي بروتوكول DNS إيعازاً أنه يجب إعادة محاولة الاستعلام عبر بروتوكول التحكم في الإرسال TCP للحصول على الاستجابة الكاملة.
استخدام آخر لبروتوكول TCP لنظام DNS يتمثل في عمليات نقل المنطقة. نظرًا لأن المناطق بأكملها تكون بشكل عام أكبر بكثير مما قد تتناسب مع رسالة واحدة لبروتوكول UDP، فمن المنطقي أداء ذلك عبر بروتوكول TCP.
يمكن أن يبدأ تشغيل بروتوكول TCP أيضًا عندما يجد الخادم نفسه معرضًا لهجوم. وقد يرسل الخادم للعملاء استجابات مقتطعة كطريقة لتحديد ما إذا كانت المصادر مزيفة أم لا. ويمكن إدراج العملاء الذين ينشئون اتصالات بروتوكول TCP في القائمة البيضاء كمصادر موثوقة غير مخادعة. بالإضافة إلى ذلك، فإن التقنية المعروفة باسم تحديد معدل الاستجابة (RRL) سترسل أحيانًا استجابات مقتطعة بحيث تتاح للعملاء الشرعيين فرصة لتلقي الاستجابات عبر بروتوكول TCP، في حين أن حركة بيانات الهجمة لن تقوم بإعادة المحاولة.
يعتبر بروتوكول TCP عبر DNS إلزاميًا لتنفيذ برنامج DNS. لمزيد من المعلومات، يُرجى الرجوع إلى RFC 7766.
3.3 كيف يمكنني تقليل وقت الاستجابة بين الخادم التكراري الذي أقوم بتشغيله وخادم الجذر؟
أولاً، يجب عليك التفكير بعناية فيما إذا كانت هناك أي فائدة حقيقية لتكون أقرب إلى (المزيد من) خوادم الجذر. يستخدم نظام DNS تقنيات التخزين المؤقت بكثرة. ولذلك، تقل الفائدة المترتبة على تقليل وقت الاستجابة بين الخادم التكراري ومعدات خادم الجذر. وكما ذكرنا في الإجابة على السؤال 3.1، فإن خوارزميات برنامج وحدات الحل ستحاول بشكل عام الاستعلام عن خوادم الجذر ذات وقت الاستجابة الأقل. وبالتالي، لن يؤدي زيادة وقت الاستجابة لبعض خوادم الجذر بالضرورة إلى أن تكون الاستعلامات إلى نظام خادم الجذر ذات وقت استجابة أعلى.
قم بتحليل حركة مرور البيانات مع ترك خادم الاسم التكراري الخاص بك للاستعلامات التي يتم إرسالها إلى خوادم اسم الجذر. إذا رأيت حركة مرور أكثر من المتوقعة، فقد تتمكن من إصلاح تطبيقاتك أو تكوينات شبكتك بحيث لا تحتاج إلى الاستعلام عن الجذر كثيرًا. استخدم برامج مثل الأداة "dig" لقياس وقت الاستجابة الفعلي. إذا كان هناك خادمان جذريان على الأقل في غضون 100 مللي ثانية، فيجب أن يكون ذلك كافياً بشكل عام.
استخدم أدوات مثل أداة تتبع المسار "traceroute" لاستكشاف مسار الشبكة بين خادمك التكراري وخوادم الجذر التي يستخدمها خادم الاسم التكراري الخاص بك. إذا وجدت شيئًا غير منطقي (مثل التوجيه عبر مواقع بعيدة)، فاسأل مزود خدمة الإنترنت عما إذا كان يمكن تعديل التوجيه أم لا.
لمزيد من المعلومات حول جودة DNS لقياسات الخدمة، يقوم مشروع خرائط Réseaux IP Européens (RIPE) بمراقبة جودة خدمة الجذر مع مشروع DNSMON الخاص به. ويتم قياس وقت الاستجابة لمعظم الخوادم بمئات من مراسي الخرائط للشبكات الأوروبية لبروتوكول الإنترنت وبأقل من 60 مللي ثانية.
إذا لم تكن هناك خوادم جذر قريبة بشكل معقول، فيمكنك محاولة تحديد نقطة تبادل أو مركز بيانات قريب حيث يمكن إيجاد خادم جذر. اسأل واحدًا أو أكثر من مشغلي خادم الجذر ما إذا كانوا على استعداد لوضع خادم هناك. ومع ذلك، لاحظ أنه إذا كان الموقع يحتوي بالفعل على خادم جذر واحد، فلن يرغب المشغلون عادةً في وضع خادم آخر هناك. ويمكنك إيجاد معلومات جهة الاتصال للمشغل في الجدول رقم 2.
3.4 هل يمكنك إعداد خادم الجذر بنفسك عن طريق تنزيل ملف منطقة الجذر والتحقق من صحة التوقيع بنفسك؟
RFC 8806 يصف كيفية القيام بذلك، بالإضافة إلى إدراج العديد من التحذيرات حول الجوانب السلبية المحتملة للقيام بذلك. لاحظ أنه يتطلب التحقق باستخدام امتدادات DNSSEC. انظر أيضًا في مشروع LocalRoot.
3.5 كم مدة التخزين المؤقت للمعلومات من قِبل الخادم التكراري؟
يحتوي كل سجل من سجلات DNS على مدة معينة لبقاء البيانات فعالة (TTL) من قِبل ناشر المنطقة. وهذا يحدد المدة التي يجب أن يخزن فيها خادم الأسماء المتكررة أو أي عميل آخر البيانات مؤقتًا لإعادة استخدامها. بعد هذا الوقت، من المتوقع أن يتصل خادم الاسم التكراري بخادم موثوق مرة أخرى للحصول على بيانات جديدة.
وفي حالة منطقة الجذر، تتم خدمة بعض السجلات لمدة TTL تبلغ 24 ساعة والبعض الآخر لمدة تبلغ 48 ساعة. ولدى بعض المحللين (وحدات الحل) أقصى مدة للتخزين المؤقت عادةً وتبلغ 24 ساعة.
3.6 لأن التخزين المؤقت سيعطي معلومات خاطئة بمرور الوقت، كيف يمكن تحديث وحدة حل بمعلومات DNS الصحيحة؟
إن كنت تشك في أن البيانات الموجودة في ذاكرة التخزين المؤقت لخادم اسم تكراري قديمة وغير صالحة، فيمكنك مسح ذاكرة التخزين المؤقت أو إعادة تشغيل عملية الخادم.
3.7 ما هي الاستعلامات والاستجابات التمهيدية لنظام DNS؟
تحتاج وحدات حل DNS التكرارية إلى تجهيز ذاكراتهم المؤقتة ببيانات محددة من منطقة الجذر قبل أن تتمكن من البدء بالرد على الاستعلامات العادية. تصف RFC 8109 الاستعلامات التي ترسلها وحدات الحل التكرارية والاستجابات التي يتوقعونها من خوادم الجذر.
3.8 ما الدور الذي تلعبه آليات توسيع نظام اسم النطاق EDNS في استعلامات نظام DNS الحديثة وكيف تؤثر على عمليات خوادم الجذر؟
تعزز EDNS أو آليات التوسيع لنظام اسم النطاق والمبينة في وثيقة RFC 6891 ، قدرات بروتوكول نظام DNS مع الحفاظ على التوافق مع الإصدارات السابقة. ويُعدّ هذا الأمر بالغ الأهمية لاستعلامات DNS الحديثة، إذ يُتيح حصول استجابات أوسع، مثل تلك التي تحتوي على بيانات DNSSEC أو المزيد من السجلات.
3.9 ما تأثير سوء التكوين في خادم جذر واحد على منظومة نظام DNS الكلية؟
قد يكون لسوء التكوين في خادم جذر واحد تأثير محلي أو مؤقت. ومع ذلك، صُمّمت خدمة RSS لضمان بقاء منظومة نظام DNS الكلية مرنة وموثوقة، حتى في حالة سوء التكونين والإعداد أو تعطل أحد مكوناته.
4 سلامة منطقة الجذر
4.1 كيف يضمن المشغلون من أن منطقة الجذر يمكن أن تتكرر بشكل صحيح؟
يتم نقل ملف منطقة الجذر من مشرف الصيانة على منطقة الجذر (RZM) إلى مشغلي خادم الجذر الفرديين (RSO) عبر بروتوكولات نقل منطقة DNS (AXFR في RFC 5936 وآلية النقل التدريجي IXFR في RFC 1995). يتم حماية رسائل نقل المنطقة هذه باستخدام سجلات موارد توقيع التحويل TSIG كما هو موضح في RFC 2845. وتعتبر هذه بروتوكولات موثوقة ولا توجد حوادث معروفة حول تلف البيانات. علاوةً على ذلك، نظرًا لتوقيع منطقة الجذر، يمكن التحقق من الإجابات غير الصحيحة أو المزيفة بواسطة مدققي DNSSEC. تشجع اللجنة الاستشارية لنظام خادم الجذر على استخدام التحقق باستخدام امتدادات DNSSEC حيثما أمكن.
يستخدم مشرف الصيانة RZM على منطقة الجذر إشعار نظام اسم النطاق DNS NOTIFY المحدد في RFC 1996 للإشعار الفوري بالتغييرات على المنطقة لتنبيه مشغلي خادم الجذر بتوافر منطقة جديدة (أي، أحدث إصدار) للنسخ أو للنقل.
4.2 ما هو موجز رسائل المنطقة ZONEMD وكيف يحمي سلامة بيانات منطقة الجذر؟
نظرًا لأنه من المستحيل منع أي تلف في البيانات على طول أي مسار، فمن المهم أن تتحقق وحدات الحل من صحة جميع الاستجابات التي يتلقونها باستخدام امتدادات DNSSEC (راجع القسم 5). وقد تم نشر آليات أخرى بالإضافة إلى ذلك للتأكد من أن كل معدة خادم جذر تم نشرها تخدم البيانات بشكل صحيح وعلى نحو أفضل. ووفق ما ناقشناه سابقًا، فإن استخدام مشغلي خادم الجذر ومشرف الصيانة على منطقة الجذر لتوقيع التحويل TSIG يضمن عدم إتلاف بيانات السجل أثناء النقل.
RFC 8976 يحدد آلية لضمان سلامة ملف منطقة نظام اسم النطاق باستخدام سجل تلخيص رسائل المنطقة ZONEMD الذي "يوفر ملخصًا لرسائل التشفير عبر بيانات منطقة نظام اسم النطاق أثناء عدم النشاط”. تحتوي منطقة الجذر الحالية على سجل ZONEMD الذي يتضمن توقيعًا رقميًا لمنطقة الجذر.
ستُمكِّن ZONEMD مستلمي منطقة الجذر الكاملة من التحقق من محتويات المنطقة من أجل سلامة البيانات وأصالة المصدر. تُمكّن الامتدادات الأمنية لنظام اسم النطاق (DNSSEC) المستخدمين النهائيين لبيانات DNS الموقعة (والتي تتضمن منطقة الجذر) من التأكد من أن الإستجابات التي تلقوها صحيحة، بغض النظر عن المسار والخوادم التي ربما تعاملت مع البيانات أثناء انتقالها.
4.3 ما هو الوضع الحالي لتننفيذ تلخيص رسائل المنطقة ZONEMD في عمليات خادم الجذر؟
ZONEMD (تلخيص رسائل المنطقة) هي تقنية مصممة لتعزيز التحقق من سلامة بيانات منطقة DNS. على الرغم من أن مشغلي شبكات الجذر RSO غير مُلزمين حاليًا بفرض التحقق من صحة ZOMEMD، إلا أنهم يواصلون مراقبة تطويرها واعتمادها. وتشمل الجهود الحالية اختبار ZONEMD في سيناريوهات واقعية، وتحليل تأثيره على الأداء، ومعالجة التحديات التشغيلية.
5 DNSSEC
5.1 هل تجعل امتدادات DNSSEC استعلامات أو إستجابات DNS سرية؟
لا، فهي تضيف فقط طبقة أمان إلى البنية التحتية لنظام اسم النطاق من خلال المصادقة على مصدر بيانات النظام، فضلاً عن حماية سلامتها.
5.2 هل تجعل امتدادات DNSSEC من الصعب تقديم نسخة من منطقة الجذر محليًا؟
لا، إن تقديم نسخة محلية من منطقة الجذر يعني ببساطة تقديم نسخ محدثة من منطقة الجذر دون أي تغييرات. تأتي منطقة الجذر من مدير منطقة الجذر (RZM) مع جميع توقيعات DNSSEC المطلوبة.
6 RSSAC
6.1 هل مسموح لأي شخص حضور اجتماعات لجنة RSSAC؟
تعقد لجنة RSSAC اجتماعات دورية عبر الإنترنت وتلتقي في اجتماعات ICANN. يمكنك الاطلاع على محاضر الاجتماعات والمؤتمرات عبر وسائل الاتصال (حيثما توفرت) من هنا. ولمتابعة ومراقبة اجتماعات لجنة RSSAC عبر وسائل الاتصال أو جلسات عملها، يُرجى الاتصال على [email protected] للحصول على مزيد من المعلومات بخصوص المشاركة عن بعد.
يُسمح بحضور المراقبين معظم اجتماعات لجنة RSSAC المنعقدة خلال اجتماعات ICANN، ما لم يتم تحديد الاجتماع في جدول جلسات اجتماع ICANN على أنه مغلق. تعقد لجنة RSSAC أيضًا جلسات عامة في اجتماعات ICANN، حيث تتم دعوة أعضاء المجتمع لطرح أسئلتهم.
6.2 ما العلاقة بين لجنة RSSAC ولجنة SSAC؟
لجنة RSSAC واللجنة اللجنة الاستشارية لنظام خادم الجذر SSAC هما اللجنتان الاستشاريتان الفنيتان في مجتمع ICANN. غير أن نطاق عملهما يختلف. فلجنة RSSAC تهتم فقط بـ "تشغيل نظام خادم الجذر وإدارته وأمنه وسلامته" وتهتم لجنة SSAC بـ "المسائل المتعلقة بأمن وسلامة أنظمة تخصيص التسمية والعناوين للإنترنت".
ويوجد بعض التداخل فيما بين اختصاص كل منهما. ولإبقاء كل منهما على اطلاع بأعمال الآخر، تُعين لجنة SSAC مسؤول اتصال لدى لجنة RSSAC. بالإضافة إلى أنهما يعقدان اجتماعًا مشتركًا خلال اجتماعات ICANN العامة.
ويرد وصف لجنة SSAC في القسم 12.2(ب) من لوائح ICANN الداخلية. يمكن إيجاد المزيد من المعلومات هنا.
6.3 كيف ترتبط لجنة (RSSAC) ولجنة (RZERC)؟ هل أن لجنة RZERC عبارة عن مجموعة فرعية من لجنة RSSAC؟
تعتبر لجنة (RSSAC) ولجنة مراجعة تطوير منطقة الجذر (RZERC) لجنتين منفصلتين داخل ICANN، على الرغم من وجود مسؤولي اتصال بينهما، إلا أنه يمكن أن يعمل أفراد منهما في كلتا اللجنتين.
ينص ميثاق لجنة RSSAC على أنها:.
"..تقوم بتقديم المشورة إلى مجلس إدارة ICANN والمجتمع بشأن المسائل المتعلقة بتشغيل نظام خادم الجذر وإدارته وأمن البيانات والشبكات." لمزيد من المعلومات عن دور لجنة RSSAC، يُرجى قراءة، RSSAC033: بيان لجنة RSSAC حول التمييز بين لجنة RSSAC وعمليات الجذر.
وينص ميثاق لجنة RZERC على أنه:
"..من المتوقع أن تقوم بمراجعة التغييرات الهيكلية المقترحة لمحتوى منطقة جذر DNS، والأنظمة بما في ذلك مكونات الأجهزة والبرامجيات المستخدمة في تنفيذ التغييرات على منطقة جذر DNS، والآليات المستخدمة لتوزيع منطقة جذر DNS."
يساعد المخطط التالي على شرح أدوار كل مجموعة.
مخطط RSSAC و RZERC
6.4 هل هناك جدول زمني لنعرف عدد خوادم الجذر التي تريد لجنة RSSAC الحصول عليها؟ متى سيتم التقييم لتحديد عدد الحروف؟
ليس لدى لجنة RSSAC تصورات مسبقة حول عدد خوادم الجذر أو عدد مشغلي خوادم الجذر RSO التي يجب أن تكون موجودة. ويعتبر الحد الحالي لعدد المشغلين تقني وليس إداري.
6.5 أين يمكنني إيجاد إصدارات لجنة RSSAC؟
تتوفر إصدارات لجنة RSSAC على صفحة إصدارات RSSAC. من المهم للأشخاص الذين يتعرفون على نظام خادم الجذر أن يطلعوا على RSSAC023v2: تاريخ نظام خادم الجذر، و RSSAC026v2: معجم مصطلحات RSSAC.
6.6 ما هو دور لجنة RSSAC في عملية وضع سياسات ICANN الشاملة؟
تعمل RSSAC كهيئة استشارية داخل ICANN، مع التركيز بشكل خاص على القضايا المتعلقة بالاستقرار التشغيلي والموثوقية وأمن نظام خادم الجذر. ومع أن RSSAC لا تضع سياسات ICANN بشكل مباشر، إلا أنها تقدم الخبرة الفنية والتوصيات اللازمة لإثراء مناقشات ,وضع السياسات. على سبيل المثال، تقدم RSSAC المشورة بشأن تطبيق التقنيات الجديدة وتأثيرها المحتمل على نظام خادم الجذر. وتساعد هذه الاسهامات على ضمان توافق سياسات ICANN مع أفضل الممارسات المتعلقة بعمليات نظام اسم النطاق (DNS) وأمنه.
6.7 كيف يمكن للأفراد أو المؤسسات تقديم ملاحظاتهم أو التفاعل مع RSSAC؟
تحث RSSAC على تقديم الملاحظات والتفاعل من مجتمع ICANN الواسع النطاق. ويمكن للأفراد والمؤسسات المشاركة في الاجتماعات العامة، وتقديم تعليقاتهم على مسودات الاصدارات خلال فترات التشاور العام، أو الانضمام إلى تجمع RSSAC كخبراء متخصصين. وتتوفر تحديثات وإحاطات دورية حول أنشطة RSSAC على موقع ICANN الإلكتروني، ويمكن لأعضاء المجتمع التواصل مع لجنة RSSAC مباشرةً من خلال فريق دعم ICANN. وتضمن عملية المشاركة المفتوحة هذه أن يظل عمل RSSAC شاملاً ومستجيباً لاحتياجات أصحاب المصلحة.
7 تجمّع RSSAC
يمكن إيجاد معلومات حول تجمع RSSAC على صفحة الويب الرئيسية الخاصة بالتجمع.
7.1 ما الفرق بين عضو لجنة RSSAC وعضو تجمع RSSAC؟
تتألف لجنة RSSAC من ممثلين معينين وبدلاء من كل مشغل خادم جذر، بالإضافة إلى مسؤولي اتصال من ومع مجموعات أخرى مختلفة. ويتألف تجمع RSSAC من خبراء نظام اسم النطاق المهتمين بنظام خادم الجذر. ويقدم تجمع RSSAC معظم (ولكن ليس كل) المشورات التي تنشرها لجنة RSSAC بينما لجنة RSSAC هي اللجنة الاستشارية الرسمية التي تعطي الموافقة النهائية على الإصدارات لنقلها إلى مجلس إدارة ICANN ومجتمعها.
جميع أعضاء لجنة RSSAC هم أيضًا أعضاء في تجمع RSSAC. يمكن الاطلاع على قائمة بأعضاء لجنة RSSAC هنا. يمكن الاطلاع على قائمة بأعضاء تجمع RSSAC هنا. يمكنك ايجاد معلومات حول كيفية الانضمام إلى RSSAC Caucus على صفحة RSSAC Caucus.
7.2 هل مسموح لأي شخص حضور اجتماعات لجنة RSSAC؟
يعقد تجمع اللجنة الاستشارية لنظام خادم الجذر اجتماعات عامة خلال الاجتماع السنوي العام لمنظمة ICANN وفي كل اجتماع لفريق عمل هندسة الإنترنت IETF عندما يكون عدد الاعضاء الحاضرين زوجياً. ويُسمح بحضور المراقبين في هذه الاجتماعات العامة. اجتماعات فريق عمل تجمع RSSAC ليست مفتوحة للمراقبين.
وتتم دعوة جميع أعضاء تجمع اللجنة الاستشارية لنظام خادم الجذر للمشاركة في كافة الاجتماعات العامة للتجمع واجتماعات فريق عمل التجمع.
7.3 هل هناك حد لعدد أعضاء تجمع RSSAC؟
كلا.
7.4 ما هي متطلبات الوقت لأعضاء تجمع RSSAC؟
يُتوقع أن يشارك أعضاء تجمع اللجنة الاستشارية لنظام خادم الجذر RSSAC في مجموعات العمل والمشاركة في مراسلات القائمة البريدية للتجمع. وسيكون بمقدور بعض الأعضاء تكريس وقت أكثر من غيرهم، وبأن بعض فرق العمل ومراجعات المستندات تتطلب وقتًا أكثر من غيرها. ومع ذلك، ترغب اللجنة الاستشارية لنظام خادم الجذر بشكل عام في أن يخصص الأعضاء 4 ساعات على الأقل شهريًا لتنفيذ أنشطة التجمع.
7.5 كيف يُسهم تجمع RSSAC في إعداد إصدارات RSSAC وتوصياتها؟
يضم تجمع RSSAC مجموعة من الخبراء المتطوعين في مجالات اختصاصية، يُقدمون المشورة، ويُعدّون الوثائق، ويُقدّمون مُداخلات فنية إلى RSSAC. يتعاون أعضاء التجمع في إعداد الاصدارات، مثل الاستشارات والدلائل الفنية والتقارير والتقييمات التقنية. يجتمع التجمع بشكل دوري لمناقشة المشاريع الجارية وتقديم مُداخلات حول مواضيع مثل تقنية نظام أسماء النطاقات (DNS)، وعمليات خادم الجذر، والتهديدات الناشئة. يمكن لأعضاء المجتمع الراغبين والمهتمين بهذا الأمر التقديم للانضمام لهذا التجمع والمساهمة في هذا العمل البالغ الأهمية.
8 جوانب سوء الفهم الشائعة
للحصول على مقدمة حول كيفية عمل نظام DNS، يُرجى قراءة، شرح نظام أسماء نطاقات الإنترنت لغير الخبراء مقدم من قبل دانيال كارينبرغ.
8.1 هل تتحكم خوادم الجذر في أين يتجه مسار انتقال البيانات في شبكة الإنترنت؟
كلا، تحدد أجهزة التوجيه وبروتوكول البوابة الحدودية BGP المسار الذي تسلكه حزم البيانات عبر الشبكة في طريقها من المصدر إلى الوجهة. ويوفر نظام أسماء النطاقات خط سير من الأسماء الموجهة من قبل الانسان إلى عناوين IP، وهي عناوين IP التي تستخدمها أجهزة التوجيه في النهاية لتحديد المكان الذي يجب أن تنتقل إليه حزم البيانات.
8.2 هل تتم معالجة معظم استعلامات DNS من قبل خادم جذر؟
كلا، يتم التعامل مع معظمها بواسطة وحدات حل تكرارية دون أي تفاعل مع خادم جذر من البيانات الموجودة بالفعل في ذاكرة التخزين المؤقت الخاصة بهم. تتفاعل وحدة الحل التكرارية فقط مع خادم الجذر إذا لم يكن لديها معلومات غير منتهية الصلاحية حول نطاقات المستوى الأعلى أو الجذور نفسها في ذاكرة التخزين المؤقت الخاصة به. و ستؤدي جميع الاستعلامات تقريباً التي يتم تلقيها من قبل خوادم الجذر إلى رد إحالة تخبر خادم الاسم المتكرر بالمكان التالي الذي يجب أن يطرح فيه سؤاله.
8.3 هل لدى أي من معرفات خادم الجذر معنى خاص؟
لا تعتبر أي من معرفات خادم الجذر خاصة.
8.4 هل هناك 13 خادم جذر فقط؟
يوجد أكثر من 1500 خادم على مستوى العالم، ولكن فقط 13 معرّفًا لخادم الجذر (RSI)، يستخدم كل منها عنوان IPv4 واحد وعنوان IPv6 واحدًا وتوجيهًا متعدد الاتجاهات.
8.5 هل يقوم مشغلو خادم الجذر بإجراء العمليات بشكل مستقل؟
تعمل هذه المنظمات بشكل مستقل، لكنها تنسق أيضًا بشكل وثيق مع بعضها البعض عبر اللجنة الاستشارية لنظام خادم الجذر RSSAC والمنتديات الأخرى. لمزيد من المعلومات، راجع RSSAC042: بيان لجنة RSSAC حول استقلالية مشغل خادم الجذر.
8.6 هل تتلقى خوادم الجذر جزء TLD فقط من استعلام DNS؟
حاليًا، تتلقى خوادم الجذر (وفي الواقع جميع خوادم DNS) اسم الاستعلام بالكامل في طلب DNS. ومع ذلك، تم تحديد ميزة جديدة لنظام DNS والتي سترسل جزء TLD من اسم النطاق إلى خوادم الجذر فقط عند الضرورة.
تصف وثيقة RFC 9156 كيف يمكن لخوادم نظام DNS التكرارية أن ترسل فقط أصغر جزء ضروري من اسم الاستعلام. وهذا ما يسمى تصغير اسم الاستعلام أو تصغير QNAME. يعمل تصغير QNAME من خلال جعل خوادم DNS التكرارية ترسل فقط الأجزاء الضرورية من اسم النطاق إلى الخوادم التي تستعلم من خلالها. يجب أن ترسل خوادم DNS التكرارية التي تستخدم تصغير QNAME فقط جزء TLD من استعلام خوادم الجذر. هذا يقلل من كمية المعلومات المنتقلة وبالتالي يوفر خصوصية أفضل للمستخدمين الذين يستعلمون عن DNS.