مقدمه: علل و کاهش تأخیر DNS
با پیچیده تر شدن صفحات وب و ارجاع منابع از دامنه های متعدد، جستجوی DNS می تواند به یک گلوگاه مهم در تجربه مرور تبدیل شود. هر زمان که یک کلاینت نیاز به پرس و جو از یک حل کننده DNS از طریق شبکه داشته باشد، تأخیر معرفی شده می تواند قابل توجه باشد، بسته به مجاورت و تعداد سرورهای نامی که حل کننده باید پرس و جو کند (بیش از 2 نادر است، اما ممکن است رخ دهد). به عنوان مثال، تصویر زیر زمان‌بندی گزارش‌شده توسط ابزار اندازه‌گیری عملکرد وب سرعت صفحه را نشان می‌دهد. هر نوار نشان دهنده منبعی است که از صفحه ارجاع داده شده است. بخش های سیاه نشان دهنده جستجوهای DNS هستند. در این صفحه 13 جستجو در 11 ثانیه اول بارگذاری صفحه انجام می شود. اگرچه چندین جستجو به صورت موازی انجام می شود، عکس صفحه نشان می دهد که 5 زمان جستجوی سریال مورد نیاز است که چند ثانیه از کل زمان بارگذاری صفحه 11 ثانیه را شامل می شود.
تأخیر DNS دو مؤلفه دارد:
- تأخیر بین کلاینت (کاربر) و سرور رفع DNS. در بیشتر موارد این امر عمدتاً به دلیل محدودیت‌های معمول زمان رفت و برگشت (RTT) در سیستم‌های شبکه‌ای است: فاصله جغرافیایی بین ماشین‌های سرویس گیرنده و سرور. تراکم شبکه؛ از دست دادن بسته و تأخیر طولانی ارسال مجدد (به طور متوسط یک ثانیه). سرورهای پربار، حملات انکار سرویس و غیره.
- تأخیر بین سرورهای حل و فصل و سایر سرورهای نام. این منبع تأخیر عمدتاً توسط عوامل زیر ایجاد می شود:
- حافظه پنهان از دست می رود. اگر پاسخی را نتوان از حافظه پنهان یک حل‌کننده ارائه کرد، اما نیاز به جستجوی بازگشتی از سرورهای نام دیگر داشته باشد، تأخیر شبکه اضافه‌شده قابل توجه است، به‌ویژه اگر سرورهای معتبر از نظر جغرافیایی از راه دور باشند.
- تامین کم اگر حل‌کننده‌های DNS بیش از حد بارگذاری شوند، باید درخواست‌ها و پاسخ‌های رزولوشن DNS را در صف قرار دهند و ممکن است بسته‌ها را رها کرده و دوباره ارسال کنند.
- ترافیک مخرب حتی اگر یک سرویس DNS بیش از حد ارائه شود، ترافیک DoS می‌تواند بار غیرمجاز را روی سرورها وارد کند. به طور مشابه، حملات به سبک Kaminsky می‌توانند شامل flooding resolers با کوئری‌هایی باشند که تضمین شده‌اند که حافظه پنهان را دور بزنند و به درخواست‌های خروجی برای حل نیاز دارند.
ما معتقدیم که عامل از دست دادن حافظه پنهان اصلی‌ترین علت تأخیر DNS است و در ادامه بیشتر درباره آن بحث می‌کنیم.
حافظه پنهان از دست می رود
حتی اگر یک حل‌کننده منابع محلی فراوانی داشته باشد، اجتناب از تاخیرهای اساسی مرتبط با مکالمه با سرورهای نام راه دور دشوار است. به عبارت دیگر، با فرض اینکه حل‌کننده به‌اندازه کافی فراهم شده باشد تا زمان بازدید از حافظه پنهان در سمت سرور صفر باشد، از دست دادن حافظه پنهان از نظر تأخیر بسیار گران باقی می‌ماند. برای رسیدگی به خطا، یک حل کننده باید حداقل با یک، اما اغلب دو یا چند سرور نام خارجی صحبت کند. با استفاده از خزنده وب Googlebot، ما میانگین زمان وضوح 130 میلی‌ثانیه را برای سرورهای نامی که پاسخ می‌دهند مشاهده کرده‌ایم. با این حال، 4-6٪ کامل از درخواست ها به دلیل از دست دادن بسته UDP و غیرقابل دسترس بودن سرورها، به سادگی به پایان می رسند. اگر خرابی هایی مانند از دست دادن بسته، سرورهای نام مرده، خطاهای پیکربندی DNS و غیره را در نظر بگیریم، میانگین زمان واقعی تفکیک انتها به انتها 300-400 میلی ثانیه است. با این حال، واریانس بالا و دم بلند وجود دارد.
اگرچه نرخ از دست دادن حافظه پنهان ممکن است در بین سرورهای DNS متفاوت باشد، اما به دلایل زیر جلوگیری از از دست دادن حافظه پنهان اساساً دشوار است:
- اندازه و رشد اینترنت خیلی ساده، با رشد اینترنت، هم از طریق افزودن کاربران جدید و هم از طریق سایت‌های جدید، بیشتر محتواها مورد توجه حاشیه‌ای قرار می‌گیرند. در حالی که تعداد کمی از سایت‌ها (و در نتیجه نام‌های DNS) بسیار محبوب هستند، اکثر آنها فقط برای تعداد کمی از کاربران مورد علاقه هستند و به ندرت به آنها دسترسی پیدا می‌کنند. بنابراین اکثر درخواست ها منجر به از دست رفتن حافظه پنهان می شود.
- مقادیر کم زمان برای زندگی (TTL). گرایش به سمت مقادیر کمتر DNS TTL به این معنی است که رزولوشن ها به جستجوهای مکرر بیشتری نیاز دارند.
- جداسازی کش سرورهای DNS معمولاً در پشت بار متعادل کننده ها مستقر می شوند که پرس و جوها را به صورت تصادفی به ماشین های مختلف اختصاص می دهند. این باعث می‌شود که هر سرور جداگانه به جای اینکه بتواند از وضوح‌های کش شده از یک استخر مشترک استفاده مجدد کند، یک کش جداگانه نگهداری می‌کند.
اقدامات کاهشی
در Google Public DNS، ما چندین رویکرد را برای سرعت بخشیدن به زمان جستجوی DNS پیاده سازی کرده ایم. برخی از این رویکردها نسبتاً استاندارد هستند. دیگران تجربی هستند:
- تهیه سرورها به اندازه کافی برای مدیریت بار ناشی از ترافیک مشتری، از جمله ترافیک مخرب.
- جلوگیری از حملات DoS و تقویت اگرچه این عمدتاً یک مسئله امنیتی است و بر حل‌کننده‌های بسته کمتر از موارد باز تأثیر می‌گذارد، اما جلوگیری از حملات DoS با حذف بار ترافیک اضافی روی سرورهای DNS برای عملکرد مفید است. برای کسب اطلاعات در مورد رویکردهایی که برای به حداقل رساندن احتمال حملات استفاده می کنیم، به صفحه مزایای امنیتی مراجعه کنید.
- تعادل بار برای حافظه پنهان مشترک ، برای بهبود نرخ ضربه حافظه پنهان انبوه در سراسر خوشه خدمات.
- ارائه پوشش جهانی برای نزدیکی به همه کاربران.
تهیه خوشه های خدماتی به اندازه کافی
حل‌کننده‌های DNS ذخیره‌سازی باید عملیات گران‌تری نسبت به سرورهای نام معتبر انجام دهند، زیرا بسیاری از پاسخ‌ها را نمی‌توان از حافظه ارائه کرد. در عوض، آنها نیاز به ارتباط با سایر سرورهای نام دارند و بنابراین ورودی/خروجی شبکه زیادی را می طلبند. علاوه بر این، حل‌کننده‌های باز در برابر تلاش‌های مسموم کردن حافظه پنهان بسیار آسیب‌پذیر هستند، که نرخ از دست دادن حافظه پنهان را افزایش می‌دهد (چنین حملاتی به طور خاص درخواست‌هایی را برای نام‌های جعلی ارسال می‌کنند که نمی‌توانند از حافظه پنهان حل شوند) و حملات DoS، که به بار ترافیک می‌افزایند. اگر حل کننده ها به اندازه کافی تهیه نشده باشند و نتوانند با بار همراه باشند، این می تواند تأثیر بسیار منفی بر عملکرد داشته باشد. بسته ها حذف می شوند و نیاز به ارسال مجدد دارند، درخواست های سرور نام باید در صف قرار گیرند و غیره. همه این عوامل به تاخیر می افزایند.
بنابراین، برای حل‌کننده‌های DNS مهم است که برای ورودی/خروجی با حجم بالا تدارک دیده شوند. این شامل مدیریت حملات احتمالی DDoS می‌شود که تنها راه‌حل مؤثر برای آن، تأمین بیش از حد بسیاری از ماشین‌ها است. با این حال، در عین حال، مهم است که هنگام اضافه کردن ماشین‌ها، نرخ ضربه حافظه پنهان را کاهش ندهید. این امر مستلزم اجرای یک سیاست موازنه بار موثر است که در زیر به آن می پردازیم.
تعادل بار برای ذخیره مشترک
اگر متعادل‌سازی بار به‌درستی انجام نشود، زیرساخت‌های حل‌کننده مقیاس‌پذیری با افزودن ماشین‌ها می‌تواند نتیجه معکوس داشته باشد و نرخ ضربه حافظه پنهان را کاهش دهد . در یک استقرار معمولی، چندین ماشین در پشت یک متعادل کننده بار قرار می گیرند که با استفاده از یک الگوریتم ساده مانند دور روبین، ترافیک را به طور مساوی بین هر ماشین توزیع می کند. نتیجه این است که هر ماشین حافظه پنهان مستقل خود را حفظ می کند، به طوری که محتوای کش شده در بین ماشین ها ایزوله می شود. اگر هر درخواست ورودی به یک ماشین تصادفی توزیع شود، بسته به ماهیت ترافیک، نرخ موثر از دست رفتن حافظه پنهان را می توان به نسبت افزایش داد. به عنوان مثال، برای نام‌هایی با TTL طولانی که به طور مکرر مورد پرسش قرار می‌گیرند، نرخ از دست دادن حافظه پنهان را می‌توان با تعداد ماشین‌های موجود در خوشه افزایش داد. (برای نام‌هایی با TTL بسیار کوتاه، که به ندرت مورد پرسش قرار می‌گیرند، یا منجر به پاسخ‌های غیرقابل ذخیره‌سازی می‌شوند (0 TTL و خطا)، نرخ از دست دادن حافظه پنهان واقعاً با افزودن ماشین‌ها تحت تأثیر قرار نمی‌گیرد.)
برای افزایش نرخ ضربه برای نام‌های کش، مهم است که سرورها را با تعادل بارگذاری کنید تا کش تکه تکه نشود. در Google Public DNS، ما دو سطح کش داریم. در یک مجموعه از ماشین‌ها، بسیار نزدیک به کاربر، یک کش کوچک برای هر ماشین حاوی محبوب‌ترین نام‌ها است. اگر یک پرس و جو از این کش برآورده نشود، به مجموعه دیگری از ماشین ها ارسال می شود که کش را بر اساس نام ها تقسیم می کنند. برای این حافظه نهان سطح دوم، همه پرس و جوهای مربوط به یک نام به یک دستگاه ارسال می شوند، جایی که نام یا در حافظه پنهان است یا نه.
توزیع خوشه های خدمت برای پوشش جغرافیایی گسترده
برای حل‌کننده‌های بسته، این واقعاً مشکلی نیست. برای حل‌کننده‌های باز، هرچه سرورهای شما به کاربران شما نزدیک‌تر باشد، تأخیر کمتری را در انتهای کلاینت مشاهده خواهند کرد. علاوه بر این، داشتن پوشش جغرافیایی کافی می تواند به طور غیرمستقیم تأخیر پایان به انتها را بهبود بخشد، زیرا سرورهای نام معمولاً نتایج بهینه شده برای مکان حل کننده DNS را برمی گردانند. یعنی اگر یک ارائه‌دهنده محتوا میزبان سایت‌های آینه‌ای در سراسر جهان باشد، سرورهای نام آن ارائه‌دهنده آدرس IP را در نزدیکترین فاصله به حل‌کننده DNS برمی‌گرداند.
Google Public DNS در مراکز داده در سراسر جهان میزبانی می شود و از مسیریابی anycast برای ارسال کاربران به نزدیکترین مرکز داده از لحاظ جغرافیایی استفاده می کند.
علاوه بر این، Google Public DNS از زیرشبکه مشتری EDNS (ECS) پشتیبانی می‌کند، یک پسوند پروتکل DNS برای حل‌کننده‌ها برای ارسال مکان کلاینت به سرورهای نام، که می‌تواند پاسخ‌های حساس به مکان را بهینه‌سازی شده برای آدرس IP مشتری واقعی، به جای آدرس IP حل‌کننده، بازگرداند. لطفاً این سؤالات متداول را برای جزئیات بخوانید. Google Public DNS به طور خودکار سرورهای نامی را شناسایی می کند که از زیرشبکه مشتری EDNS پشتیبانی می کنند.