الوفود عرجاء في AFRINIC عكس DNS

مقترح

1. ملخص للمشكلة التي يعالجها هذا الاقتراح

1.1 .الخلفية: ما هو "تفرج عرجاء"؟

في DNS ، التفويض العرجاء هو نوع من خطأ التكوين الخاطئ لـ DNS الذي يحدث عندما لا يقوم خادم الأسماء المعين كخادم موثوق لاسم المجال بإرجاع بيانات موثوقة لهذا الاسم ، عند الاستعلام عنها. على سبيل المثال ، إذا تم تفويض أحد خوادم الأسماء بمسؤولية توفير خدمة اسم لمنطقة (عبر سجلات NS) ولم يكن يفعل ذلك بالفعل ، أي أن خادم الأسماء لم يتم إعداده كخادم أساسي أو ثانوي ، أو أنه لا يستجيب ، إذن سجل NS يعتبر "أعرج". (RFC1912 [2]).

 

1.2. تأثير وفود عرجاء في DNS العالمي

في مناطق in-addr.arpa و ip6.arpa ، وفقًا لما هو مطبق على هذه السياسة ، تعتبر سجلات DNS التي تم اعتبارها سجلات NS (كما في المثال أعلاه) ، تفويضًا للسلطة بشكل أكبر في سلسلة السلطة. نظرًا لأن هذا التفويض ينتج عنه ردود عرجاء ، فإن المشكلة الأكثر وضوحًا هي الفشل التام للمنطقة الفرعية .ARPA المحددة التي يتم تفويضها إليها. يشبه هذا عدم وجود أي تفويض في مكانه على الإطلاق: لا يمكن العثور على المجموعة الفرعية لسجلات .ARPA ، وبالتالي ستفشل عمليات البحث العكسي عن DNS في هذه المجموعة من موارد عنوان IP. مع عدم وجود تفويض في المكان ، يكون الفشل فوريًا ونهائيًا. سيحصل عميل الاستعلام عن منطقة معينة على استجابة سلبية من خادم أسماء المنطقة الأصل ، ولن يقوم بأي عمليات بحث إضافية.

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

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

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

 

2. ملخص عن كيفية معالجة هذا الاقتراح للمشكلة

2.1. ملخص

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

 

2.2.نطاق السياسة

تهدف هذه السياسة إلى أن تنطبق فقط على مناطق DNS تحت in-addr.arpa و ip6.arpa التي تديرها AFRINIC. يجب إجراء عمليات التحقق لكل سجل NS على أنه مصدره كائنات "المجال" في AFRINIC WHOIS

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

يجب ألا تراقب هذه السياسة أو تفكر في تفويضات DNS العكسية للأقلية RIR موارد عنوان IP أو موارد عنوان IP القديمة.

 

3. الاقتراح

3.1. تفاصيل العملية

سيتم إضافة النص التالي في دليل السياسة الموحدة:

10.7 عملية تفويض عرجاء

10.7.1 الرصد / الفحص

جميع الكائنات "المجال" في AFRINIC WHOIS يجب فحص قاعدة البيانات بشكل دوري ، ويتم استخراج كافة سمات "nserver" للتدقيق. يجب التحقق من كل "خادم" موجود حتى:

• الرد على استفسارات DNS.
• يمكنك الرد باستخدام سجل SOA صالح للنطاق المرتبط به في WHOIS

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

 

10.7.2 الإخطار

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

يجب تجربة جميع جهات الاتصال "admin-c" و "tech-c" و "zone-c" بشكل متوازٍ.

بالإضافة إلى ذلك ، قد يتم استخراج معلومات الاتصال من السمات "org" و / أو "mnt-by" المرتبطة عند الاقتضاء.

يجب أيضًا إعادة تجربة اتصالات الإشعارات التي لم تتم الإجابة عليها أكثر من مرة قبل الانتقال إلى إجراءات أخرى.

يجب توحيد وتيرة الاتصالات وطريقة الاتصال وعدد المحاولات وتوثيقها علنًا.

 

10.7.3 إزالة التفويض

بمجرد أن يتم تحديد خادم أسماء محدد على أنه عرجاء لـ "مجال" DNS معين ، وقد بذلت محاولات معقولة للاتصال بشخص مسؤول ، يجب إزالة خادم الأسماء من "مجال" DNS المحدد.

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

فقط تلك الخوادم التي تم تمييزها على أنها أعرج يجب إزالتها من مجال معين. يجب ألا يحتوي المجال على جميع سمات "nserver" التي تمت إزالتها.

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

إذا كان مجال معين لديه كل ما يعرف به خادم الأسماء على أنه عرجاء ، وبالتالي إزالته ، فيجب إزالته أيضًا من قاعدة البيانات ، نظرًا لأن السمة "nserver" إلزامية بالنسبة للكائنات "domain".

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

 

10.7.4 إعادة التثبيت

بمجرد إصلاح خوادم الأسماء ، أو توفر خوادم أسماء بديلة لمنطقة DNS العكسي المعينة ، يضيف الشخص المسؤول (الأشخاص) التفويض إليهم بالطريقة نفسها التي يتم بها تفويض جديد لتعيين IP جديد أو تخصيص.

 

3.2 التأثير التشغيلي المحتمل

سوف ينتج عن تفويض DNS لمنطقة تابعة بواسطة سجلات NS عرجاء في المنطقة الأصل فشل جزئي أو كامل للمنطقة التابعة.

لذلك ، لن يكون لإزالة هذه السجلات العرجاء عند الوالد أي آثار سلبية أخرى على المنطقة الفرعية.

في حالة العرج الجزئي ، حيث لا توجد جميع خوادم الأسماء عرجاء ، سيكون التأثير إيجابياً: إزالة التفويضات الفاشلة لن تؤدي إلى فشل DNS ، وليس جزئية.

 

3.3 نموذج توجيهي لعمليات التنفيذ

يدرك المؤلفون أنه سيكون هناك عمل كبير يتعين القيام به لتنفيذ هذه السياسة. لقد عملوا على مبادئ توجيهية للتنفيذ ، في حالة تمرير السياسة.

يتوفر دليل تشغيلي نموذجي على الإنترنت [9] كدليل إرشادي لموظفي AFRINIC لاستخدامه. نرحب بالإدخال والنص ، ولكن يرجى ملاحظة أن هذا نموذج للتنفيذ وليس جزءًا من السياسة.

 

4. تاريخ المراجعة

2017-03-15: أولاً draft

 

5. المراجع

5.1 سياسات مماثلة في مناطق أخرى

• ARIN: السياسة 2002-1: وفود عرجاء في IN-ADDR.ARPA [4]
• APNIC: prop-038: تعديل سياسة تفويض DNS العرجاء لـ APNIC [5]
• LACNIC: سياسة تفويض عرجاء داخل المنطقة التي تغطيها LACNIC [6]
• RIPE NCC: لا توجد سياسة معروفة في هذا الوقت.

 

5.2 دراسات تكوين DNS الخاطئ

• بعثة عرجاء في قاعدة البيانات AFRINIC: كيف عرجاء هي الوفود العكسي لدينا؟ [7]
• أخطاء تكوين DNS: تأثير أخطاء التكوين على متانة DNS [8]

 

5.3 URI

[1]https://www.rfc-editor.org/rfc/rfc2119.txt

[2]https://www.ietf.org/rfc/rfc1912.txt

[3]https://www.afrinic.net/library/corporate-documents/216-how-to-request-reverse-delegation-in-afrinic-region

[4]https://www.arin.net/policy/proposals/2002_1.html

[5]https://www.apnic.net/community/policy/proposals/prop-038/

[6]http://www.lacnic.net/en/web/lacnic/manual-6

[7]http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations

[8]http://web.cs.ucla.edu/~lixia/papers/09DNSConfig.pdf

[9]https://raw.githubusercontent.com/techdad/afpub-2017-lame-dns/master/sample-implementation/afpub-2017-lame-dns-sample-ops-manual-draft-00.txt

 

5.4 مسرد

• DNS: نظام اسم المجال
• RIR: سجل الإنترنت الإقليمي
• أغلبية RIR: يحمل التخصيص الرئيسي من IANA.
• أقلية RIR: يدير المساحة ضمن تخصيص الأغلبية.
• موارد الإنترنت القديمة: موارد رقم الإنترنت التي تم الحصول عليها قبل أو خارج نظام التسجيل الهرمي الحالي للإنترنت.
• سجل الخدمية: سجل "بداية السلطة" ، على رأس كل منطقة DNS.

 

الموظفين assesment

*** تقييم الموظفين ***

---

 

مقترح	AFPUB-2017-DNS-001-DRAFT-01
العنوان	الوفود عرجاء في AFRINIC عكس DNS
URL	https://afrinic.net/en/community/policy-development/policy-proposals/2067-lame-delegations-in-afrinic-reverse-dns
تقييم	15 مايو 2017

1.0 فهم الموظفين للاقتراح

• يهدف الاقتراح إلى تخفيف أو إزالة عمليات تفويض DNS عرجاء المرتبطة بالموارد الصادرة (أو المدارة إدارياً) من قبل AFRINIC.

• يضع الاقتراح عملية لرصد سجلات NS المسؤولة عن تفويض الأعرج ، ونهج مرحلي لإزالة هذه السجلات من DNS.

• إنه تحديث (أو تحسين) لعملية rDNS الحالية الموضحة في دليل السياسة الموحدة (المادة 10)

2.0 تعليقات الموظفين:

3.0 تعليقات من المستشار القانوني:

• لا شيء لوحظ

 

4.0 التنفيذ:

4.1 الجدول الزمني والأثر

سيتطلب تطوير واختبار (البرامج) قرابة شهرين.

4.2 متطلبات التنفيذ

الإجراءات التالية ضرورية لتنفيذ هذه السياسة كما هو مكتوب:

• تنفيذ الشيكات التلقائية "العرج".
• تحديث قواعد العمل (الداخلية) لتشغيل الاختبارات قبل إنشاء المجال / التحديثات.
• أتمتة الإخطارات المرسلة إلى جهات الاتصال الخاصة بالسجلات المرتبطة بتفويضات عرجاء كما هو محدد في 10.7.2 بالإضافة إلى تقارير تفويض عرج شهرية وتقارير تنظيف تفويض عرجاء نصف سنوي.
• أداة المدقق العرج العامة.
• كائن الأرشفة في WHOIS (هناك حاجة أيضًا إلى تطوير إضافي لعرض الكائنات المؤرشفة بتنسيق MyAFRINIC).
• أتمتة إزالة التفويض عرجاء كما هو محدد في 10.7.3
• أتمتة عمليات إعادة التشغيل كما هو محدد في 10.7.4
• التوثيق (والنشر المطلوب) للعملية التي توضح بالتفصيل كيفية تنفيذ وتيرة / محاولات الاتصال وطريقة (طرق) الاتصال.