الأسئلة الشائعة والأجوبة الخاصة بلجنة RSSAC

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

إذا كان لديكم أي استفسار غير مدرج أدناه، أو للحصول على مزيد من المعلومات أو التوضيح، فيمكنك مراسلتنا مباشرة بالبريد الإلكتروني على ask-rssac@icann.org. إذا كنت ترغب في الرجوع إلى سؤال في هذه الأسئلة والأجوبة، فيرجى تضمين رقم السؤال وعنوانه في بريدك الإلكتروني. ويملك مشغلو خادم الجذر أسئلة وأجوبة

قائمة الموضوعات

1. عدد خوادم الجذر
2. التوجيه متعدد الاتجاهات - anycast
3. DNS وتوصيل الشبكات
4. سلامة منطقة الجذر
5. الامتدادات الأمنية لنظام أسماء النطاقات
6. اللجنة الاستشارية لنظام خادم الجذر
7. تجمع اللجنة الاستشارية لنظام خادم الجذر
8. حالات سوء الفهم الشائعة

1. عدد خوادم الجذر

   1.1 لماذا يوجد 13 اسمًا لخادم الجذر؟

   في عام 1985، كان هناك أربعة خوادم جذر. من 1987-1991 كان هناك سبعة، وجميعها كانت موجودة في الولايات المتحدة الأمريكية. بحلول عام 1993 كان هناك ثمانية. في هذه المرحلة، تمت مواجهة مشكلة. ينص RFC 1035 على أن "رسائل [DNS] التي يحملها بروتوكول مخطط بيانات مستخدم الإنترنت مقيدة بـ 512 بايت". ستؤدي إضافة المزيد من خوادم أسماء الجذر إلى استجابة أولية تجاوزت 512 بايت.لا يقدم RFC 1035 أساسًا منطقيًا للحد البالغ 512 بايت، ولكن تجدر الإشارة أيضًا إلى أنه في ذلك الوقت، كان هناك شرطًا شائعًا يقتصر على حزم IP على الإنترنت إلى 576 بايت.

   أدرك مشغلو خادم الجذر أنه يمكنهم إضافة المزيد من خوادم الأسماء إذا تمكنوا من الاستفادة من ضغط اسم DNS. وبالتالي، تم تقديم الاقتراح لإعطاء أسماء خوادم الجذر في منطقة root-servers.net. وبحلول عام 1995، تمت إعادة تسمية خوادم الجذر التسعة الحالية إلى "a.root-servers.net" و"b.root-servers.net" وما إلى ذلك. في عام 1997، تمت إضافة أربعة أخرى، مما رفع إجمالي عدد معرفات خادم الجذر (RSIs) إلى 13.

   حتى عام 1998، كان الدكتور جون بوستل، بصفته مدير IANA، هو المسؤول عن تعيين مشغلي خادم الجذر. وبعد وفاته في عام 1998، لم يتغير عدد المشغلين، على الرغم من أن عددًا صغيرًا قد تغير على مر السنين.

   منذ عام 1998، تغير المشهد بعدة طرق. أضاف كل خادم جذر عنوان بروتوكول الإننرنت - الإصدار السادس (IPv6) الخاص به، ووقعت ICANN المنطقة مع الامتدادات الأمنية لنظام اسم النطاق (DNSSEC). أيضًا، تم توسيع حجم الرسائل التي تم نقلها عبر بروتوكول مخطط بيانات مستخدم الإنترنت (UDP) باستخدام آلية تمديد الامتداد لبروتوكول DNS (EDNS). قدمت هذه التغييرات مجتمعة حدًا لمخطط بيانات مستخدم الإنترنت بقيمة 512 بايت و13 حد لمعرفات خادم الجذر (RSIs) أقل أهمية بكثير.

   في عام 2002، أصبح اتحاد برامج الإنترنت (ISC، الآن اتحاد أنظمة الإنترنت) أول مشغل خادم جذر ينشر IP متعدد الاتجاهات، على الرغم من أن مشروع WIDE قد جرب التكنولوجيا في وقت سابق. وعلى مدار السنين، اتبعت عوامل خادم الجذر الأخرى. يسمح تعدد الاتجاهات لكل مشغل بتقديم الخدمة من نماذج مميزة متعددة. بينما لا يزال هناك اليوم 13 معرف خادم جذر (RSIs)، فإن هناك في الواقع أكثر من 1500 نموذج متعدد الاتجاهات في التشغيل في جميع أنحاء العالم.

   للحصول على فهم أفضل لتاريخ نظام خادم الجذر (RSS)، برجاء قراءة RSSAC023v2: تاريخ نظام خادم الجذر. إذا كنت مهتمًا بالتطور المتواصل لنظام خادم الجذر، برجاء قراءةRSSAC037: نموذج حوكمة مقترح لنظام خادم جذر DNS.

   1.2 ما هي الرياضيات وراء حد معرفات خادم الجذر الـ 13؟

   في عام 1997، كانت خوادم الجذر تعمل أيضًا كخوادم موثوقة لمناطق .COM و.NET و.ORG، وقد وضعت هذه الوظيفة المضافة قيودًا مهمة على عدد معرفات خادم الجذر التي يمكن أن تكون موجودة. تمامًا كما هو الحال مع الاستعلام التمهيدي لمنطقة الجذر، لا يمكن أن يتجاوز الاستعلام عن NS RRSET للمناطق .COM و.NET و.ORG حد 512 بايت، وبما أن نفس الخوادم كانت تخدم هذه المناطق، فقد تم تطبيق نفس القيد على جميعها.

   تحتوي حزمة استجابة DNS أيضًا على السؤال الكامل الذي تم طرحه في قسم الأسئلة. ستستخدم أي استجابة على استعلام تمهيدي الجذر دائمًا 5 بايت لقسم الأسئلة. يأخذ QNAME بايت واحد، ويأخذ كل من QTYPE وQCLASS 2، ليصبح المجموع 5. ومع ذلك، بالنسبة للاستعلام التمهيدي .COM يمكن أن يكون قسم الأسئلة أكبر بكثير.

   الغرض	بايت
   ترويسة DNS	12
   أول سجل NS	31
   12 سجل NS مضغوط	(12 * 15) 180
   13 سجل A	(13 * 16) 208
   قسم أسئلة QTYPE وQCLASS	4
   قسم أسئلة QNAME	؟
   	=
   	435

   جدول رقم 1: شرح البايتات المستخدمة في استجابة معايرة الجذر

   مع وجود 435 بايت قيد الاستخدام، فقد ترك ذلك 77 بايت متاحة لقسم الأسئلة QNAME. في ذلك الوقت تم تحديد أن 64 بايت ستكون كافية لاستيعاب معظم الاستعلامات المرسلة لـ.COM و.NET و.ORG. تتطلب إضافة خادم آخر 25 بايت، وبما أن 435 + 64 + 25> 512، فقد تقرر عدم إضافة خادم آخر.

2. التوجيه متعدد الاتجاهات

   2.1 ما السبب في أن بعض المشغلين لديهم العديد من معدات التوجيه متعدد الاتجاهات في حين أن المشغلين الآخرين لديهم القليل منها؟

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

   2.2 هل عدد عقد تعدد الاتجاهات غير محدود أو محدود بعدد معين؟

   إن عمل التوجيه متعدد الاتجاهات - anycast معرَّف ومذكور في RFC 4786 بعنوان "تشغيل خدمات التوجيه متعدد الاتجاهات - anycast" وأيضًا في RFC 7094 بعنوان "الاعتبارات الهندسية للتوجيه متعدد الاتجاهات لبروتوكولات الإنترنت." لا يوجد حد ملازم لعدد العقد في خدمة تعدد الاتجاهات.

   2.3 تقوم خوادم الجذر بتكرار منطقة الجذر الموثوقة وإعادة نشرها، ثم تقوم حالات تعدد الاتجاهات بإعادة نشر البيانات منها. ما الفرق بين هذين النوعين من إعادة النشر؟

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

   2.4 نحن نستضيف حالات تعدد الاتجاهات لخادم الجذر في مدينة محلية. ونرى أنها تجيب على الاستعلامات من جميع أنحاء العالم. كيف يمكنني أن أجيب فقط على الاستعلامات من المنطقة المحلية؟

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

   2.5 في عام 2016، كان هناك هجوم كبير على شركة Dyn. هل يمكن أن يحدث الشيء نفسه لجميع حالات تعدد الاتجاهات لخادم الجذر؟

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

   2.6 كيف يمكنني طلب حالة تعدد الاتجاهات لخادم الجذر لمؤسستي؟

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

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

   شركة كوجينت للاتصالات (Cogent Communications)
   وزارة الدفاع الأمريكية (NIC)
   ICANN	https://www.dns.icann.org/imrs/host/
   Internet Systems Consortium, Inc.	https://www.isc.org/f-root/hosting-an-f-root-node/
   مركز بحث أميس التابع لناسا (NASA Ames Research Center)
   Netnod	https://www.netnod.se/i-root/i.root-servers.net
   RIPE NCC	https://www.ripe.net/analyse/dns/k-root/hosting-a-k-root-node
   جامعة ماريلاند (University of Maryland)
   معهد علوم المعلومات التابع لجامعة جنوب كاليفورنيا	https://b.root-servers.org/
   معمل بحوث (الجيش الأمريكي)
   Verisign, Inc.	https://www.verisign.com/rirs
   مشروع WIDE

   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 لكل من بروتوكول مخطط بيانات مستخدم الإنترنت ومنفذ TCP 53؟

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

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

   استخدام آخر لبروتوكول التحكم في الإرسال لـ DNS يتمثل في عمليات نقل المنطقة. نظرًا لأن المناطق بأكملها تكون بشكل عام أكبر بكثير مما قد تتناسب مع رسالة واحدة لمخطط بيانات مستخدم الإنترنت، فمن المنطقي القيام بذلك عبر بروتوكول التحكم في الإرسال.

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

   يعتبر بروتوكول التحكم في الإرسال عبر DNS إلزاميًا للتنفيذ في برنامج DNS. للحصول على مزيد من المعلومات، برجاء مراجعة RFC 7766.

   3.3 كيف يمكنني تقليل وقت الاستجابة بين الخادم المتكرر الذي أقوم بتشغيله وخادم الجذر؟

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

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

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

   لمزيد من المعلومات حول جودة DNS لقياسات الخدمة، يقوم مشروع أطلس Réseaux IP Européens (RIPE) بمراقبة جودة خدمة الجذر مع مشروع DNSMON الخاص به. يتم قياس وقت الاستجابة لمعظم الخوادم بمئات من مراسي Atlas للشبكات الأوروبية لبروتوكول الإنترنت أقل من 60 مللي ثانية.

   إذا لم تكن هناك خوادم جذر قريبة بشكل معقول، فيمكنك محاولة تحديد نقطة تبادل أو مركز بيانات قريب حيث يمكن إيجاد خادم جذر. اسأل واحدًا أو أكثر من مشغلي خادم الجذر ما إذا كانوا على استعداد لوضع خادم هناك. ومع ذلك، لاحظ أنه إذا كان الموقع يحتوي بالفعل على خادم جذر واحد، فلن يرغب المشغلون عادةً في وضع خادم آخر هناك. يمكنك الحصول على معلومات اتصال المشغل من خلال زيارة http://www.root-servers.org وتحديد مكان أزرار "البريد الإلكتروني لجهة الاتصال" في قسم خوادم الجذر أسفل الصفحة.

   3.4 هل يمكنك إعداد خادم الجذر بنفسك عن طريق تنزيل ملف منطقة الجذر والتحقق من صحة التوقيع بنفسك؟

   يصف RFC 8806 كيفية القيام بذلك، بالإضافة إلى إدراج العديد من التحذيرات حول المساوئ المحتملة جراء القيام بذلك. لاحظ أنه يتطلب التحقق من DNSSEC. راجع أيضًا مشروع LocalRoot.

   3.5 ما المدة التي يخزن فيها الخادم التكراري المعلومات تخزينًا مؤقتًا؟

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

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

   3.6 لأن التخزين المؤقت سيعطي معلومات خاطئة بعد مرور الوقت، كيف يمكن تحديث وحدة حل بمعلومات DNS الصحيحة؟

   إذا كنت تشك في أن البيانات الموجودة في ذاكرة التخزين المؤقت لخادم اسم متكرر قديمة، فيمكنك مسح ذاكرة التخزين المؤقت أو إعادة تشغيل عملية الخادم.

   3.7 ما هي استعلامات وردود معايرة DNS؟

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

4. سلامة منطقة الجذر

   4.1 كيف يتأكد المشغلون من تكرار منطقة الجذر بشكل صحيح؟

   وتحدث عملية نقل ملف منطقة الجذر من مدير الصيانة على منطقة الجذر (RZM) إلى مشغلي خوادم الجذر الفرديين وذلك من خلال بروتوكولات نقل منطقة DNS وهما (بروتوكول AXFR في RFC 5936 وبروتوكول IXFR في RFC 1995). وتتم حماية رسائل نقل المنطقة هذه من خلال استخدام سجلات مصدر توقيع التحويل (TSIG)وفقًا لما هو مذكور في RFC 2845. فهذا بروتوكول يُعد موثوقًا ولا توجد حوادث معروفة لتلف البيانات. علاوة على ذلك، نظرًا لتوقيع منطقة الجذر، يمكن التحقق من الإجابات غير الصحيحة أو المزيفة بواسطة مدققي DNSSEC. تشجع اللجنة الاستشارية لنظام خادم الجذر على استخدام التحقق من DNSSEC حيثما أمكن.

   يستخدم مدير منطقة الجذر (RZM) إشعار DNS المحدد في RFC 1996 للإعلام الفوري بتغييرات المنطقة لتنبيه مشغلي منطقة الجذر بأن منطقة جديدة (أي أحدث إصدار) متاحة للنسخ أو النقل.

   4.2 ما هو ZONEMD وكيف يمكنه حماية سلامة بيانات منطقة الجذر؟

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

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

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

5. الإمتدادات الأمنية لنظام اسم النطاق (DNSSEC)

   5.1 هل تقدم DNSSEC استفسارات DNS أو ردود سرية؟

   لا ، فهي تُضيف فقط طبقة أمان إلى البنية التحتية لنظام DNS من خلال مصادقة أصل بيانات DNS، إضافة إلى حماية سلامتها.

   5.2 هل تزيد امتدادات DNSSEC من صعوبة تقديم نسخة من منطقة الجذر محليًا؟

   لا، إن تقديم نسخة محلية من منطقة الجذر يعني ببساطة تقديم نسخ محدثة من منطقة الجذر دون أي تغييرات. تأتي منطقة الجذر من مدير منطقة الجذر (RZM) مع جميع توقيعات DNSSEC المطلوبة.

   للحصول على مزيد من المعلومات حول كيفية تقديم منطقة الجذر محليًا، راجع السؤال 3.4 وأيضًا RFC 8806.

6. اللجنة الاستشارية لنظام خادم الجذر

   (RSSAC)6.1 ما الصلة بين اللجنة الاستشارية لنظام خادم الجذر ولجنة مراجعة تطوير منطقة الجذر؟ هل لجنة مراجعة تطوير منطقة الجذر عبارة عن مجموعة فرعية من اللجنة الاستشارية لنظام خادم الجذر؟

   تعتبر اللجنة الاستشارية لنظام خادم الجذر (RSSAC) ولجنة مراجعة تطوير منطقة الجذر (RZERC) لجنتين منفصلتين داخل ICANN، على الرغم من وجود اتصالات بينهما وقد يعمل أفراد في كلتا اللجنتين.

   تنص اللجنة الاستشارية لنظام خادم الجذر على أنها:
   "..تقدم المشورة لمجلس إدارة ICANN والمجتمع بشأن الأمور المتعلقة بتشغيل وإدارة وأمن وتكامل نظام خادم الجذر." للحصول على مزيد من المعلومات حول دور اللجنة الاستشارية لنظام خادم الجذر، برجاء قراءة RSSAC033: بيان اللجنة الاستشارية لنظام خادم الجذر حول التمييز بين اللجنة الاستشارية لنظام خادم الجذر وعمليات الجذر.

   تنص لجنة مراجعة تطوير منطقة الجذر على أنها:
   "..من المتوقع أن تقوم بمراجعة التغييرات المعمارية المقترحة لمحتوى منطقة جذر DNS، والأنظمة بما في ذلك مكونات الأجهزة والبرامج المستخدمة في تنفيذ التغييرات على منطقة جذر DNS، والآليات المستخدمة لتوزيع منطقة جذر DNS."

   يساعد الرسم التالي على شرح أدوار كل مجموعة.

   

   6.2 هل هناك إطار زمني لموعد معرفة عدد خوادم الجذر التي تريد اللجنة الاستشارية لنظام خادم الجذر الحصول عليها؟ متى سيحدث التقييم لتحديد عدد الحروف؟

   ليس لدى اللجنة الاستشارية لنظام خادم الجذر تصورات مسبقة حول عدد خوادم الجذر أو عدد مشغلي خوادم الجذر التي يجب أن تكون موجودة. يعتبر الحد الحالي لعدد المشغلين تقني وليس إداري.

   6.3 أين يمكنني الحصول على منشورات اللجنة الاستشارية لنظام خادم الجذر (RSSAC)؟

   يتم نشر منشورات اللجنة الاستشارية لنظام خادم الجذرعلى صفحة منشورات RSSAC على الانترنت. تُمثل RSSAC023v2 أهمية خاصة للأشخاص الذين يتعرفون على نظام خادم الجذر:تاريخ نظام خادم الجذر, وRSSAC026v2:معجم مصطلحات اللجنة الاستشارية لنظام خادم الجذر (RSSAC)

7. تجمع اللجنة الاستشارية لنظام خادم الجذر (RSSAC)

   يمكن الحصول على معلومات حول تجمع اللجنة الاستشارية لنظام خادم الجذر على صفحة الويب الرئيسة الخاصة بهم.

   7.1 هل هناك حد لعدد أعضاء مجموعة اللجنة الاستشارية لنظام خادم الجذر؟

   لا.

   7.2 ما هي متطلبات الوقت بالنسبة لأعضاء تجمع اللجنة الاستشارية لنظام خادم الجذر؟

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

8. حالات سوء الفهم الشائعة

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

   8.1 هل تتحكم خوادم الجذر في أين تذهب حركة الإنترنت؟

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

   8.2 هل تتم معالجة معظم استعلامات DNS بواسطة خادم جذر؟

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

   8.3 هل لدى أي من معرفات خادم الجذر معنى خاص؟

   لا تعتبر أي من معرفات خادم الجذر خاصة.

   8.4 هل يوجد 13 خادم جذر فقط؟

   يوجد أكثر من 1500 خادم على مستوى العالم، ولكن فقط 13 معرّفًا لخادم الجذر (RSIs)، يستخدم كل منها عنوان IPv4 وعنوان IPv6 واحدًا وتوجيهًا متعدد الاتجاهات.

   8.5 هل يُجري مشغلو خادم الجذر عمليات مستقلة؟

   تعمل هذه المنظمات بشكل مستقل، لكنها تنسق أيضًا بشكل وثيق مع بعضها البعض عبر اللجنة الاستشارية لنظام خادم الجذر والمنتديات الأخرى. لمزيد من المعلومات، راجع RSSAC042: بيان اللجنة الاستشارية لنظام خادم الجذر حول استقلالية مشغل خادم الجذر.

   8.6 هل تتلقى خوادم الجذر جزء TLD فقط من استعلام DNS؟

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

   يصف RFC 9156 طريقة استخدام خوادم DNS التكرارية إرسال أصغر جزء ضروري فقط من اسم الاستعلام. وهذا ما يسمى تصغير اسم الاستعلام أو تصغير QNAME. يعمل تصغير QNAME من خلال جعل خوادم DNS المتكررة ترسل فقط الأجزاء الضرورية من اسم النطاق إلى الخوادم التي تستعلم عنها. يجب أن ترسل خوادم DNS المتكررة التي تستخدم تصغير QNAME فقط جزء TLD من استعلام خوادم الجذر. هذا يقلل من كمية المعلومات على السلك وبالتالي يوفر خصوصية أفضل للمستخدمين الذين يستعلمون عن DNS.