رهنمودهای زیرشبکه مشتری EDNS (ECS).

مقدمه

RFC 7871 - زیرشبکه مشتری در پرس و جوهای DNS - مکانیزمی را برای حل‌کننده‌های بازگشتی مانند Google Public DNS تعریف می‌کند تا اطلاعات آدرس IP مشتری جزئی را به سرورهای نام DNS معتبر ارسال کند. شبکه‌های تحویل محتوا (CDN) و سرویس‌های حساس به تأخیر از این برای ارائه پاسخ‌های دقیق در موقعیت جغرافیایی هنگام پاسخ به جستجوهای نام که از طریق حل‌کننده‌های DNS عمومی می‌آیند، استفاده می‌کنند.

RFC ویژگی های ECS را توصیف می کند که سرورهای نام معتبر باید پیاده سازی کنند. اما مجریان همیشه از آن الزامات پیروی نمی کنند. همچنین مشکلات عملیاتی و استقرار ECS وجود دارد که RFC آنها را برطرف نمی‌کند و می‌تواند برای حل‌کننده‌هایی مانند Google Public DNS که پشتیبانی ECS را در سرورهای نام معتبر شناسایی می‌کنند، و همچنین حل‌کننده‌هایی که نیاز به فهرست سفید ECS دارند، مانند OpenDNS مشکلاتی ایجاد کند.

این دستورالعمل‌ها برای کمک به اجراکنندگان و اپراتورهای معتبر DNS در نظر گرفته شده‌اند تا از بسیاری از اشتباهات رایج که می‌توانند برای ECS مشکل ایجاد کنند، اجتناب کنند.

تعاریف اصطلاحات

ما از عبارات زیر برای توصیف عملیات ECS استفاده می کنیم:

  • سرور نام اگر به پرس‌و‌جوهای ECS با پاسخ‌های ECS که دارای گزینه‌های ECS منطبق هستند، ECS را پیاده‌سازی می‌کند (یا پشتیبانی می‌کند) (حتی اگر گزینه‌های ECS همیشه طول پیشوند دامنه جهانی /0 داشته باشند).

  • اگر پرس و جوهای ECS به سرورهای نام آن ارسال شده با پیشوند منبع غیر صفر، پاسخ های ECS را با دامنه غیر صفر دریافت کنند، یک منطقه ECS فعال می شود.

دستورالعمل ها برای سرورهای نام معتبر

  1. همه سرورهای نام معتبر برای یک منطقه دارای ECS باید ECS را برای منطقه فعال کنند.

    • حتی اگر فقط یک سرور نام ECS را اجرا نکند یا آن را برای منطقه فعال نکند، به سرعت به منبع بیشتر داده های کش تبدیل می شود. از آنجایی که پاسخ‌های آن دارای دامنه جهانی هستند، (تا زمانی که TTL آنها منقضی شود) به عنوان پاسخ به تمام جستارهای یک نام (صرف نظر از زیرشبکه مشتری) استفاده می‌شوند. پاسخ‌های سرورهایی که ECS را پیاده‌سازی می‌کنند و آن را فعال می‌کنند، فقط برای درخواست‌های مشتریان در محدوده خاص استفاده می‌شوند، بنابراین احتمال استفاده از آنها بسیار کمتر از پاسخ‌های دامنه جهانی است.

  2. سرورهای نام معتبری که ECS را پیاده‌سازی می‌کنند باید پاسخ‌های ECS را برای تمام مناطقی که از یک آدرس IP یا نام میزبان NS ارائه می‌شوند، حتی برای مناطقی که ECS فعال نیستند، به درخواست‌های ECS ارسال کنند.

    • Google Public DNS پشتیبانی ECS را به‌جای نام میزبان سرور یا منطقه DNS به‌طور خودکار با آدرس IP شناسایی می‌کند، زیرا تعداد آدرس‌ها از تعداد نام‌های میزبان سرور نام و از تعداد مناطق DNS بسیار کمتر است. اگر یک سرور نام معتبر همیشه پاسخ های ECS را به جستارهای ECS ارسال نکند (حتی برای مناطقی که ECS فعال نیستند)، ممکن است DNS عمومی Google ارسال درخواست های ECS را متوقف کند.

  3. سرورهای نام معتبری که ECS را پیاده‌سازی می‌کنند باید به تمام پرسش‌های ECS با پاسخ‌های ECS، از جمله پاسخ‌های منفی و ارجاعی پاسخ دهند.

    • مسائل مشابه در مورد تشخیص خودکار پشتیبانی ECS در اینجا نیز اعمال می شود.

    • پاسخ‌های منفی (NXDOMAIN و NODATA) باید برای ذخیره‌سازی بهتر و سازگاری با RFC 7871 از دامنه جهانی /0 استفاده کنند.

    • علاوه بر NXDOMAIN و NODATA (NOERROR با بخش پاسخ خالی)، سایر پاسخ‌های خطا به پرس و جوهای ECS (به ویژه SERVFAIL و REFUSED) باید شامل یک گزینه ECS منطبق با دامنه جهانی /0 باشد.

      • اگر یک سرور نام معتبر در حال تلاش برای کاهش بار از یک حمله DoS باشد، می‌تواند یک SERVFAIL را بدون داده‌های ECS برگرداند. انجام مکرر این کار باعث می شود DNS عمومی Google ارسال پرس و جو با ECS را متوقف کند (که ممکن است تعداد پرس و جوهای قانونی ارسالی آنها را کاهش دهد، اما بر پرس و جوهای حمله تصادفی زیر دامنه تأثیری نخواهد گذاشت). کاهش بار پرس و جوی قانونی در طول یک حمله DoS ممکن است میزان موفقیت پرس‌و‌جوهای قانونی را بهبود بخشد یا نکند (اگرچه می‌توان پاسخ‌ها را از حافظه پنهان برای همه مشتریان ارائه کرد).

        یک رویکرد کاهش بار مؤثرتر ارسال همه پاسخ‌ها با دامنه جهانی /0 است تا Google Public DNS به ارسال پرس‌وجوهای ECS ادامه دهد. این به Google Public DNS امکان می‌دهد پس از توقف حمله، پاسخ‌های موقعیت جغرافیایی را خیلی زودتر بازگرداند، زیرا نیازی به شناسایی مجدد پشتیبانی ECS ندارد، فقط برای درخواست مجدد پس از انقضای TTLهای پاسخ دامنه جهانی.

    • پاسخ‌های ارجاع (تفویض اختیار) همچنین باید داده‌های ECS منطبق داشته باشند و SHOULD 4 از یک دامنه جهانی /0 استفاده کنند. توجه داشته باشید که پاسخ‌های تفویض اختیار هرگز به کلاینت‌هایی که آدرس‌هایشان در داده‌های ECS نمایش داده می‌شود، ارسال نمی‌شود، بنابراین هر رکورد NS، A یا AAAA در موقعیت جغرافیایی باید توسط آدرس IP مشتری حل‌کننده انتخاب شود، نه داده‌های ECS.

  4. سرورهای نام معتبری که ECS را پیاده‌سازی می‌کنند باید یک گزینه ECS منطبق را در پاسخ‌ها به همه انواع درخواست‌های دریافتی با یک گزینه ECS داشته باشند. پاسخ دادن به پرس و جوهای آدرس IPv4 (A) با داده های ECS به اندازه کافی خوب نیست. پاسخ‌ها به A، AAAA، PTR، MX یا هر نوع درخواست دیگری باید داده‌های ECS منطبق داشته باشند یا حل‌کننده‌ها ممکن است پاسخ را به‌عنوان یک پاسخ احتمالا جعلی رها کنند، و Google Public DNS ممکن است ارسال درخواست‌ها با داده‌های ECS را متوقف کند.

    به طور خاص، پاسخ‌های ECS به جستارهای SOA، NS و DS باید همیشه از دامنه جهانی / 0 برای ذخیره بهتر و نمای ثابتی از تفویض اختیار استفاده کنند (پاسخ‌های مکان‌یابی شده به جستارهای A/AAAA برای نام‌های میزبان سرور نام خوب هستند). پاسخ به هر نوع پرس و جو (مثلاً TXT، PTR و غیره) که بر اساس داده های ECS تغییر نمی کنند، نباید از محدوده ای برابر با طول پیشوند منبع استفاده کنند، آنها باید از یک دامنه جهانی / 0 برای ذخیره سازی بهتر و کاهش بار پرس و جو استفاده کنند.

  5. سرورهای نام معتبری که پاسخ‌های CNAME با ECS فعال را برمی‌گردانند ، باید فقط اولین CNAME را در زنجیره داشته باشند، و هدف نهایی زنجیره CNAME باید با طول پیشوند دامنه یکسان با ECS فعال شود. به دلیل ابهام در مشخصات ECS، برخی از حل‌کننده‌های بازگشتی (به ویژه Unbound 6 ) ممکن است پاسخی را با دامنه دامنه نهایی غیر CNAME (/0 در صورتی که ECS فعال نباشد) برگردانند.

  6. داده های ECS ممکن است حاوی آدرس های IPv6 حتی برای سرورهای نام فقط IPv4 باشد (و بالعکس، اگرچه سرورهای نام فقط IPv6 نادر هستند).

    • سرورهای نام باید با داده‌های گزینه معتبر ECS پاسخ دهند (حوزه 0/ خوب است، اما آدرس منبع و طول پیشوند باید مطابقت داشته باشند).

    • ECS برای یک منطقه می تواند به طور جداگانه برای آدرس های IPv4 و IPv6 فعال شود.

  7. سرورهای نام معتبری که پاسخ‌های دارای ECS را برمی‌گردانند، نباید 7 پیشوند دامنه را در پاسخ‌هایشان همپوشانی داشته باشند. نمونه ای از همپوشانی پیشوندهای دامنه می تواند به صورت زیر باشد:

    • پرس و جو با پیشوند منبع 198.18.0.0/15 : پاسخ A با پیشوند scope 198.0.0.0/8

    • پرس و جو با پیشوند منبع 198.51.100/24 ​​: پاسخ B با پیشوند دامنه 198.51.0.0/16

    اگر یک کلاینت به ترتیب بالا از یک حل‌کننده بازگشتی فعال ECS درخواست کند، هر دو پرس‌وجو ممکن است پاسخ A را دریافت کنند، زیرا دامنه پاسخ ذخیره‌شده A شامل محدوده پیشوند پرس و جو دوم است. حتی اگر پرس و جوهای کلاینت به ترتیب مخالف انجام شوند و هر دو پرس و جو به سرورهای نام معتبر ارسال شوند، پاسخ های ذخیره شده ممکن است در زمان های مختلف منقضی شوند. پرس و جوهای بعدی به حل کننده بازگشتی در پیشوند همپوشانی 198.51.100/24 ​​می توانند پاسخ A یا B را دریافت کنند.

  8. هنگام اجرای پشتیبانی ECS برای اولین بار در سرورهای نام، از آدرس‌های IP جدید برای سرورهای نام که این مناطق فعال ECS را ارائه می‌کنند، استفاده کنید.

    • هنگامی که سرورهای نام معتبری که ECS را پیاده‌سازی کرده‌اند اما نتایج دامنه جهانی را برگردانده‌اند شروع به بازگرداندن پاسخ‌های فعال ECS برای یک منطقه می‌کنند، Google Public DNS به محض انقضای TTL پاسخ‌های دامنه جهانی قبلی، پاسخ‌های موقعیت جغرافیایی را به جستارها برمی‌گرداند.

    • شناسایی خودکار DNS عمومی Google از پشتیبانی ECS به ندرت درخواست های ECS را برای یک آدرس IP (یا نام میزبان سرور نام) زمانی که به طور خودکار عدم پشتیبانی ECS را شناسایی می کند (تایم وقفه، بازگشت FORMERR، BADVERS، یا ارسال پاسخ های غیر ECS) را امتحان می کند. پیاده‌سازی‌های جدید ECS در آن آدرس‌های IP (یا نام‌های میزبان NS) بسیار آهسته یا اصلاً به‌طور خودکار شناسایی می‌شوند.

  9. اطمینان حاصل کنید که اتصالات شبکه قابل اعتماد هستند و هر گونه محدودیت نرخ پاسخ به اندازه کافی بالا تنظیم شده است که سرورهای نام پرس و جوها را حذف نکنند (یا بدتر از آن، با خطاهایی که فاقد گزینه ECS منطبق هستند، پاسخ دهند).

    • برای سرورهای نامی که محدودیت نرخ پاسخ را در پرس و جوهای ECS اجرا می کنند، بهترین پاسخ NODATA با مجموعه پرچم کوتاه (TC) است که فقط شامل یک بخش سؤال منطبق و یک گزینه ECS منطبق است.

  10. پاسخ‌های به‌موقع را به همه پرسش‌ها ارسال کنید (به‌طور ایده‌آل ظرف 1 ثانیه).

    • استفاده از خدمات جستجوی آنلاین Geo-IP برای پرس و جوهای ECS به طور قابل اعتماد کار نمی کند، زیرا تاخیر تجمعی پرس و جو DNS و سرویس آنلاین Geo-IP بعید است در یک ثانیه باشد. تشخیص خودکار DNS عمومی Google از پشتیبانی ECS، پاسخ‌های با تأخیر را نشانه‌ای از پشتیبانی ضعیف یا ناقص ECS می‌داند و احتمال ارسال درخواست‌های آینده با ECS را کاهش می‌دهد. اگر پاسخ‌های کافی به تأخیر بیفتد، ارسال پرسش‌های ECS را متوقف می‌کند.

ارجاعات RFC 7871 و پاورقی های دیگر

1 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.

2 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.

3 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.

4 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.

5 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.

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

استفاده از دامنه دامنه نهایی در یک زنجیره CNAME در Unbound بی ضرر است، زیرا معمولاً به عنوان یک خرد محلی یا حل‌کننده ارسال ارسال می‌شود، جایی که همه مشتریان در یک زیر شبکه هستند و پاسخ یکسانی را دریافت می‌کنند.

7 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.