إرشادات الشبكة الفرعية لعميل EDNS (ECS)

المقدمة

RFC 7871 – الشبكة الفرعية للعميل في طلبات بحث نظام أسماء النطاقات: تحدد آلية لبرامج التعيين المتكررة مثل نظام أسماء النطاقات العام من Google لإرسال معلومات عنوان IP جزئي للعميل إلى خوادم أسماء نظام أسماء النطاقات الموثوق بها. تستخدم شبكات توصيل المحتوى (CDN) والخدمات الحساسة لوقت الاستجابة هذه لتقديم ردود دقيقة بتحديد الموقع الجغرافي عند الاستجابة لعمليات البحث عن الأسماء التي تأتي من خلال برامج تعيين نظام أسماء النطاقات العامة.

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

وتهدف هذه الإرشادات إلى مساعدة أدوات تنفيذ نظام أسماء النطاقات الموثوق بها وبرامج التشغيل في تجنُّب العديد من الأخطاء الشائعة التي يمكن أن تسبب مشاكل في ECS.

تعريفات المصطلحات

نستخدم المصطلحات التالية لوصف عمليات ECS:

• يطبّق خادم الأسماء (أو يتوافق) ECS في حال الرد على طلبات ECS مع استجابات ECS التي تحتوي على خيارات ECS مطابقة (حتى إذا كانت خيارات ECS لها طول بادئة نطاق /0 عام دائمًا).

  ملاحظة: ردود ECS يجب1 تطابق عنوان ECS طول العائلة والعنوان وبادئة المصدر لطلبات البحث المقابلة. وإذا لم يتم ذلك، لن يتم تنفيذ خدمة ECS بشكل صحيح من قبل خادم الأسماء، وقد لا يرسل نظام أسماء النطاقات العام من Google طلبات ECS إليه.

• zone هي ECS-مفعّلة في حال تلقّيت طلبات ECS من خوادم الأسماء المُرسَلة ببادئة مصدر غير صفرية استجابات ECS مع نطاق غير صفري.

إرشادات لخوادم الأسماء الموثوقة

1. جميع خوادم الأسماء الموثوق بها للمنطقة التي تم تفعيل ميزة ECS فيها يجب تفعيل ECS للمنطقة.

   • حتى في حال لم ينفِّذ خادم أسماء واحد تطبيق ECS أو تفعيله للمنطقة، سيصبح سريعًا مصدر معظم البيانات المخزَّنة مؤقتًا. ونظرًا لأن ردودها لها نطاق عام، يتم استخدامها (حتى تنتهي صلاحية مدة البقاء) كاستجابة لطلبات البحث لجميع الاسم نفسه (بغض النظر عن الشبكة الفرعية للعميل). الردود من الخوادم التي تُنفِّذ خدمة ECS وتفعِّلها فقط لطلبات البحث من العملاء ضمن النطاق المحدّد، لأنّها تقل احتمالات استخدامها مقارنةً باستجابات النطاق العام.

2. ترسل خوادم الأسماء الموثوقة التي تنفذ ECS MUST² استجابات ECS إلى طلبات بحث ECS لجميع المناطق التي يتم عرضها من عنوان IP أو اسم مضيف NS، حتى في المناطق التي لا يتم تفعيل ECS فيها.

   • يرصد نظام أسماء النطاقات العام من Google تلقائيًا دعم ECS من خلال عنوان IP بدلاً من اسم مضيف خادم الأسماء أو منطقة نظام أسماء النطاقات لأن عدد العناوين أصغر من عدد أسماء مضيفي خادم الأسماء وأقل بكثير من عدد مناطق نظام أسماء النطاقات. إذا كان خادم الأسماء المفوّض لا يرسل دائمًا ردود ECS إلى طلبات بحث ECS (حتى بالنسبة إلى المناطق التي لم يتم تفعيل ECS)، قد يتوقف نظام أسماء النطاقات العام من Google عن إرسال طلبات بحث ECS إليه.

3. يجب أن تردّ خوادم الأسماء الموثوقة التي تنفذ ECS على جميع طلبات ECS التي تحتوي على استجابات ECS، بما في ذلك الردود السلبية واستجابات الإحالة.

   • تنطبق هنا نفس المشاكل المتعلقة بالاكتشاف التلقائي لدعم ECS.

   • الردود السلبية (NXDOMAIN وNODATA) SHOULD³ تستخدم نطاق /0 عامًا لتحسين التخزين المؤقت والتوافق مع RFC 7871.

   • بالإضافة إلى NXDOMAIN وNODATA (NOERROR مع قسم إجابة فارغ)، يجب أن تتضمن استجابات الأخطاء الأخرى لطلبات ECS (خاصة SERVFAIL وREFUSED) خيار ECS مطابقًا مع نطاق /0 عمومي.

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

       تتمثّل منهجية أكثر فعالية للتخفيف من حِمل البيانات في إرسال كل الردود مع نطاق عالمي /0 بحيث تستمر خدمة "نظام أسماء النطاقات العام من Google" في إرسال طلبات ECS. ويسمح ذلك لخدمة "نظام أسماء النطاقات" من Google بعرض الردود التي تم تحديد موقعها الجغرافي بعد وقت قصير من الهجوم، لأنه لا حاجة إلى إعادة رصد دعم ECS، فقط لإعادة طلب البحث بعد انتهاء صلاحية مدة البقاء (TTL) الخاصة بالاستجابة العامة.

   • يجب أن تحتوي ردود الإحالة (التفويض) أيضًا على بيانات ECS مطابقة ويجب أن تستخدم⁴ نطاق /0 عمومي. تجدر الإشارة إلى أنه لا تتم إعادة توجيه ردود التفويض مطلقًا إلى البرامج التي تظهر عناوينها في بيانات ECS، لذا يجب اختيار أي سجلات NS أو A أو AAAA للمواقع الجغرافية من خلال أداة الحل's عنوان IP للعميل، وليس بيانات ECS.

4. يجب أن تتضمن خوادم الأسماء الموثوق بها التي تنفذ ECS خيار مطابقة ECS في الردود على جميع أنواع طلبات البحث المستلمة مع خيار ECS. ليس من الجيد الاستجابة لطلبات بحث عنوان IPv4 (A) مع بيانات ECS، لأن الردود على A أو AAAA أو PTR أو MX أو أي نوع طلب بحث آخر يجب أن تحتوي على بيانات ECS أو برامج تعيين يمكن أن تؤدي إلى خفض الاستجابة كاحتمال تزييفها، وقد يتوقف نظام أسماء النطاقات العام من Google عن إرسال طلبات البحث مع بيانات ECS.

   وعلى وجه الخصوص، يجب أن تستخدم استجابات ECS لطلبات بحث SOA وNS وDS دائمًا نطاق /0 عام لـ تخزين مؤقت أفضل وعرض متسق للتفويض (يُسمح بالردود المستندة إلى الموقع الجغرافي على طلبات بحث A/AAAA لأسماء مضيفات الأسماء.) يجب ألا تستخدم الردود على أي نوع من طلبات البحث (مثل TXT وPTR وغيرها) التي لا تتغيّر استنادًا إلى بيانات ECS نطاقًا مساويًا لطول بادئة المصدر، كما يجب أن تستخدم نطاقًا /0 عموميًا لتحسين التخزين المؤقت وتقليل حمل طلبات البحث.

5. لا تتضمن خوادم الأسماء الموثوقة التي تعرض استجابات CNAME التي تم تفعيل خدمة ECS SHOULD⁵ إلا أول CNAME في السلسلة، ويجب أن يكون الهدف النهائي لسلسلة CNAME مفعَّلاً ECS بطول بادئة النطاق نفسها. بسبب الالتباس في مواصفات ECS، قد تعرض بعض برامج التعيين المتكرر ((بتحديد غير محدد⁶) استجابة تتضمّن نطاق النطاق النهائي غير CNAME (/0 إذا لم يكن ECS مفعّلاً).

6. قد تحتوي بيانات ECS على عناوين IPv6 حتى لخوادم الأسماء IPv4 فقط (والعكس صحيح، على الرغم من أن خوادم الأسماء IPv6 فقط نادرة).

   ملاحظة مهمة: إن عدم عرض نطاق IPv6 ECS صالح هو السبب الأكثر شيوعًا وراء عدم حصول خوادم الأسماء الموثوقة على بيانات ECS من نظام أسماء النطاقات العام من Google.

   • يجب أن تردّ خوادم الأسماء ببيانات خيارات ECS الصالحة (النطاق 0 حسنًا، ولكن يجب أن يتطابق عنوان المصدر مع طول البادئة).

   • يمكن تفعيل خدمة ECS لمنطقة منفصلة لعناوين IPv4 وIPv6.

7. خوادم الأسماء الموثوقة التي تعرض استجابات ECS المفعَّلة يجب ألا⁷ تتداخل بادئات النطاق المتداخلة في إجاباتها. في ما يلي مثال على بادئات النطاق المتداخلة:

   • طلب البحث ببادئة المصدر 198.18.0.0/15: الاستجابة "أ" ببادئة النطاق 198.0.0.0/8

   • طلب البحث ببادئة المصدر 198.51.100/24: الاستجابة "ب" ببادئة النطاق 198.51.0.0/16

   إذا طلب عميل برنامج تعيين متكرّر مُفعّل من ECS بالترتيب أعلاه، قد يحصل كلا الطلبَين على الاستجابة (أ)، لأنّ نطاق الاستجابة المخزّنة مؤقتًا (أ) يتضمن نطاق بادئة طلب البحث الثاني. حتى إذا تم إجراء طلبات البحث بالترتيب العكسي، وتمت إعادة توجيه كلا طلبَي البحث إلى خوادم الأسماء الموثوق بها، قد تنتهي صلاحية الردود المخزَّنة مؤقتًا في أوقات مختلفة، وبالتالي قد تنتهي صلاحية طلبات البحث اللاحقة لبرنامج التعيين المتكرر في البادئة المتداخلة، ويمكن أن يحصل 198.51.100/24 على الاستجابة (أ) أو (ب).

8. عند تنفيذ دعم ECS للمرة الأولى على خوادم الأسماء، استخدِم عناوين IP الجديدة لخوادم الأسماء التي تعرض هذه المناطق المفعّلة من ECS.

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

   • نادرًا جدًا ما تجرّب طلبات ECS لعنوان IP (أو اسم مضيف خادم الأسماء) الاكتشاف التلقائي لنظام أسماء النطاقات العام من Google. يتم اكتشاف عمليات تنفيذ ECS الجديدة على عناوين IP هذه (أو أسماء المضيفين NS) تلقائيًا ببطء شديد، أو لا يتم عرضها على الإطلاق.

9. تأكّد من أن اتصالات الشبكة موثوقة ومن أن أي حد لمعدّل الاستجابة تم ضبطه على مستوى كافٍ بحيث لا تتجاهل خوادم الأسماء طلبات البحث (أو أسوأ من ذلك، عليك الاستجابة بالأخطاء التي لا تحتوي على خيار ECS المطابق).

   • بالنسبة إلى خوادم الأسماء التي تنفذ حدًا لمعدّل الاستجابة في طلبات بحث ECS، أفضل إجابة هي NODATA مع ضبط علامة الاقتطاع (TC)، التي تحتوي على قسم سؤال مطابق فقط وخيار ECS مطابق.

10. أرسِل ردودًا في الوقت المناسب على جميع طلبات البحث (من الأفضل أن تكون في غضون ثانية واحدة).

    • لن يعمل استخدام خدمات البحث عن عنوان IP الجغرافي عند الطلب لطلبات ECS بشكل موثوق، حيث من غير المرجّح أن يكون وقت الاستجابة التراكمي لطلب البحث لنظام أسماء النطاقات وخدمة الموقع الجغرافي على الإنترنت خلال ثانية واحدة. يرصد الاكتشاف التلقائي لنظام أسماء النطاقات العام من Google لدعم ECS الردود المُتأخرة كإشارة إلى دعم ECS الضعيف أو غير المكتمل، ويقلل من احتمال إرسال طلبات البحث المستقبلية عن طريق ECS. في حال تأخُّر ردود كافية، سيتوقّف عن إرسال طلبات ECS.

مراجع RFC 7871 وحواشي سفلية أخرى

¹ https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

² https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

³ https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

⁴ https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

⁵ https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

⁶ https://unbound.net/pipermail/unbound-users/2015-May/003875.html

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

⁷ https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

...

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.