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

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

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

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

1. عدد خوادم الجذر
2. التوجيه متعدد الاتجاهات (Anycast)
3. نظام اسم النطاق والشبكات
4. سلامة منطقة الجذر
5. الامتدادات الأمنية لنظام اسم النطاق (DNSSEC)
6. اللجنة الاستشارية لنظام خادم الجذر (RSSAC)
7. تجمّع اللجنة الاستشارية لنظام خادم الجذر (RSSAC)
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: تاريخ نظام خادم الجذر. إذا كنت مهتمًا بالتطور المستمر لنظام خادم الجذر (RSS)، فيُرجى قراءة 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 لماذا يوجد لدى بعض المشغلين العديد من معدات التوجيه متعدد الاتجاهات في حين لا يوجد لدى المشغلين الآخرين إلا القليل؟

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

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

   يتم تعريف عملية تعدد الاتجاهات ووصفها في RFC 4786"تشغيل خدمات التوجيه متعدد الاتجاهات" و RFC 7094 "الاعتبارات التصميمية لتعدد اتجاهات IP". لا يوجد حد ملازم لعدد العقد في خدمة التوجيه متعدد الاتجاهات.

   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
   جامعة ميريلاند
   معهد علوم المعلومات بجامعة جنوب كاليفورنيا	https://b.root-servers.org/
   معمل بحوث (الجيش الأمريكي)
   Verisign, Inc.	https://www.verisign.com/rirs
   مشروع WIDE

   2.7 Hكيف يمكنني تحديد معدات مُعرّف خادم الجذر التي تستجيب لاستعلاماتي؟

   يمكنك استخدام أداة مُجمع معلومات المجال (ديغ) من نظام كمبيوتر يعمل بنظام 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 تقريبًا نقل مخطط بيانات مستخدم الإنترنت افتراضيًا للاستعلامات. ومع ذلك، هناك بعض المواقف التي تحتاج إلى استخدام بروتوكول التحكم في الإرسال بدلاً من ذلك.

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

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

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

   يعتبر بروتوكول التحكم في الإرسال عبر 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 حيثما أمكن.

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

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

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

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

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

5. DNSSEC

   5.1 هل تجعل DNSSEC استعلامات أو إجابات DNS سرية؟

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

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

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

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

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

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

   تعقد اللجنة مؤتمرات عبر الهاتف منتظمة وتلتقي في اجتماعات ICANN. يمكنك الاطلاع على محاضر الاجتماعات والمؤتمرات عبر الهاتف (حيثما توفرت) من هنا. لمتابعة ومراقبة مؤتمر عبر الهاتف أو جلسة عمل للجنة RSSAC، يُرجى الاتصال على rssac-staff@icann.org للحصول على معلومات المشاركة عن بعد.

   يُسمح بحضور المراقبين معظم اجتماعات لجنة 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)؟ هل لجنة مراجعة تطوير منطقة الجذر عبارة عن مجموعة فرعية من اللجنة الاستشارية لنظام خادم الجذر؟

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

   تنص اللجنة الاستشارية لنظام خادم الجذر على أنها:

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

   تنص لجنة مراجعة تطوير منطقة الجذر على أنها:

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

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

   

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

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

   6.5 أين يمكنني العثور على منشورات لجنة RSSAC؟

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

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

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

   7.1 ما الفرق بين عضو اللجنة الاستشارية لنظام خادم الجذر وعضو تجمع اللجنة الاستشارية لنظام خادم الجذر؟

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

   جميع أعضاء لجنة RSSAC هم أيضًا أعضاء في RSSAC Caucus. يمكن العثور على قائمة بأعضاء لجنة RSSAC هنا. يمكن العثور على قائمة بأعضاء RSSAC Caucus هنا. يمكنك العثور على معلومات حول كيفية الانضمام إلى RSSAC Caucus على صفحة RSSAC Caucus.

   7.2. هل يُسمح لأي شخص بحضور اجتماعات RSSAC Caucus؟

   يعقد تجمع اللجنة الاستشارية لنظام خادم الجذر جمعيات عامة خلال الاجتماع السنوي العام لمنظمة ICANN وفي كل فريق عمل هندسة الإنترنت مرقم بالتساوي. ويُسمح بحضور المراقبين اجتماعات هذه الجمعيات العامة. اجتماعات فريق عمل تجمع اللجنة الاستشارية لنظام خادم الجذر ليست مفتوحة للمراقبين.

   ويتم دعوة جميع أعضاء تجمع اللجنة الاستشارية لنظام خادم الجذر مدعوون للمشاركة في كافة الاجتماعات العامة للتجمع واجتماعات فريق عمل التجمع.

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

   لا.

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

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

8. جوانب سوء الفهم الشائعة

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

   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 من اسم النطاق إلى خوادم الجذر فقط عند الضرورة.

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