إرشادات الشبكة الفرعية لعميل 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 مع نطاق غير صفري.
إرشادات لخوادم الأسماء الموثوقة
جميع خوادم الأسماء الموثوق بها للمنطقة التي تم تفعيل ميزة ECS فيها يجب تفعيل
ECS للمنطقة.
حتى في حال لم ينفِّذ خادم أسماء واحد تطبيق ECS أو تفعيله للمنطقة، سيصبح سريعًا مصدر معظم البيانات المخزَّنة مؤقتًا.
ونظرًا لأن ردودها لها نطاق عام، يتم استخدامها
(حتى تنتهي صلاحية مدة البقاء)
كاستجابة لطلبات البحث لجميع الاسم نفسه
(بغض النظر عن الشبكة الفرعية للعميل).
الردود من الخوادم التي تُنفِّذ خدمة ECS وتفعِّلها فقط لطلبات البحث من العملاء ضمن النطاق المحدّد،
لأنّها تقل احتمالات استخدامها مقارنةً باستجابات النطاق العام.
ترسل خوادم الأسماء الموثوقة التي تنفذ ECS MUST 2 لجميع المناطق التي يتم عرضها من
عنوان IP أو اسم مضيف NS، حتى في المناطق التي لا يتم تفعيل ECS فيها.
يرصد نظام أسماء النطاقات العام من Google تلقائيًا دعم ECS من خلال عنوان IP بدلاً من
اسم مضيف خادم الأسماء أو منطقة نظام أسماء النطاقات لأن عدد العناوين أصغر من عدد أسماء مضيفي خادم الأسماء وأقل بكثير من عدد مناطق نظام أسماء النطاقات.
إذا كان خادم الأسماء المفوّض لا يرسل دائمًا ردود ECS إلى طلبات بحث ECS (حتى بالنسبة إلى المناطق التي لم يتم تفعيل ECS)،
قد يتوقف نظام أسماء النطاقات العام من Google عن إرسال طلبات بحث ECS إليه.
يجب أن تردّ خوادم الأسماء الموثوقة التي تنفذ ECS على جميع طلبات ECS التي تحتوي على استجابات ECS، بما في ذلك الردود السلبية واستجابات الإحالة.
تنطبق هنا نفس المشاكل المتعلقة بالاكتشاف التلقائي لدعم ECS.
الردود السلبية (NXDOMAIN وNODATA) SHOULD 3
بالإضافة إلى NXDOMAIN وNODATA (NOERROR مع قسم إجابة فارغ)،
يجب أن تتضمن استجابات الأخطاء الأخرى لطلبات ECS (خاصة SERVFAIL وREFUSED)
خيار ECS مطابقًا مع نطاق /0 عمومي.
إذا حاول خادم أسماء موثوق به التخلص من التحميل من هجوم DoS، يمكن أن يعرض خادم SERVFAIL بدون بيانات ECS،
ويؤدي ذلك بشكل متكرر إلى إيقاف نظام أسماء النطاقات العام من Google عن إرسال طلبات البحث باستخدام ECS
(قد يؤدي ذلك إلى تقليل عدد طلبات البحث المشروعة التي يرسلها،
ولكنه لن يؤثر في طلبات هجوم النطاقات الفرعية العشوائية).
وقد يؤدي تقليل الحمل على طلبات البحث الشرعية أثناء هجوم DoS إلى تحسين معدل نجاح طلبات البحث المشروعة أو عدم تحسينها (على الرغم من أنه يمكن عرض الردود من ذاكرة التخزين المؤقت لجميع البرامج).
تتمثّل منهجية أكثر فعالية للتخفيف من حِمل البيانات في إرسال كل الردود
مع نطاق عالمي /0 بحيث تستمر خدمة "نظام أسماء النطاقات العام من Google" في إرسال
طلبات ECS.
ويسمح ذلك لخدمة "نظام أسماء النطاقات" من Google بعرض الردود التي تم تحديد موقعها الجغرافي بعد وقت قصير من الهجوم،
لأنه لا حاجة إلى إعادة رصد دعم ECS،
فقط لإعادة طلب البحث بعد انتهاء صلاحية مدة البقاء (TTL) الخاصة بالاستجابة العامة.
يجب أن تحتوي ردود الإحالة (التفويض) أيضًا على بيانات ECS مطابقة
ويجب أن تستخدم4 أداة الحل's عنوان IP للعميل، وليس بيانات ECS.
يجب أن تتضمن خوادم الأسماء الموثوق بها التي تنفذ ECS خيار مطابقة ECS
في الردود على جميع أنواع طلبات البحث المستلمة مع خيار ECS.
ليس من الجيد الاستجابة لطلبات بحث عنوان IPv4 (A) مع بيانات ECS، لأن الردود على A أو AAAA أو PTR أو MX أو أي نوع طلب بحث آخر يجب أن تحتوي على بيانات ECS أو برامج تعيين يمكن أن تؤدي إلى خفض الاستجابة كاحتمال تزييفها، وقد يتوقف نظام أسماء النطاقات العام من Google عن إرسال طلبات البحث مع بيانات ECS.
وعلى وجه الخصوص، يجب أن تستخدم استجابات ECS لطلبات بحث SOA وNS وDS دائمًا نطاق /0 عام لـ تخزين مؤقت أفضل وعرض متسق للتفويض
(يُسمح بالردود المستندة إلى الموقع الجغرافي على طلبات بحث A/AAAA لأسماء مضيفات الأسماء.)
يجب ألا تستخدم الردود على أي نوع من طلبات البحث (مثل TXT وPTR وغيرها) التي لا تتغيّر استنادًا إلى بيانات ECS نطاقًا مساويًا لطول بادئة المصدر، كما يجب أن تستخدم نطاقًا /0 عموميًا لتحسين التخزين المؤقت وتقليل حمل طلبات البحث.
لا تتضمن خوادم الأسماء الموثوقة التي تعرض استجابات CNAME التي تم تفعيل خدمة ECS
SHOULD 5 6
قد تحتوي بيانات ECS على عناوين IPv6 حتى لخوادم الأسماء IPv4 فقط
(والعكس صحيح، على الرغم من أن خوادم الأسماء IPv6 فقط نادرة).
ملاحظة مهمة: إن عدم عرض نطاق IPv6 ECS صالح هو السبب الأكثر شيوعًا وراء عدم حصول خوادم الأسماء الموثوقة على بيانات ECS من نظام أسماء النطاقات العام من Google. خوادم الأسماء الموثوقة التي تعرض استجابات ECS المفعَّلة
يجب ألا 7
إذا طلب عميل برنامج تعيين متكرّر مُفعّل من ECS بالترتيب أعلاه، قد يحصل كلا الطلبَين على الاستجابة (أ)، لأنّ نطاق الاستجابة المخزّنة مؤقتًا (أ) يتضمن نطاق بادئة طلب البحث الثاني.
حتى إذا تم إجراء طلبات البحث بالترتيب العكسي، وتمت إعادة توجيه كلا طلبَي البحث إلى خوادم الأسماء الموثوق بها، قد تنتهي صلاحية الردود المخزَّنة مؤقتًا في أوقات مختلفة، وبالتالي قد تنتهي صلاحية طلبات البحث اللاحقة لبرنامج التعيين المتكرر في البادئة المتداخلة، ويمكن أن يحصل 198.51.100/24 على الاستجابة (أ) أو (ب).
عند تنفيذ دعم ECS للمرة الأولى على خوادم الأسماء،
استخدِم عناوين IP الجديدة لخوادم الأسماء التي تعرض هذه المناطق المفعّلة من ECS.
عندما تبدأ خوادم الأسماء الموثوق بها التي نفّذت ECS ولكن عرضت
نتائج النطاق الشامل في عرض إجابات مفعّلة لخدمة ECS لمنطقة معيّنة،
يبدأ نظام أسماء النطاقات من Google العلني في عرض الردود المستندة إلى الموقع الجغرافي إلى طلبات البحث، وذلك قريبًا مثل انتهاء صلاحية TTL من الردود السابقة على النطاق العالمي.
نادرًا جدًا ما تجرّب طلبات ECS
لعنوان IP (أو اسم مضيف خادم الأسماء) الاكتشاف التلقائي لنظام أسماء النطاقات العام من Google.
يتم اكتشاف عمليات تنفيذ ECS الجديدة على عناوين IP هذه (أو أسماء المضيفين NS) تلقائيًا ببطء شديد، أو لا يتم عرضها على الإطلاق.
تأكّد من أن اتصالات الشبكة موثوقة ومن أن أي حد لمعدّل الاستجابة تم ضبطه على مستوى كافٍ بحيث لا تتجاهل خوادم الأسماء طلبات البحث (أو أسوأ من ذلك، عليك الاستجابة بالأخطاء التي لا تحتوي على خيار ECS المطابق).
بالنسبة إلى خوادم الأسماء التي تنفذ حدًا لمعدّل الاستجابة في طلبات بحث ECS، أفضل إجابة هي NODATA مع ضبط علامة الاقتطاع (TC)،
التي تحتوي على قسم سؤال مطابق فقط وخيار ECS مطابق.
أرسِل ردودًا في الوقت المناسب على جميع طلبات البحث (من الأفضل أن تكون في غضون ثانية واحدة).
لن يعمل استخدام خدمات البحث عن عنوان IP الجغرافي عند الطلب لطلبات ECS بشكل موثوق، حيث من غير المرجّح أن يكون وقت الاستجابة التراكمي لطلب البحث لنظام أسماء النطاقات وخدمة الموقع الجغرافي على الإنترنت خلال ثانية واحدة.
يرصد الاكتشاف التلقائي لنظام أسماء النطاقات العام من Google لدعم ECS الردود المُتأخرة كإشارة إلى دعم ECS الضعيف أو غير المكتمل، ويقلل من احتمال إرسال طلبات البحث المستقبلية عن طريق ECS.
في حال تأخُّر ردود كافية، سيتوقّف عن إرسال طلبات ECS.
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.
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.
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.
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.
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.
وجدير بالذكر أن استخدام نطاق النطاق النهائي في سلسلة CNAME غير مؤذٍ في إلغاء الربط،
لأنه يتم نشره عادةً كحل بديل أو إعادة توجيه،
حيث يكون جميع العملاء على الشبكة الفرعية نفسها ويحصلون على الاستجابة نفسها.
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:
Deaggregate the shorter prefix response into multiple longer
prefix responses, or
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.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0 . للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers . إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2022-09-26 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2022-09-26 (حسب التوقيت العالمي المتفَّق عليه)"],[],["Authoritative name servers for ECS-enabled zones must consistently implement ECS, sending ECS responses to all ECS queries, using matching ECS options with the same address, family, and source prefix. Negative, referral, and DoS attack responses should use a global /0 scope. CNAME responses should only include the first CNAME. Responses must not overlap scope prefixes. Use new IPs for new ECS implementations, and maintain network reliability with prompt responses. Longer prefixes within shorter prefixes need to either deaggregated or alert the operator.\n"]]
