Skip to main content

الأسئلة المتكررة حول خطة إدارة حالات تضارب أسماء نطاقات المستوى الأعلى العام الجديد New gTLD

هذه الصفحة متوفرة باللغات:

تؤكد رسالة ICANN وقيمها الجوهرية الى الحفاظ على وتعزيز الأستقرار التشغيلي والموثوقية وقابلية التشغيل المتبادل لنظام الإنترنت ذو المعرّفات الفريدة من نوعها ( تشمل المعرفات الأسماء ورقم بروتوكول الإنترنت IP ومعرّفات البروتوكول). وسعياً نحو هذه الاهداف وإتباعاً لتوجيات أعضاء مجلس الإدارة وكذلك مع الأخذ بنظر الإعتبار مشورة اللجنة الإستشارية للأمن والإستقرار، كُلّفت ICANN بإجراء دراسة حول تأثيرات الأمن المحتملة للسلاسل التي تم التقديم عليها ضمن نظام new gTLD الجديد. وكانت الدراسة للنظر فيما لو كان تضارب الأسماء محتمل الوقوع بين طلبات السلاسل المقدمة الى نظام new gTLD وأسماء النطاق التي قد تكون مستخدمة ضمن مساحات الأسماء الخاصة (النطاقات غير القابلة للتفويض non-delegated TLDs). وكانت من أهداف الدارسة أيضاً، النظر في إحتمالية حدوث تضارب للأسماء الناتجة من إستخدام الأسماء الداخلية التي من أجلها تم إصدار الشهادات الرقمية فئة X.509.

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

نشرت ICANN في 5 آب 2013 على موقعها الألكتروني دراسة عن تضارب الأسماء http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf [PDF، 3.34 ميجابايت] وأطلقت عليها تسمية "الدراسة" ("the Study") والتي حددت فئات السلاسل حسب ورود الإستفسارات والشكوك بشأنها، وكما تمت تحديدها في عينات سجل خادم الجذر التي تم الحصول عليه من  مبادرة يوم في حياة الإنترنت "Day in the life of the Internet"(DITL) والصادرة من مركزبحوث وتحليلات عمليات نظام إسم النطاق DNS-OARC. وأستخدمت الدراسة كمداخلة في: 1) نقل عينات من طلبات DNS الى خوادم الجذر (من المبادرات الرقمية)، تم إستكمالها مع 2) معلومات من الهيئات المانحة للشهادات بخصوص إصدار شهادات للأسماء الداخلية (على سبيل المثال شهادات TLS/SSL "Transport Layer Security/Secure Sockets Layer"). يمكن إيجاد وصف شامل لمنهجية الدراسة هذه في الجزء 3.4 من الدراسة.

وإشتملت الدراسة أيضاً خيارات لتخفيف المخاطرالناجمة، ولكنها لم تعطي توصيات معينة لكل فئة من فئات السلاسل. وإستناداً الى الدراسة، نشرت ICANN على موقعها الألكتروني في 5 آب 2013 مقترحاً لمعالجة مخاطر تضارب الأسماء http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf [PDF، 166 كيلوبايت].

وفي 7 تشرين الأول 2013 تبنّت لجنة برنامج New gTLD الجديد لدى مجلس إدارة ICANN مقترحاً منقّحاً في الرابط أدناه: http://www.icann.org/ar/groups/board/documents/resolutions-new-gtld-07oct13-ar.htm#1.a يصف خطة إدارة تضارب الأسماء الحاصل بين نظام new gTLD الجديد والإستخدامات الخاصة المتواجدة حاليا لنفس السلاسل.

أدناه أسئلة يتكرر طرحها حول الخطة وأجوبةICANN لها.

  1. كيف جمعت ICANN قائمة أسماء نطاقات المستوى الثاني (SLDs – Second-Level Domain Names) لأجل حظرها وإيجاد مسار بديل للتفويض؟

    تتألف كل قائمة بأسماء نطاقات المستوى الثاني من نطاقات المستوى العالي الواجب حظرها من أسماء نطاقات المستوى الثاني SLDs والتي تم الإستفسار عنها من خلال عينات مبادرة DITL للفترة من 2006 والى 2013 ومن خلال مجموعة البيانات التمهيدية المأخوذة من برنامج الإمتدادات الأمنية لإسم النطاق DNSSEC لعام 2010.

  2.  ماهي المعايير التي أستخدمت للنظر في عدم أهلية نطاق المستوى العالي الجديد new gTLD للمسار البديل لأجل التفويض؟

    لقد إعتبرت نطاقات المستوى الأعلى العامة لبرنامج new gTLD والتي آظهرت سلوكاً غير مألوف بخصوص إضافة نطاقات المستوى الثاني SLDs المشكوك فيها الى قائمتهم من عام الى آخر، بإنها غير مؤهلة. بعبارة اخرى، تعتبر ICANN إن نطاقات المستوى الأعلى الجديد new gTLD غير مؤهل لمسار بديل للتفويض في الحالات التي التي تتغير فيها نطاقات المستوى الثاني SLDs بصورة متكررة وواسعة.

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

    على سبيل المثال، فإنه لايزال يُعتبر نطاق المستوى الأعلى TLD المنعزل في مقارنات 2006-2007 مؤهلاً. غير إن نطاقات المستوى الاعلى التي تم عزلها في الفترة 2009-2010 و في الفترة 2011- 2012 لن تكون مؤهلة لمسارات بديلة للتفويض.

  3. هل سيتم تعديل قائمة حظر أسماء نطاقات المستوى الثاني SDL كنتيجة لإستخدام مجموعات اخرى للبيانات أثناء العمل على إطار عمل إدارة حدوث تضارب الأسماء؟

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

  4. هل إن شفرة المصدر لوضع  قائمة الحظر متاحة؟

    تم شرح عملية وضع قائمة الحظر وبصورة مفصلة في كل تقارير التفويضات للمسارات البديلة لكل أسم نطاق جديد new gTLD والذي تم توقيع إتفاقية بشأنه وإعتُبر مؤهلاً وعلى سبيل المثال شاهد الرابط التالي:- http://www.icann.org/en/about/agreements/registries/luxury/luxury-apd-report-12nov13-en.htm. وإن الشفرة التي إستخدمت لإنشاء القائمة قد تم نشرها في الرابط: https://github.com/JASdevteam/dns-oarc

  5. لأي فترة زمنية ينبغي لأسماء النطاقات الثانوية SLDs أن تبقى محظورة في قائمة الحظر؟

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

  6.  لأسم نطاق محدد من نوع TLD ، إن ظهر نطاق المستوى الثاني "nic" في بيانات DITL (مشيراً الى إحتمالية حدوث حالة تضارب أسماء هناك)، فلماذا يسمح لأسم النطاق الثانوي "nic" في نطاق المستوى الأعلى العام gTLD ، ولماذا يكون هذا الخطر أكثر قبولاً من خطر أي تضارب آخر بالأسماء؟

    الأسم الوحيد المطلوب إستخدامه هو "whois.nic<tld>" لغرض عرض خدمة مسجل WHOIS، بعبارة أخرى "whois.nic<tld>". ولأجل موازنة خطورة أستخدام هذا الإسم مع قابلية أستخدام خدمات WHOIS المتاحة في موقع معلوم جداً، قررت ICANN عدم شمل "nic" في قائمة أسماء النطاقات الثانوية الواجب حظرها من أي نطاق للمستوى الأعلى العام الجديد gTLD. وبكل الاحوال فإن آلية الأستجابة لحالة تضارب الأسماء موجودة في الرابط: http://www.icann.org/ar/help/name-collision لأجل إستخدامها من قبل الطرف المتضرر لأجل التبليغ عن أي ضرر بالغ كان قد تسبّب من قبل إسم النطاق. ولاحظوا أيضاً فإن الأسم متاح فقط لمشغل السجل وحده، مما يعني إن للسجل السيطرة التامة على نطاقات المستوى الثاني SLD.

  7. هل ستقوم ICANN بتحديث قائمة أسماء نطاقات المستوى الثاني المحظورة لتتضمن السنة التي تم خلالها الإستفسار عن تلك الأسماء؟

    ليس لـِ ICANN خطة لتحديث قائمة حظر نطاقات المستوى الثاني أو لإضافة السنة التي تم فيها الإستفسار عن تلك الأسماء. ولكن إن كان لمجتمع الإنترنت إهتماماً بهذا الأمر فسيؤخذ ذلك بنظر الإعتبار إضافة تلك البيانات عندما تكون الموارد متاحة.

  8. ما الذي ينبغي القيام به حيال الأسماء المدرجة في قائمة حضر نطاقات المستوى الثاني SLD عندما يتم إطلاقها فيما يخص فترة مايطلق عليها "sunrise " الخاصة بإداء مقاصة العلامات التجارية TMCH والشكاوي؟

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

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

  9. مالذي يسبب ضرراً  يجيز تعطيل أسم نطاق لمستوىً ثان يتسبب في حالات تضارب في الأسماء؟

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

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

  10. هل سيكون هناك موقعاً ألكترونياً خاصاً لحالات تضارب الأسماء؟

    تخطط ICANN لتصميم موقعاً ألكترونياً لعرض المعلومات المتاحة عن هذا الموضوع.

  11. هل تقع مختلف أنواع التفويضات التجريبية ضمن إطار عمل إدارة حالات حدوث تضارب الأسماء؟

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

    بالإضافة الى ذلك، صادق مجلس إدارة ICANN خلال أجتماعه في بوينس آيريس على قرار يوجه العاملين الى تقييم توصيات SSAC's SAC 062 والتي تطالب ICANN صراحةً بالنظر في التفويضات التجريبية.

  12. ماهي العملية التي تساعد في إنجاز العمل لتطوير إطار عمل إدارة حالات حدوث تضارب الأسماء والتي من خلالها يُقرر تبنّي هذا الإطار؟

    يتوقع من المتعاقد الرئيسي أن يعمل على صياغة مسودة لإطار العمل في التعاون مع المجتمع كما هو موضح في الرابط:

    http://www.icann.org/ar/news/announcements/announcement-2-11nov13-ar.htm. ويتم بعد ذلك نشر مسودة إطار العمل هذه لأجل التعليقات العامة. وبعد إنقضاء فترة  التعليقات سيتم عمل خلاصة لكافة التعليقات الواردة وسيتم تحديث إطار العمل إستناداً للمداخلات العامة. وأخيراً، ستقوم لجنة برنامج new gTLD لدى مجلس إدارة ICANN بالنظر في النسخة النهائية لإطار العامل لأجل إعتماده بعد ذلك.

  13. أين يمكن للجمهور المشاركة في وضع إطار عمل إدارة حالات تضارب الأسماء؟

    الكل مرحب به للمشاركة في وضع إطار العمل. وستتم مناقشة المشاركات عبر الرسائل الالكترونية العامة من خلال الرابط: <https://lists.dns-oarc.net/mailman/listinfo/collisions>

  14. هل سيتم توسيع إدارة تضارب الأسماء الى نطاقات المستوى الاعلى لرموز البلدان ccTLD ؟

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


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."