فحص النطاقات المرتبطة هو متطلب ICANN مقترح من شأنه أن يُلزم المُسجِّل بالتحقيق في النطاقات الأخرى المرتبطة بنفس حساب العميل أو المُسجِّل بعد ثبوت أدلة قابلة للتنفيذ على إساءة استخدام DNS لنطاق معين.
هذا الأمر مهم لأن حملات التصيد غالبًا ما تستخدم أكثر من نطاق واحد.
إذا كان الحساب يحتوي على 300 نطاق وتم تأكيد أن أحدها جزء من حملة تصيد، فإن التحقيق في ذلك النطاق فقط قد يترك بنية تحتية خبيثة ذات صلة دون مساس.
ولكن هناك ضمانة مهمة بنفس القدر :
كون النطاق مرتبطًا بنطاق مسيء لا يجعله تلقائيًا نطاقًا مسيئًا.
تطلب ICANN حاليًا تعليقات الجمهور حول هذه القضية من خلال عملية تطوير السياسات لتخفيف إساءة استخدام DNS رقم 1. يحتوي التقرير الأولي على ثماني توصيات أولية وخمسة إرشادات تنفيذية. تظل التعليقات العامة مفتوحة حتى 28 سبتمبر 2026. (icann.org)
بالنسبة لمالكي النطاقات ومُبلغي الإساءة والموزعين، من المهم أيضًا الفصل بين سؤالين مختلفين :
ما الذي يجب على المُسجِّلين فعله بالفعل بعد تلقي شكوى تصيد؟
و
ما الالتزامات الجديدة التي يمكن أن تضيفها فحوصات النطاقات المرتبطة في المستقبل؟
إنهما ليسا الشيء نفسه.
تنشر NiceNIC عملية التعامل الحالية مع الإساءة عبر صفحة NiceNIC للتعامل مع إساءة استخدام النطاقات والشفافية وسياساتها الرسمية سياسة الإبلاغ عن الإساءة والتعامل معها.
ما هو فحص النطاقات المرتبطة؟
يهدف فحص النطاقات المرتبطة، والذي يُختصر غالبًا إلى ADC، إلى نقل تحقيقات DNS المتعلقة بالإساءة إلى ما هو أبعد من نهج يعتمد على نطاق بنطاق فقط.
اليوم، تخيل أن المُسجِّل يؤكد أن example1.com تم تسجيله بشكل ضار ويُستخدم في التصيد.
قد يحتوي نفس حساب العميل أيضًا على:
example2.com example3.com example4.com
قد تكون هذه النطاقات غير مرتبطة و مشروعة.
أو قد تشكل جزءًا من نفس حملة التصيد .
السؤال السياساتي الذي تدرسه ICANN حاليًا هو ما إذا كان يجب إلزام المُسجِّل بالتحقيق في تلك النطاقات المرتبطة بدلاً من انتظار قيام شخص ما بالإبلاغ عن كل نطاق بشكل منفصل.
تصف ICANN الغرض من PDP بأنه خلق التزام على المُسجِّلين بالتحقيق في النطاقات المرتبطة بحساب العميل أو المُسجِّل عندما يُكتشف أن نطاقًا واحدًا على الأقل يشارك في إساءة استخدام DNS. (icann.org)
حدد ميثاق PDP الأصلي الفجوة الحالية بوضوح: المُسجِّلون لديهم بالفعل التزامات لتقييم النطاقات المُبلَّغ عنها، ولكن لا يوجد حاليًا متطلب تعاقدي عام للتحقيق في جميع النطاقات النشطة الأخرى المرتبطة بنفس الحساب بعد تحديد نطاق ضار واحد. (gnso.icann.org)
هل فحص النطاقات المرتبطة مطلوب بالفعل من قبل ICANN؟
لا، ليس كمتطلب ICANN لسياسة توافقية جديدة اليوم.
هذا التمييز مهم.
فحوصات النطاقات المرتبطة هي حاليًا جزء من DNS لتخفيف إساءة الاستخدام PDP 1 التقرير الأولي.
العملية حاليًا:
التقرير الأولي ← تعليقات الجمهور ← مراجعة تعليقات الجمهور ← المزيد من عمل مجموعة العمل ← التوصيات النهائية المحتملة
تنتهي فترة التعليق العام الحالية في:
28 سبتمبر 2026 الساعة 23:59 UTC
لذا سيكون من غير الدقيق القول:
«ICANN تطلب الآن من المُسجِّلين فحص كل نطاق في الحساب بعد تقرير تصيد واحد.»
هذه ليست القاعدة الحالية.
ما تفكر فيه ICANN هو التزام مستقبلي يتطلب من المُسجِّلين التحقيق في النطاقات المرتبطة بعد استيفاء المحفز السياساتي ذي الصلة. (icann.org)
ما الذي يجب على المُسجِّل فعله بعد تلقي شكوى تصيد؟
ICANN — المُسجِّلون المعتمدون لديهم بالفعل التزامات قابلة للتنفيذ بموجب القسم 3.18 من اتفاقية اعتماد المُسجِّلين.
التصيد مدرج صراحةً في تعريف ICANN لإساءة استخدام DNS. (itp.cdn.icann.org)
بعد تلقي تقرير إساءة يتضمن نطاقًا مُدارًا، يجب على المُسجِّل عمومًا القيام بأربعة أشياء .
1. هل يجب على المُسجِّل توفير طريقة للإبلاغ عن التصيد؟
نعم.
يجب على المُسجِّل المعتمد من ICANN الاحتفاظ بجهة اتصال لمعالجة الإساءة وجعل عنوان بريد إلكتروني أو نموذج ويب لتقارير الإساءة متاحًا بسهولة .
توفر NiceNIC صفحة مخصصة للإبلاغ عن إساءة استخدام النطاق للتقارير المتعلقة بالتصيد والبرامج الضارة وغيرها من أنواع الإساءة ذات الصلة.
2. هل يجب على المُسجِّل تأكيد استلام الشكوى؟
نعم.
بموجب القسم 3.18.1 من اتفاقية RAA، يجب على المُسجِّل تقديم تأكيد باستلام تقرير الإساءة. (itp.cdn.icann.org)
توضح نشرة ICANN الاستشارية للامتثال بشأن إساءة استخدام DNS أنه، كحد أدنى، يجب أن يحدد التأكيد ما يلي:
- المُسجِّل؛
- اسم أو أسماء النطاقات المُبلَّغ عنها؛
- تاريخ تقديم التقرير. (icann.org)
3. هل يجب على المُسجِّل التحقيق في شكوى التصيد؟
نعم.
استلام الشكوى لا يثبت تلقائيًا حدوث إساءة استخدام.
ولكن لا يمكن للمُسجِّل ببساطة تجاهل التقرير.
يتطلب القسم 3.18.1 من RAA من المُسجِّلين اتخاذ خطوات معقولة وسريعة للتحقيق والاستجابة بشكل مناسب لتقارير الإساءة. (itp.cdn.icann.org)
قد يأخذ التحقيق في الاعتبار الأدلة التي قدمها المُبلِّغ بالإضافة إلى المعلومات المتاحة بشكل معقول للمُسجِّل .
4. ما الذي يجب على المُسجِّل فعله إذا تم تأكيد أدلة التصيد؟
عندما يمتلك المُسجِّل أدلة قابلة للتنفيذ على أن نطاقًا ما يُستخدم لإساءة استخدام DNS، يتطلب القسم 3.18.2 من RAA من المُسجِّل اتخاذ إجراءات تخفيف مناسبة على وجه السرعة، بشكل معقول وضروري لوقف الإساءة أو تعطيلها بطريقة أخرى. (itp.cdn.icann.org)
الاستجابة المناسبة تعتمد على الظروف.
ليست بالضرورة نفس الإجراء لكل حالة تصيد .
هل تعني شكوى التصيد تلقائيًا تعليق النطاق؟
لا. شكوى التصيد بحد ذاتها لا تتطلب تلقائيًا تعليق النطاق.
يحتاج المُسجِّل أولاً إلى تقييم التقرير والأدلة المتاحة.
هناك فرق مهم بين:
ادعاء تصيد
و
أدلة قابلة للتنفيذ على أن النطاق يُستخدم لأغراض التصيد.
بمجرد وجود أدلة قابلة للتنفيذ، يجب على المُسجِّل التصرف بسرعة وبشكل مناسب.
ولكن حتى في هذه الحالة، التعليق ليس تلقائيًا الاستجابة الوحيدة الممكنة.
تطلب ICANN على وجه التحديد من المُسجِّلين مراعاة عوامل تشمل:
- سبب الإساءة؛
- شدة الضرر؛
- ما إذا كان المستخدمون يواجهون خطرًا وشيكًا؛
- الضرر الجانبي المحتمل؛
- ما إذا كان النطاق نفسه قد تم تسجيله بشكل ضار؛
- ما إذا كان النطاق المشروع قد تم اختراقه. (icann.org)
في أحد أمثلة الامتثال لدى ICANN، تم تأكيد أن نطاقًا مسجلًا حديثًا ينتحل صفة بنك وكان يستخدم للتصيد. تم اعتبار تطبيق clientHold لتعليق النطاق إجراءً مناسبًا للتخفيف .
في مثال آخر، ظهر التصيد على نطاق فرعي لنطاق تجاري شرعي قائم. تعليق النطاق بالكامل كان سيعطل أيضًا المواقع الإلكترونية والمراسلات التجارية المشروعة، لذا اعتُبرت المعالجة مع المُسجِّل الشرعي أكثر تناسبًا. (icann.org)
القاعدة العملية هي:
الشكوى لا تعادل التعليق التلقائي.
ولكن:
إساءة استخدام DNS المؤكدة والقابلة للتنفيذ تتطلب تخفيفًا مناسبًا.
ما الذي يُعتبر أدلة قابلة للتنفيذ على التصيد؟
تصف ICANN الأدلة بأنها قابلة للتنفيذ عندما تكون المعلومات المتاحة بشكل معقول للمُسجِّل كافية لاتخاذ قرار معقول بأن النطاق يُستخدم لإساءة استخدام DNS. (icann.org)
بالنسبة لتقرير التصيد، قد تشمل الأدلة المفيدة ما يلي:
- اسم النطاق المسيء؛
- رابط التصيد الكامل؛
- لقطات شاشة لصفحة التصيد؛
- الشركة أو الخدمة الشرعية التي يتم انتحال صفتها؛
- رسالة التصيد أو الرسالة النصية عند الاقتضاء؛
- ترويسات البريد الإلكتروني الكاملة عند الاقتضاء؛
- الطوابع الزمنية؛
- معلومات تظهر كيفية إعادة إنتاج المحتوى الخبيث؛
- أدلة تقنية أو سياقية أخرى تدعم الادعاء.
على سبيل المثال، قول:
«example.com يقوم بالتصيد»
يوفر القليل جدًا من المعلومات.
تقديم:
رابط URL الكامل + لقطة شاشة + العلامة التجارية المستهدفة + رسالة التصيد + طابع زمني
يمنح المُسجِّل معلومات أكثر بكثير للتحقق .
تنشر NiceNIC الأدلة المفيدة عمومًا لفئات الإساءة المختلفة على صفحة الإبلاغ عن إساءة استخدام النطاقات.
ما مدى سرعة استجابة المُسجِّل لشكوى التصيد؟
لا توجد قاعدة ICANN عالمية تنص على وجوب حل كل شكوى تصيد عادية بالكامل خلال 24 ساعة.
هذا فهم خاطئ شائع.
بالنسبة لتقارير الإساءة العامة، يتطلب RAA القسم 3.18.1 ما يلي:
تحقيق واستجابة معقولان وسريعان.
عند وجود أدلة قابلة للتنفيذ على إساءة استخدام DNS، يتطلب القسم 3.18.2 ما يلي:
تخفيف مناسب على وجه السرعة. (itp.cdn.icann.org)
الوقت المحدد قد يعتمد على الظروف.
حملة تصيد واضحة تسبب ضررًا وشيكًا قد تبرر تدخلًا أسرع من حالة معقدة تقنيًا تتضمن نطاقًا شرعيًا مخترقًا.
تصف أمثلة الامتثال الخاصة بـ ICANN فترات تحقيق وتخفيف مختلفة اعتمادًا على وقائع القضية. (icann.org)
متطلب 24 ساعة المنفصل ينطبق على التقارير الموثقة جيدًا عن الأنشطة غير القانونية المرسلة عبر القناة المخصصة للمُسجِّل لجهات إنفاذ القانون ووكالات حماية المستهلك وبعض السلطات الحكومية. (itp.cdn.icann.org)
لا ينبغي الخلط بين ذلك وبين موعد نهائي عالمي يبلغ 24 ساعة لكل شكوى إساءة عادية.
ما الفرق بين فحص نطاق مرتبط وتعليقه؟
هذا التمييز أساسي في النقاش الحالي حول فحص النطاقات المرتبطة.
فحص النطاق لا يعني تعليق ذلك النطاق.
قد يبحث التحقيق عن مؤشرات على أن نطاقات متعددة مرتبطة بنفس النشاط الضار .
ولكن الارتباط وحده لا ينبغي أن يعامل تلقائيًا كدليل على الإساءة.
على سبيل المثال، قد يتشارك نطاقان في ما يلي:
- حساب عميل؛
- معلومات المُسجِّل؛
- البنية التحتية؛
- خوادم الأسماء؛
- معلومات الدفع؛
- إشارات أخرى على مستوى الحساب.
بعض هذه العلاقات قد تكون ذات مغزى.
أخرى قد يكون لها تفسيرات بريئة.
أثارت التعليقات العامة المقدمة إلى ICANN بالفعل مخاوف بشأن الإفراط في الربط والنتائج الإيجابية الكاذبة، مشيرة إلى أن معلومات التسجيل المشتركة أو المؤشرات الأخرى لا تثبت بالضرورة سيطرة مشتركة أو نشاطًا ضارًا. (icann.org)
لذا فإن التمييز المفيد هو :
الارتباط يمكن أن يبرر التحقيق.
لا ينبغي أن يساوي تلقائيًا :
الارتباط يثبت الإساءة.
إذا تم استخدام نطاق واحد للتصيد، فهل سيقوم المُسجِّل بفحص نطاقاتي الأخرى؟
في ظل الإطار التعاقدي العام ICANN الحالي، ليس بالضرورة.
قد يختار المُسجِّل بالفعل التحقيق في النطاقات المرتبطة عندما تشير المعلومات المتاحة إلى حملة أوسع.
ومع ذلك، لا يوجد حاليًا متطلب تعاقدي عام يلزم كل مُسجِّل بإجراء فحص للنطاقات المرتبطة على مستوى الحساب عندما يتم تأكيد أن نطاقًا واحدًا ضار.
هذه هي بالضبط الفجوة التي يدرسها DNS Abuse Mitigation PDP 1. (gnso.icann.org)
إذا أصبحت السياسة المقترحة في النهاية سياسة توافقية، فقد يكون لدى المُسجِّلين التزام أكثر وضوحًا بالتحقيق في النطاقات المرتبطة عند استيفاء المحفز المطلوب .
التفاصيل لا تزال مهمة.
الأسئلة قيد الدراسة تشمل:
- ما الذي يحفز إجراء فحص النطاقات المرتبطة؛
- ما الذي يجعل النطاقات مرتبطة بشكل كافٍ؛
- ما هي المعلومات التي يمكن للمُسجِّلين استخدامها؛
- كيف ينبغي إجراء التحقيقات؛
- ما هي الضمانات المطلوبة؛
- كيف ينبغي حماية الخصوصية؛
- كيف ينبغي تجنب النتائج الإيجابية الكاذبة؛
- متى يكون اتخاذ إجراء ضد نطاق آخر مبررًا.
ماذا لو كان النطاق المُبلَّغ عنه مخترقًا بدلاً من تسجيله للتصيد؟
هذا واحد من أهم التمييزات في التعامل مع إساءة استخدام DNS .
يمكن اختراق نطاق تجاري شرعي دون أن يشارك مالك النطاق عن علم في التصيد.
على سبيل المثال:
قد تشغل شركة ما:
company.com
يخترق المهاجم الموقع الإلكتروني وينشئ :
company.com/login-update
أو نطاقًا فرعيًا خبيثًا.
التصيد حقيقي.
ولكن تعليق company.com قد يؤدي أيضًا إلى إيقاف :
- الموقع الإلكتروني الشرعي للشركة؛
- البريد الإلكتروني المؤسسي؛
- خدمات العملاء؛
- نطاقات فرعية غير ذات صلة.
تعترف إرشادات الامتثال الخاصة بـ ICANN صراحةً بمشكلة الضرر الجانبي هذه.
في حالة النطاق المخترق، قد تشمل التخفيفات المناسبة إخطار المُسجِّل أو مزود الاستضافة وطلب إزالة محتوى التصيد بدلاً من تعليق النطاق بالكامل فورًا. (icann.org)
لهذا السبب تحتاج عملية الإساءة الجيدة إلى كليهما:
تخفيف فعال
و
إجراء متناسب.
توضح NiceNIC عملية حالة القضية ومراجعة الأدلة على صفحة التعامل مع إساءة استخدام النطاقات والشفافية.
كيف يمكنني الإبلاغ عن نطاق تصيد إلى مُسجِّل؟
يجب أن يساعد تقرير التصيد المفيد المُسجِّل على إعادة إنتاج المشكلة والتحقق منها.
قبل تقديم التقرير، اجمع:
1. اسم النطاق
حدد النطاق المعني.
2. رابط الـURL الدقيق للتصيد
لا تقدم الصفحة الرئيسية فقط إذا كان محتوى التصيد يظهر في مسار محدد أو نطاق فرعي.
3. لقطة شاشة
التقط الصفحة التي تعرض انتحال الهوية أو طلب البيانات.
4. الهدف الشرعي المُنتحَل
حدد البنك أو البورصة أو الشركة أو الخدمة الحكومية أو أي منظمة أخرى يتم انتحال صفتها.
5. رسالة التصيد
إذا وصل الرابط عبر البريد الإلكتروني أو الرسائل النصية أو قناة أخرى، فقم بتضمين الرسالة ذات الصلة والترويسات عند التوفر.
6. الوقت والتفاصيل الفنية
قد تساعد الطوابع الزمنية ومعلومات المتصفح ومعلومات الموقع وتفاصيل أخرى إذا كانت الصفحة الخبيثة تستخدم الإخفاء أو الاستهداف الجغرافي.
إذا كان النطاق مُدارًا من قبل NiceNIC، فاستخدم نموذج NiceNIC الرسمي للإبلاغ عن إساءة استخدام النطاق.
تُنشر مبادئ المعالجة الرسمية وإجراءات الإبلاغ الخاصة بـ NiceNIC في سياسة الإبلاغ عن الإساءة والتعامل معها.
ماذا يمكنني أن أفعل إذا لم يتصرف المُسجِّل بناءً على تقرير التصيد؟
أولاً، تأكد من أن التقرير يحتوي على أدلة محددة كافية ليتمكن المُسجِّل من التحقيق.
إذا كانت المعلومات مفقودة، فقدمها عبر نفس حالة الإساءة بدلاً من فتح شكاوى مكررة.
بالنسبة لنطاق gTLD، إذا مرت فترة زمنية معقولة وكنت تعتقد أن المُسجِّل المُدارة لديه لم يف بالتزاماته بموجب القسم 3.18 من RAA، توفر ICANN عملية تقديم شكاوى الامتثال التعاقدي. وتذكر ICANN أنه يمكن للمُبلِّغين تصعيد المسألة بعد تقديم شكوى إساءة إلى المُسجِّل والسماح بوقت معقول للمعالجة. (icann.org)
قد يقوم فريق ICANN للامتثال التعاقدي بعد ذلك بتقييم :
- الأدلة المقدمة من المُبلِّغ؛
- المعلومات المتاحة للمُسجِّل؛
- تحقيق المُسجِّل؛
- ما إذا كانت الأدلة القابلة للتنفيذ موجودة؛
- ما هي إجراءات التخفيف التي تم اتخاذها؛
- متى تم اتخاذ الإجراء؛
- لماذا اعتُبر الإجراء المختار مناسبًا ومتناسبًا. (icann.org)
هل يعني فحص النطاقات المرتبطة أنه يمكن تعليق كل نطاق في الحساب؟
لا.
سيكون هذا تفسيرًا واسعًا بشكل مفرط للاقتراح الحالي.
النقاش السياساتي يدور حول التحقيق في النطاقات المرتبطة بعد وجود أدلة قابلة للتنفيذ على نطاق محفِّز.
وهذا لا يعني:
نطاق واحد مسيء = تعليق تلقائي للحساب بالكامل.
العمل السياساتي الحالي يدرس على وجه التحديد التناسب والخصوصية والأدلة والأضرار الجانبية المحتملة. (icann.org)
هذا التمييز مهم بشكل خاص لـ:
- مستثمري النطاقات ذوي المحافظ الكبيرة؛
- مزودي الاستضافة؛
- الموزعين؛
- الوكالات التي تدير نطاقات العملاء؛
- الشركات التي لديها تسجيلات دفاعية عديدة؛
- الحسابات التي تحتوي على نطاقات نشطة ومتوقفة معًا.
هل ينطبق اقتراح فحص النطاقات المرتبطة على نطاقات ccTLD؟
يتم تطوير DNS Abuse Mitigation PDP 1 الحالي من خلال GNSO التابعة لـICANN ويتعلق بالتزامات المُسجِّلين المعتمدين من ICANN بموجب اتفاقية اعتماد المُسجِّلين.
لذا لا ينبغي تفسيره على أنه ينشئ تلقائيًا نفس القواعد لكل نطاق من نطاقات TLD الخاصة بالدول.
نطاقات ccTLD مثل .uk و.de و.ca أو .in قد تعمل بموجب سياسات سجل خاصة بها ومتطلبات وطنية وترتيبات مع المُسجِّلين.
تحقق دائمًا من القواعد المطبقة على TLD المحدد.
ما الذي يجب أن يعرفه مالكو النطاقات والموزعون عن فحوصات النطاقات المرتبطة؟
أهم النقاط بسيطة:
- فحوصات النطاقات المرتبطة مقترحة حاليًا وليست بعد متطلبًا نهائيًا جديدًا لسياسة توافقية.
- فترة التعليق العام لدى ICANN تعمل حاليًا حتى 28 سبتمبر 2026.
- للمُسجِّلين بالفعل التزامات قابلة للتنفيذ لاستلام تقارير الإساءة والتحقيق فيها والاستجابة لها.
- التصيد معرّف صراحةً كإساءة استخدام DNS بموجب RAA.
- الشكوى وحدها لا تتطلب تلقائيًا التعليق.
- الأدلة القابلة للتنفيذ تتطلب تخفيفًا سريعًا ومناسبًا.
- النطاق الشرعي المخترق قد يتطلب استجابة مختلفة عن نطاق التصيد المسجل بشكل ضار.
- فحص نطاق مرتبط ليس مثل تحديد أنه مسيء.
- السياسة المقترحة تهدف إلى المساعدة في تحديد الحملات الضارة الأكبر دون معاملة الارتباط وحده كدليل على الإساءة.
بالنسبة لعملاء وموزعي NiceNIC، يمكن مراجعة حالة القضية الحالية وتأثير النطاق وتقدم المراجعة والخطوات التالية المتاحة عبر صفحة NiceNIC للتعامل مع إساءة استخدام النطاقات والشفافية.
لأي شخص يقيّم موارد NiceNIC الأوسع المتعلقة بالاعتماد والأمن والامتثال والسياسات العامة، تفضل بزيارة مركز الثقة NiceNIC Trust Center.
ما هو الخلاصة بشأن فحوصات النطاقات المرتبطة وشكاوى التصيد؟
اليوم، لدى المُسجِّلين المعتمدين من ICANN مسؤوليات واضحة عندما يتلقون تقارير تصيد موثوقة:
استلام التقرير ← تأكيد الاستلام ← التحقيق بشكل معقول وسريع ← تحديد ما إذا كانت الأدلة القابلة للتنفيذ موجودة ← اتخاذ التخفيف المناسب عند الحاجة ← توثيق التعامل مع القضية.
ما قد يتغير هو ما يحدث بعد ذلك.
تدرس ICANN حاليًا ما إذا كان تأكيد إساءة استخدام DNS على نطاق واحد يجب أن يؤدي إلى تحقيق إلزامي في النطاقات الأخرى المرتبطة بنفس حساب العميل أو المُسجِّل.
قد يساعد ذلك المُسجِّلين في تعطيل حملات التصيد المنسقة مبكرًا.
ولكن الضمانات لا تقل أهمية .
نطاق واحد يمكن أن يبرر النظر عن كثب. لا ينبغي أن يجعل تلقائيًا كل نطاق مرتبط مذنبًا.
نتيجة عملية السياسات الحالية لدى ICANN ستحدد كيفية تحقيق هذا التوازن في النهاية .
