مزایای امنیتی

مقدمه: تهدیدات امنیتی DNS و کاهش آن

به دلیل طراحی باز و توزیع شده سیستم نام دامنه و استفاده آن از پروتکل Datagram کاربر (UDP)، DNS در برابر اشکال مختلف حمله آسیب پذیر است. حل‌کننده‌های DNS بازگشتی عمومی یا «باز» به‌ویژه در معرض خطر هستند، زیرا بسته‌های ورودی را به مجموعه‌ای از آدرس‌های IP منبع مجاز محدود نمی‌کنند. ما بیشتر نگران دو نوع حمله رایج هستیم:

  • حملات جعل منجر به مسمومیت کش DNS می شود. انواع مختلفی از جعل DNS و سوء استفاده های جعل فراوان است که هدف آنها هدایت کاربران از سایت های قانونی به وب سایت های مخرب است. اینها شامل حملات به اصطلاح Kaminsky است که در آن مهاجمان کنترل کامل یک منطقه DNS را به دست می گیرند.
  • حملات انکار سرویس (DoS). مهاجمان ممکن است حملات DDoS را علیه خود حل‌کننده‌ها انجام دهند، یا حل‌کننده‌ها را ربودند تا حملات DoS را به سیستم‌های دیگر انجام دهند. حملاتی که از سرورهای DNS برای راه‌اندازی حملات DoS به سیستم‌های دیگر با بهره‌برداری از اندازه رکورد/پاسخ DNS بزرگ استفاده می‌کنند، به عنوان حملات تقویتی شناخته می‌شوند.

در زیر به هر کلاس حمله بیشتر پرداخته می شود.

حملات مسمومیت حافظه پنهان

انواع مختلفی از حملات جعل DNS وجود دارد که می تواند منجر به مسمومیت حافظه پنهان شود، اما سناریوی کلی به شرح زیر است:

  1. مهاجم برای یک نام دامنه که می‌داند سرور معتبر نیست و بعید است که در حافظه نهان سرور وجود داشته باشد، به یک حل‌کننده DNS هدف، درخواست‌های متعددی برای نام دامنه ارسال می‌کند.
  2. حل‌کننده درخواست‌ها را به سرورهای نام دیگر ارسال می‌کند (که مهاجم می‌تواند آدرس IP آنها را نیز پیش‌بینی کند).
  3. در این بین، مهاجم سرور قربانی را با پاسخ های جعلی که به نظر می رسد از سرور نام واگذار شده سرچشمه می گیرد، پر می کند. پاسخ ها حاوی رکوردهایی هستند که در نهایت دامنه درخواستی را به آدرس های IP کنترل شده توسط مهاجم حل می کند. آنها ممکن است حاوی سوابق پاسخ برای نام حل شده باشند یا بدتر از آن، ممکن است اختیارات بیشتری را به یک سرور نام متعلق به مهاجم واگذار کنند تا کنترل کل منطقه را در دست بگیرند.
  4. اگر یکی از پاسخ‌های جعلی با درخواست حل‌کننده مطابقت داشته باشد (مثلاً با نام کوئری، نوع، شناسه و پورت منبع تحلیلگر) و قبل از پاسخ از سرور نام واقعی دریافت شود، حل‌کننده پاسخ جعلی را می‌پذیرد و آن را در حافظه پنهان ذخیره می‌کند و دور می‌اندازد. پاسخ واقعی
  5. پرسش‌های آینده برای دامنه یا منطقه در معرض خطر با رزولوشن‌های DNS جعلی از کش پاسخ داده می‌شوند. اگر مهاجم مدت زمان بسیار طولانی برای پاسخ جعلی تعیین کرده باشد، رکوردهای جعلی تا زمانی که ممکن است بدون بازخوانی در حافظه پنهان می مانند.

برای آشنایی عالی با حملات Kaminsky، به راهنمای مصور آسیب‌پذیری Kaminsky DNS مراجعه کنید.

حملات DoS و تقویت

حل‌کننده‌های DNS در معرض تهدیدات DoS معمولی هستند که هر سیستم شبکه‌ای را آزار می‌دهد. با این حال، حملات تقویت‌کننده نگرانی خاصی دارند زیرا حل‌کننده‌های DNS اهداف جذابی برای مهاجمانی هستند که از نسبت بزرگ پاسخ به درخواست حل‌کننده‌ها برای به دست آوردن پهنای باند آزاد اضافی سوء استفاده می‌کنند. حل‌کننده‌هایی که از EDNS0 (مکانیسم‌های توسعه برای DNS) پشتیبانی می‌کنند، به‌دلیل اندازه بسته بزرگ‌تری که می‌توانند برگردانند، به‌ویژه آسیب‌پذیر هستند.

در یک سناریوی تقویت، حمله به صورت زیر انجام می شود:

  1. مهاجم با استفاده از یک آدرس IP جعلی منبع، درخواست‌های سرور DNS قربانی را ارسال می‌کند. پرس و جوها ممکن است از یک سیستم منفرد یا شبکه ای از سیستم ها با استفاده از آدرس IP جعلی یکسان ارسال شوند. پرس‌و‌جوها برای سوابقی هستند که مهاجم می‌داند که پاسخ‌های بسیار بزرگ‌تری، تا چندین ده برابر اندازه پرس‌و‌جوهای اصلی (از این رو به حمله «تقویت» می‌گویند).
  2. سرور قربانی پاسخ‌های بزرگ را به آدرس IP منبع ارسال شده در درخواست‌های جعلی ارسال می‌کند و سیستم را تحت تأثیر قرار می‌دهد و باعث ایجاد وضعیت DoS می‌شود.

اقدامات کاهشی

راه حل استاندارد در سراسر سیستم برای آسیب پذیری های DNS DNSSEC است. با این حال، تا زمانی که به طور جهانی پیاده‌سازی نشود، حل‌کننده‌های DNS باز باید به طور مستقل اقداماتی را برای کاهش تهدیدات شناخته شده انجام دهند. تکنیک های زیادی پیشنهاد شده است. IETF RFC 5452 را ببینید: اقداماتی برای انعطاف پذیرتر کردن DNS در برابر پاسخ های جعلی برای مروری بر اکثر آنها. در Google Public DNS، ما رویکردهای زیر را پیاده‌سازی کرده‌ایم و توصیه می‌کنیم:

  • ایمن سازی کد خود در برابر سرریزهای بافر، به ویژه کدی که مسئول تجزیه و سریال سازی پیام های DNS است.
  • تامین بیش از حد منابع ماشین برای محافظت در برابر حملات مستقیم DoS به خود حل کننده ها. از آنجایی که جعل آدرس های IP برای مهاجمان بی اهمیت است، مسدود کردن پرس و جوها بر اساس آدرس IP یا زیرشبکه غیرممکن است. تنها راه مؤثر برای مقابله با چنین حملاتی، جذب ساده بار است.
  • اجرای بررسی اعتبار اولیه بسته های پاسخ و اعتبار سرور نام، برای محافظت در برابر مسمومیت ساده حافظه پنهان. اینها مکانیزم‌های استاندارد و بررسی‌های سلامت عقل هستند که هر حل‌کننده ذخیره‌سازی سازگار با استانداردها باید انجام دهد.
  • افزودن آنتروپی برای درخواست پیام‌ها ، برای کاهش احتمال حملات پیچیده‌تر جعل/ مسمومیت حافظه پنهان مانند حملات Kaminsky. بسیاری از تکنیک های توصیه شده برای افزودن آنتروپی وجود دارد. در زیر، مروری بر مزایا، محدودیت‌ها و چالش‌های هر یک از این تکنیک‌ها ارائه می‌کنیم و نحوه پیاده‌سازی آن‌ها را در Google Public DNS بحث می‌کنیم.
  • حذف پرس و جوهای تکراری ، برای مبارزه با احتمال "حملات تولد".
  • درخواست های محدود کننده نرخ ، برای جلوگیری از حملات DoS و تقویت.
  • نظارت بر سرویس برای IP های مشتری با استفاده از بیشترین پهنای باند و تجربه بالاترین نسبت اندازه پاسخ به درخواست.

DNSSEC

استاندارد افزونه های امنیتی نام دامنه (DNSSEC) در چندین RFC IETF مشخص شده است: 4033 ، 4034 ، 4035 و 5155 .

حل‌کننده‌هایی که DNSSEC حملات مسمومیت حافظه پنهان را با تأیید صحت پاسخ‌های دریافتی از سرورهای نام اجرا می‌کنند. هر منطقه DNS مجموعه‌ای از جفت‌های کلید خصوصی/عمومی را نگه می‌دارد و برای هر رکورد DNS، یک امضای دیجیتال منحصربه‌فرد تولید و با استفاده از کلید خصوصی رمزگذاری می‌شود. سپس کلید عمومی مربوطه از طریق یک زنجیره اعتماد توسط کلیدهای متعلق به مناطق والد احراز هویت می شود. حل‌کننده‌های منطبق با DNSSEC پاسخ‌هایی را که حاوی امضای صحیح نیستند رد می‌کنند. DNSSEC به طور موثری از دستکاری پاسخ ها جلوگیری می کند، زیرا در عمل، جعل امضا بدون دسترسی به کلیدهای خصوصی تقریبا غیرممکن است.

از ژانویه 2013، Google Public DNS به طور کامل از DNSSEC پشتیبانی می کند. ما پیام‌های با قالب DNSSEC را می‌پذیریم و ارسال می‌کنیم و پاسخ‌ها را برای احراز هویت صحیح تأیید می‌کنیم. ما قویاً سایر حل کننده ها را تشویق می کنیم که همین کار را انجام دهند.

همچنین پاسخ‌های NSEC را همانطور که در IETF RFC 8198: استفاده تهاجمی از DNSSEC-Validated Cache مشخص شده است، ذخیره می‌کنیم. این می‌تواند پرس‌وجوهای NXDOMAIN را به سرورهای نام‌گذاری‌کننده DNSSEC و استفاده از NSEC برای پاسخ‌های منفی کاهش دهد.

حمل و نقل رمزگذاری شده توسط مشتری

Google Public DNS از پروتکل های حمل و نقل رمزگذاری شده، DNS از طریق HTTPS و DNS از طریق TLS پشتیبانی می کند. این پروتکل‌ها از دستکاری، استراق سمع و جعل جلوگیری می‌کنند و حریم خصوصی و امنیت بین یک کلاینت و Google Public DNS را تا حد زیادی افزایش می‌دهند. آنها DNSSEC را تکمیل می کنند تا جستجوهای DNS تأیید شده سرتاسر را ارائه دهند.

اجرای بررسی اعتبار پایه

برخی از خرابی‌های کش DNS می‌تواند به دلیل عدم تطابق ناخواسته و نه لزوماً مخرب بین درخواست‌ها و پاسخ‌ها باشد (به عنوان مثال شاید به دلیل پیکربندی نادرست سرور نام، اشکال در نرم‌افزار DNS و غیره). حداقل، حل‌کننده‌های DNS باید بررسی‌هایی را برای تأیید اعتبار و ارتباط پاسخ‌های سرورهای نام انجام دهند. ما تمام دفاع های زیر را توصیه می کنیم (و اجرا می کنیم):

  • بیت بازگشتی را در درخواست‌های خروجی تنظیم نکنید و همیشه زنجیره‌های نمایندگی را به صراحت دنبال کنید. غیرفعال کردن بیت بازگشتی تضمین می کند که حل کننده شما در حالت "تکرار کننده" عمل می کند، به طوری که شما به جای اینکه به سرور نام دیگری اجازه دهید این پرس و جوها را از طرف شما انجام دهد، به طور صریح از هر سرور نام در زنجیره تفویض پرس و جو می کنید.
  • پیام های پاسخ مشکوک را رد کنید. برای جزئیات آنچه که ما "مشکوک" می دانیم به زیر مراجعه کنید.
  • رکوردهای A را بر اساس سوابق چسبی که از درخواست‌های قبلی ذخیره شده‌اند، به مشتریان برنگردانید. به عنوان مثال، اگر یک درخواست مشتری برای ns1.example.com دریافت کردید، باید آدرس را دوباره حل کنید، به جای ارسال یک رکورد A بر اساس سوابق چسب ذخیره شده از یک سرور نام TLD .com.

رد پاسخ هایی که معیارهای لازم را ندارند

Google Public DNS همه موارد زیر را رد می کند:

  • پاسخ‌های غیرقابل تجزیه یا بدشکل.
  • پاسخ هایی که فیلدهای کلیدی با فیلدهای مربوطه در درخواست مطابقت ندارند. این شامل شناسه پرس و جو، IP منبع، پورت منبع، IP مقصد یا نام پرس و جو می شود. RFC 5452، بخش 3 را برای توضیح کامل رفتار جعلی DNS ببینید.
  • سوابق غیر مرتبط با درخواست
  • به رکوردهایی که نمی توانیم زنجیره CNAME را برای آنها بازسازی کنیم پاسخ دهید.
  • سوابق (در پاسخ، مرجع، یا بخش های اضافی) که سرور نام پاسخ دهنده برای آنها معتبر نیست. ما "اعتبار" یک نام سرور را با مکان آن در زنجیره نمایندگی برای یک دامنه مشخص تعیین می کنیم. Google Public DNS اطلاعات زنجیره تفویض را در حافظه پنهان ذخیره می کند و ما هر پاسخ دریافتی را در برابر اطلاعات ذخیره شده در حافظه پنهان تأیید می کنیم تا اعتبار سرور نام پاسخ دهنده را برای پاسخ به یک درخواست خاص مشخص کنیم.

افزودن آنتروپی به درخواست ها

هنگامی که یک حل‌کننده بررسی‌های اولیه سلامت عقل را اجرا می‌کند، مهاجم باید برای تطبیق شناسه پرس و جو، پورت UDP (درخواست)، آدرس IP (پاسخ)، و نام پرس و جوی اصلی، پاسخ‌های حل‌کننده قربانی را پر کند. قبل از اینکه سرور نام قانونی انجام دهد درخواست کنید.

متأسفانه، دستیابی به این امر دشوار نیست، زیرا یک فیلد شناسایی منحصر به فرد، شناسه پرس و جو، تنها 16 بیت طول دارد (یعنی برای 1/65536 شانس برای درست کردن آن). سایر فیلدها نیز از نظر دامنه محدود هستند و تعداد کل ترکیبات منحصر به فرد را به تعداد نسبتاً کمی تبدیل می کند. برای محاسبه ترکیبات درگیر به RFC 5452، بخش 7 مراجعه کنید.

بنابراین، چالش این است که تا حد امکان آنتروپی را به بسته درخواست اضافه کنیم، در قالب استاندارد پیام DNS، تا تطبیق موفقیت آمیز ترکیبی از فیلدها در پنجره فرصت برای مهاجمان دشوارتر شود. ما تمام تکنیک های مورد بحث در بخش های بعدی را توصیه می کنیم و اجرا کرده ایم.

ما در کنفرانس DNS OARC 38 در ژوئیه 2022 مروری به روز از تکنیک های ذکر شده در اینجا ارائه کردیم. این ارائه همچنین شامل توصیه هایی برای اپراتورهای سرور نام است.

تصادفی کردن پورت های منبع

به عنوان یک گام اساسی، هرگز اجازه ندهید بسته های درخواست خروجی از پورت UDP پیش فرض 53 استفاده کنند، یا از یک الگوریتم قابل پیش بینی برای تخصیص چندین پورت (مثلاً افزایش ساده) استفاده کنند. از طیف گسترده ای از پورت ها از 1024 تا 65535 تا حد مجاز در سیستم خود استفاده کنید و از یک تولید کننده اعداد تصادفی قابل اعتماد برای اختصاص پورت ها استفاده کنید. به عنوان مثال، Google Public DNS از 15 بیت استفاده می کند تا تقریباً 32000 شماره پورت مختلف را مجاز کند.

توجه داشته باشید که اگر سرورهای شما در پشت فایروال‌ها، load-balancer یا سایر دستگاه‌هایی که ترجمه آدرس شبکه (NAT) را انجام می‌دهند مستقر هستند، آن دستگاه‌ها ممکن است پورت‌های بسته‌های خروجی را از حالت تصادفی خارج کنند. مطمئن شوید که دستگاه‌های NAT را برای غیرفعال کردن تصادفی‌سازی پورت پیکربندی کرده‌اید.

انتخاب تصادفی سرورهای نام

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

اگر نگران تأخیر هستید، می‌توانید از باندبندی زمان رفت و برگشت (RTT) استفاده کنید که شامل تصادفی‌سازی در محدوده‌ای از آدرس‌هایی است که زیر آستانه تأخیر مشخصی هستند (مثلاً 30 میلی‌ثانیه، 300 میلی‌ثانیه و غیره).

کوکی های DNS

RFC 7873 یک گزینه EDNS0 برای افزودن کوکی های 64 بیتی به پیام های DNS تعریف می کند. یک سرویس گیرنده پشتیبانی از کوکی DNS شامل یک کوکی تصادفی 64 بیتی و به صورت اختیاری (در صورت شناخته شدن) یک کوکی سرور در یک درخواست است. اگر یک سرور پشتیبانی، گزینه کوکی را در یک درخواست معتبر بیابد، کوکی مشتری و کوکی سرور صحیح را در پاسخ منعکس می کند. سپس مشتری پشتیبانی می‌تواند با تأیید کوکی مشتری در پاسخ، پاسخ از سرور مورد انتظار را تأیید کند.

اگر یک سرور نام از کوکی‌های DNS پشتیبانی نمی‌کند، می‌توان از دو گزینه زیر برای افزودن آنتروپی استفاده کرد.

تصادفی کردن موارد در نام های پرس و جو

استانداردهای DNS ایجاب می‌کند که سرورهای نام، نام‌ها را با حساسیت به حروف کوچک و بزرگ رفتار کنند. به عنوان مثال، نام های example.com و EXAMPLE.COM باید به همان آدرس IP 2 حل شوند. علاوه بر این، همه به جز اقلیت کوچکی از سرورهای نام، نام را در پاسخ بازتاب می‌دهند، همانطور که در درخواست ظاهر می‌شود، با حفظ حالت اصلی.

بنابراین، راه دیگری برای افزودن آنتروپی به درخواست‌ها، تغییر تصادفی حروف در نام‌های دامنه مورد نظر است. این تکنیک، همچنین به عنوان "0x20" شناخته می شود زیرا بیت 0x20 برای تنظیم حروف US-ASCII استفاده می شود، اولین بار در پیش نویس اینترنت IETF استفاده از بیت 0x20 در برچسب های DNS برای بهبود هویت تراکنش ها پیشنهاد شد. با این تکنیک، پاسخ سرور نام باید نه تنها با نام پرس و جو بلکه با حروف هر حرف در رشته نام مطابقت داشته باشد. برای مثال، wWw.eXaMpLe.CoM یا WwW.ExamPLe.COm . این ممکن است آنتروپی کمی به پرس‌و‌جوها برای دامنه‌های سطح بالا و ریشه اضافه کند، اما برای اکثر نام‌های میزبان مؤثر است.

یکی از چالش های مهمی که در هنگام اجرای این تکنیک کشف کردیم این است که برخی از سرورهای نام از رفتار پاسخ مورد انتظار پیروی نمی کنند:

  • برخی از سرورهای نام با عدم حساسیت کامل به حروف بزرگ پاسخ می دهند: آنها به درستی نتایج یکسانی را بدون توجه به حروف کوچک در درخواست نشان می دهند، اما پاسخ با حروف دقیق نام در درخواست مطابقت ندارد.
  • سایر سرورهای نام با حساسیت کامل به حروف بزرگ و کوچک پاسخ می‌دهند (در تخطی از استانداردهای DNS): آنها با نام‌های معادل بسته به مورد در درخواست متفاوت رفتار می‌کنند، یا به هیچ وجه پاسخ نمی‌دهند یا پاسخ‌های نادرست NXDOMAIN را برمی‌گردانند که دقیقاً با حروف مورد نظر مطابقت دارد. درخواست.
  • برخی از سرورهای نام به جز پرس و جوهای PTR در منطقه arpa به درستی کار می کنند.

برای هر دوی این نوع سرورهای نام، تغییر شکل نام پرس و جو نتایج نامطلوبی ایجاد می کند: برای گروه اول، پاسخ از یک پاسخ جعلی قابل تشخیص نیست. برای گروه دوم، پاسخ (در صورت وجود) می تواند کاملاً نادرست باشد.

راه حل فعلی ما برای این مشکل استفاده از تصادفی سازی حروف فقط برای سرورهای نام است که می دانیم استانداردها را به درستی اعمال می کنند. ما همچنین بر اساس تجزیه و تحلیل گزارش های خود، زیر دامنه های استثنایی مناسب را برای هر یک از آنها فهرست می کنیم. اگر پاسخی که به نظر می رسد از آن سرورها می آید حاوی مورد صحیح نباشد، پاسخ را رد می کنیم. سرورهای نام فعال بیش از 70 درصد از ترافیک خروجی ما را مدیریت می کنند.

چسباندن برچسب های غیر عادی به نام های پرس و جو

اگر یک حل‌کننده نمی‌تواند مستقیماً یک نام را از حافظه پنهان حل کند، یا نمی‌تواند مستقیماً یک سرور نام معتبر را پرس و جو کند، باید ارجاعات را از یک سرور نام ریشه یا TLD دنبال کند. در بیشتر موارد، درخواست‌ها به سرورهای نام ریشه یا TLD منجر به ارجاع به سرور نام دیگری می‌شود، نه تلاشی برای حل نام به آدرس IP. بنابراین، برای چنین درخواست‌هایی، باید یک برچسب تصادفی به نام پرس‌وجو الصاق کرد تا آنتروپی درخواست افزایش یابد، در حالی که خطر شکست در حل یک نام وجود ندارد. یعنی ارسال یک درخواست به یک سرور نام ارجاع کننده برای نامی که پیشوند با برچسب nonce دارد، مانند entriih-f10r3.www.google.com ، باید همان نتیجه درخواست www.google.com را نشان دهد.

اگرچه در عمل چنین درخواست‌هایی کمتر از 3 درصد درخواست‌های خروجی را تشکیل می‌دهند، با فرض ترافیک معمولی (از آنجایی که بیشتر درخواست‌ها را می‌توان مستقیماً از حافظه پنهان یا با یک پرس‌وجو پاسخ داد)، این دقیقاً انواع درخواست‌هایی هستند که یک مهاجم سعی می‌کند آن‌ها را وادار کند. حل کننده مشکل بنابراین، این تکنیک می تواند در جلوگیری از سوء استفاده های سبک Kaminsky بسیار موثر باشد.

پیاده‌سازی این تکنیک مستلزم آن است که برچسب‌های nonce فقط برای درخواست‌هایی استفاده شوند که تضمین شده است که منجر به ارجاع می‌شوند. یعنی پاسخ هایی که حاوی رکوردهایی در بخش پاسخ ها نیستند. با این حال، هنگام تلاش برای تعریف مجموعه ای از چنین درخواست هایی با چالش های متعددی مواجه شدیم:

  • برخی از سرورهای نام TLD با کد کشور (ccTLD) در واقع برای سایر TLD های سطح دوم (2LD) معتبر هستند. اگرچه 2LD ​​ها دارای دو برچسب هستند، اما 2LD ها درست مانند TLD ها رفتار می کنند، به همین دلیل است که اغلب توسط سرورهای نام ccTLD مدیریت می شوند. به عنوان مثال، سرورهای نام mod.uk .uk nic.uk ، و از این رو، نام‌های میزبان موجود در آن مناطق، مانند www.nic.uk ، www.mod.uk ، و غیره. به عبارت دیگر، درخواست به سرورهای نام ccTLD برای حل چنین نام‌های میزبانی منجر به ارجاع نمی‌شود، بلکه منجر به پاسخ‌های معتبر می‌شود. اضافه کردن برچسب‌های nonce به چنین نام‌هایی باعث می‌شود که نام‌ها غیرقابل حل شوند.
  • گاهی اوقات سرورهای نام عمومی TLD (gTLD) پاسخ‌های غیرمعتبر را برای سرورهای نام برمی‌گردانند. به این معنا که برخی از نام‌های میزبان سرور نام وجود دارند که اتفاقاً در منطقه gTLD زندگی می‌کنند تا در ناحیه دامنه خود. یک gTLD یک پاسخ غیرمعتبر برای این نام هاست ها، با استفاده از هر رکورد چسبی که اتفاقاً در پایگاه داده خود دارد، به جای بازگرداندن یک ارجاع، برمی گرداند. به عنوان مثال، نام سرور ns3.indexonlineserver.com به جای اینکه در منطقه indexonlineserver.com باشد، در منطقه gTLD .COM قرار داشت. وقتی درخواستی برای سرور gTLD برای n3.indexonlineserver.com کردیم، به جای ارجاع، یک آدرس IP برای آن دریافت کردیم. با این حال، اگر یک برچسب nonce اضافه می‌کردیم، ارجاعی به indexonlineserver.com که پس از آن قادر به حل نام میزبان نبود. بنابراین، نمی‌توانیم برای سرورهای نامی که به وضوح از یک سرور gTLD نیاز دارند، برچسب‌های غیرانسی اضافه کنیم.
  • اختیارات مناطق و نام میزبان در طول زمان تغییر می کند. این می‌تواند باعث شود که در صورت تغییر زنجیره تفویض، نام میزبانی که قبلاً قابل حل نبود، غیرقابل حل شود.

برای رسیدگی به این چالش‌ها، استثناهایی را برای نام‌های میزبان پیکربندی کردیم که نمی‌توانیم برچسب‌های غیرمستقی برای آن‌ها اضافه کنیم. اینها نام‌های میزبانی هستند که سرورهای نام TLD پاسخ‌های غیر ارجاعی را بر اساس گزارش‌های سرور ما برمی‌گردانند. ما به طور مداوم لیست استثناها را بررسی می کنیم تا مطمئن شویم که در طول زمان معتبر می ماند.

حذف پرس و جوهای تکراری

حل‌کننده‌های DNS در برابر «حملات تولد» آسیب‌پذیر هستند، به این دلیل که از «پارادوکس تولد» ریاضی استفاده می‌کنند، که در آن احتمال تطابق به تعداد زیادی ورودی نیاز ندارد. حملات تولد شامل سیل سرور قربانی نه تنها با پاسخ های جعلی، بلکه با پرس و جوهای اولیه است و روی حل کننده حساب می شود تا درخواست های متعددی را برای حل یک نام واحد صادر کند. هرچه تعداد درخواست‌های خروجی صادر شده بیشتر باشد، احتمال اینکه مهاجم یکی از آن درخواست‌ها را با پاسخ جعلی مطابقت دهد، بیشتر می‌شود: یک مهاجم فقط به ترتیب 300 درخواست در حین پرواز برای 50 درصد شانس موفقیت در مطابقت با جعلی نیاز دارد. پاسخ، و 700 درخواست برای نزدیک به 100٪ موفقیت.

برای محافظت در برابر این استراتژی حمله، باید مطمئن شوید که تمام پرس و جوهای تکراری را از صف خروجی کنار بگذارید. به عنوان مثال، Google Public DNS هرگز اجازه نمی دهد بیش از یک درخواست معوق برای همان نام پرس و جو، نوع پرس و جو و آدرس IP مقصد یکسان باشد.

پرس و جوهای محدود کننده نرخ

جلوگیری از حملات انکار سرویس چندین چالش خاص را برای حل‌کننده‌های DNS بازگشتی باز ایجاد می‌کند:

  • حل‌کننده‌های بازگشتی باز اهداف جذابی برای راه‌اندازی حملات تقویتی هستند. آنها سرورهایی با ظرفیت بالا و قابلیت اطمینان بالا هستند و می توانند پاسخ های بزرگ تری نسبت به یک سرور نام معتبر معمولی تولید کنند - به خصوص اگر یک مهاجم بتواند پاسخ بزرگی را به حافظه پنهان خود تزریق کند. این وظیفه هر توسعه دهنده یک سرویس DNS باز است که از استفاده از سرورهای خود برای حمله به سیستم های دیگر جلوگیری کند.
  • شناسایی حملات تقویتی در زمانی که در حال وقوع هستند دشوار است. مهاجمان می توانند از طریق هزاران حل کننده باز حمله را انجام دهند، به طوری که هر حل کننده تنها بخش کوچکی از حجم کلی پرس و جو را می بیند و نمی تواند سیگنال واضحی مبنی بر به خطر افتادن آن استخراج کند.
  • ترافیک مخرب باید بدون هیچ گونه اختلال یا کاهش سرویس DNS برای کاربران عادی مسدود شود. DNS یک سرویس شبکه ضروری است، بنابراین خاموش کردن سرورها برای قطع حمله یک گزینه نیست و همچنین انکار سرویس به IP مشتری خاص برای مدت طولانی نیست. حل‌کننده‌ها باید بتوانند به‌محض شروع حمله، سریعاً آن را مسدود کنند و به محض پایان حمله، سرویس کاملاً عملیاتی را بازیابی کنند.

بهترین رویکرد برای مبارزه با حملات DoS، تحمیل یک مکانیسم محدودکننده نرخ یا «گسل‌کننده» است. Google Public DNS دو نوع کنترل نرخ را پیاده سازی می کند:

  • کنترل نرخ درخواست های خروجی به سایر سرورهای نام. برای محافظت از سایر سرورهای نام DNS در برابر حملات DoS که می‌توانند از سرورهای حل‌کننده ما راه‌اندازی شوند، Google Public DNS محدودیت‌های QPS را در درخواست‌های خروجی از هر خوشه سرویس‌دهی برای هر آدرس IP سرور نام اعمال می‌کند.

  • کنترل نرخ پاسخ های خروجی به مشتریان. برای محافظت از سایر سیستم‌ها در برابر تقویت و حملات DoS توزیع شده (botnet) سنتی که می‌توانند از سرورهای حل‌کننده ما راه‌اندازی شوند، Google Public DNS دو نوع محدودیت نرخ را در جستارهای مشتری انجام می‌دهد:

    • برای محافظت در برابر حملات سنتی مبتنی بر حجم، هر سرور محدودیت‌هایی را برای هر IP QPS و میانگین پهنای باند اعمال می‌کند.
    • برای محافظت در برابر حملات تقویت، که در آن پاسخ های بزرگ به پرس و جوهای کوچک مورد سوء استفاده قرار می گیرند، هر سرور یک حداکثر میانگین ضریب تقویت به ازای هر مشتری-IP را اعمال می کند. میانگین ضریب تقویت یک نسبت قابل تنظیم اندازه پاسخ به پرس و جو است که از الگوهای ترافیک تاریخی مشاهده شده در گزارش های سرور ما تعیین می شود.

    اگر درخواست‌های DNS از یک آدرس IP منبع از حداکثر نرخ QPS بیشتر شود، درخواست‌های اضافی حذف می‌شوند. اگر پرس و جوهای DNS از طریق UDP از یک آدرس IP منبع به طور مداوم از میانگین پهنای باند یا حد تقویت فراتر رود (پاسخ گاه به گاه بزرگ می گذرد)، ممکن است پرس و جوها حذف شوند یا فقط یک پاسخ کوچک ارسال شود. پاسخ های کوچک ممکن است یک پاسخ خطا یا یک پاسخ خالی با مجموعه بیت برش (به طوری که اکثر پرس و جوهای قانونی از طریق TCP دوباره امتحان شوند و موفق شوند). همه سیستم‌ها یا برنامه‌ها از طریق TCP دوباره امتحان نمی‌شوند، و DNS روی TCP ممکن است توسط فایروال‌های سمت کلاینت مسدود شود، بنابراین برخی از برنامه‌ها ممکن است در هنگام کوتاه شدن پاسخ‌ها به درستی کار نکنند. با این وجود، کوتاه کردن به مشتریان سازگار با RFC اجازه می دهد تا در اکثر موارد به درستی کار کنند.

  1. برای مثال، مقاله حملات تقویت DNS را ببینید و به طور کلی یک بحث خوب در مورد مشکل را ببینید. ↩

  2. RFC 1034، بخش 3.5 می گوید: ↩

    توجه داشته باشید که در حالی که حروف بزرگ و کوچک در نام دامنه مجاز است، هیچ اهمیتی به حروف داده نمی شود. یعنی دو نام با املای یکسان اما حالت متفاوت باید به عنوان یکسان تلقی شوند.