یکی از ویژگی‌های Chromium بار زیادی را روی سرورهای DNS ریشه ایجاد می‌کند

یکی از ویژگی‌های Chromium بار زیادی را روی سرورهای DNS ریشه ایجاد می‌کند

مرورگر Chromium، مادر منبع باز پررونق گوگل کروم و مایکروسافت اج جدید، توجه منفی قابل توجهی را برای ویژگی‌ای که با نیت خوب در نظر گرفته شده بود، به خود جلب کرده است: بررسی می‌کند که آیا ISP کاربر نتایج جستجوی دامنه‌ای که وجود ندارد را «دزدیده است» یا خیر. .

آشکارساز تغییر مسیر اینترانتپرس‌وجوهای جعلی برای «دامنه‌های» تصادفی ایجاد می‌کند که از نظر آماری احتمال وجود ندارد، تقریباً نیمی از کل ترافیک دریافتی توسط سرورهای DNS ریشه در سراسر جهان را بر عهده دارد. مت توماس، مهندس Verisign مطالبی طولانی نوشت ارسال در وبلاگ APNIC مشکل را توصیف کرده و مقیاس آن را ارزیابی می کند.

چگونه وضوح DNS معمولا انجام می شود

یکی از ویژگی‌های Chromium بار زیادی را روی سرورهای DNS ریشه ایجاد می‌کند
این سرورها بالاترین مرجعی هستند که باید با آنها تماس بگیرید تا .com، .net و غیره را حل کنید تا به شما بگویند frglxrtmpuf یک دامنه سطح بالا (TLD) نیست.

DNS یا Domain Name System، سیستمی است که توسط آن رایانه‌ها می‌توانند نام‌های دامنه به یاد ماندنی مانند arstechnica.com را به آدرس‌های IP بسیار کمتر کاربرپسندتر مانند 3.128.236.93 تبدیل کنند. بدون DNS، اینترنت به روشی وجود نداشت که انسان بتواند از آن استفاده کند، به این معنی که بار غیر ضروری در زیرساخت های سطح بالا یک مشکل واقعی است.

بارگیری یک صفحه وب مدرن می تواند به تعداد باورنکردنی جستجوی DNS نیاز داشته باشد. به عنوان مثال، هنگامی که صفحه اصلی ESPN را تجزیه و تحلیل کردیم، 93 نام دامنه جداگانه، از a.espncdn.com تا z.motads.com را شمارش کردیم. همه آنها برای بارگذاری کامل صفحه ضروری هستند!

برای تطبیق این نوع حجم کاری برای موتور جستجویی که نیاز به خدمت به کل جهان دارد، DNS به عنوان یک سلسله مراتب چند سطحی طراحی شده است. در بالای این هرم سرورهای ریشه قرار دارند - هر دامنه سطح بالا، مانند .com، خانواده سرورهای خود را دارد که بالاترین مرجع برای هر دامنه زیر آنها است. یک پله بالاتر اینها سرورها خود سرورهای ریشه هستند a.root-servers.net به m.root-servers.net.

چگونه اغلب این اتفاق می افتد؟

به لطف سلسله مراتب کش چند سطحی زیرساخت DNS، درصد بسیار کمی از پرس و جوهای DNS جهان به سرورهای ریشه می رسد. اکثر مردم اطلاعات DNS Resolver خود را مستقیماً از ISP خود دریافت می کنند. هنگامی که دستگاه کاربر باید بداند چگونه به یک وب سایت خاص دسترسی پیدا کند، ابتدا یک درخواست به یک سرور DNS که توسط آن ارائه دهنده محلی مدیریت می شود ارسال می شود. اگر سرور DNS محلی پاسخ را نداند، درخواست را به "Forwarders" خود (در صورت مشخص شدن) ارسال می کند.

اگر نه سرور DNS ارائه‌دهنده محلی و نه «سرورهای بازارسال» مشخص‌شده در پیکربندی آن، پاسخی در حافظه پنهان ندارند، درخواست مستقیماً به سرور دامنه معتبر ارائه می‌شود. بالاتر اونی که میخوای تبدیلش کنی چه زمانی домен.com این بدان معنی است که درخواست به سرورهای معتبر خود دامنه ارسال می شود com، که در gtld-servers.net.

سیستم gtld-servers، که درخواست به آن داده شد، با لیستی از سرورهای نام معتبر برای دامنه domain.com و همچنین حداقل یک رکورد پیوند حاوی آدرس IP یکی از سرورهای نامی مشابه پاسخ می دهد. سپس، پاسخ‌ها به سمت پایین زنجیره حرکت می‌کنند - هر فورواردکننده این پاسخ‌ها را به سروری که آنها را درخواست کرده ارسال می‌کند، تا زمانی که پاسخ در نهایت به سرور ارائه‌دهنده محلی و رایانه کاربر برسد. همه آنها این پاسخ را در حافظه پنهان ذخیره می کنند تا بی جهت سیستم های سطح بالاتر را مختل نکنند.

در بیشتر موارد، رکوردهای سرور نام برای domain.com در حال حاضر در یکی از این فورواردها ذخیره می شود، بنابراین سرورهای ریشه مختل نخواهند شد. با این حال، در حال حاضر ما در مورد نوع URL که با آن آشنا هستیم صحبت می کنیم - آدرسی که به یک وب سایت معمولی تبدیل می شود. درخواست‌های Chrome در سطح هستند بالاتر این، در مرحله خود خوشه ها root-servers.net.

بررسی سرقت Chromium و NXDomain

یکی از ویژگی‌های Chromium بار زیادی را روی سرورهای DNS ریشه ایجاد می‌کند
Chromium بررسی می‌کند که «این سرور DNS مرا فریب می‌دهد؟» تقریباً نیمی از ترافیکی را تشکیل می دهد که به خوشه سرورهای DNS ریشه Verisign می رسد.

مرورگر Chromium، پروژه مادر گوگل کروم، مایکروسافت اج جدید، و تعداد بیشماری از مرورگرهای کمتر شناخته شده، می‌خواهد جستجوی آسان را در یک کادر به کاربران ارائه دهد که گاهی اوقات "Omnibox" نامیده می‌شود. به عبارت دیگر، کاربر هم URL های واقعی و هم درخواست های موتور جستجو را در یک قسمت متنی در بالای پنجره مرورگر وارد می کند. برداشتن یک گام دیگر به سمت ساده سازی، همچنین کاربر را مجبور نمی کند که بخشی از URL را با آن وارد کند http:// یا https://.

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

اگر کاربری در اینترانت شرکت خود «بازاریابی» را تایپ کند و اینترانت شرکت یک وب‌سایت داخلی با همین نام داشته باشد، Chromium یک کادر اطلاعاتی را نمایش می‌دهد که از کاربر می‌پرسد آیا می‌خواهد «بازاریابی» را جستجو کند یا به https://marketing. ممکن است اینطور نباشد، اما بسیاری از ISP ها و ارائه دهندگان وای فای عمومی هر URL غلط املایی را "ربایش" می کنند و کاربر را به صفحه ای پر از بنر هدایت می کنند.

نسل تصادفی

توسعه‌دهندگان Chromium نمی‌خواستند کاربران در شبکه‌های معمولی هر بار که یک کلمه را جستجو می‌کنند یک جعبه اطلاعات ببینند که منظورشان چیست، بنابراین آزمایشی را اجرا کردند: وقتی مرورگر را راه‌اندازی می‌کنند یا شبکه‌ها را تغییر می‌دهند، Chromium جستجوهای DNS را در سه مورد انجام می‌دهد. به طور تصادفی "دامنه" در سطح بالای تولید شده، هفت تا پانزده کاراکتر طول دارد. اگر هر دو از این درخواست‌ها با آدرس IP یکسان برگردند، Chromium فرض می‌کند که شبکه محلی خطاها را "ربایش" می‌کند. NXDOMAIN، که باید دریافت کند، بنابراین مرورگر تا اطلاع ثانوی تمام جستارهای تک کلمه ای وارد شده را به عنوان تلاش برای جستجو در نظر می گیرد.

متاسفانه در شبکه هایی که هیچ نتایج پرس و جوهای DNS را بدزدید، این سه عملیات معمولاً به بالاترین حد خود می رسند، تا سرورهای نام اصلی: سرور محلی نمی داند چگونه حل کند. qwajuixk، بنابراین این درخواست را به Forwarder خود فوروارد می کند که همین کار را انجام می دهد تا در نهایت a.root-servers.net یا یکی از "برادران" او مجبور نخواهد شد بگوید "متاسفم، اما این یک دامنه نیست."

از آنجایی که تقریباً 1,67*10^21 نام دامنه جعلی احتمالی با طول بین هفت تا پانزده کاراکتر وجود دارد، رایج ترین آنها هر کدام از این آزمایشات انجام شده در شبکه "صادق"، به سرور اصلی می رسد. این به همان اندازه است نصف از کل بار روی DNS ریشه، طبق آمار آن بخش از خوشه ها root-servers.net، که متعلق به Verisign هستند.

تاریخ دوباره تکرار می شود

این اولین بار نیست که پروژه ای با بهترین نیت ایجاد می شود ناموفق یا تقریباً یک منبع عمومی را با ترافیک غیر ضروری پر کرده است - این بلافاصله ما را به یاد تاریخ طولانی و غم انگیز سرور NTP (پروتکل زمان شبکه) D-Link و پول-هنینگ کمپ در اواسط دهه 2000 می اندازد.

در سال 2005، Poul-Henning توسعه‌دهنده FreeBSD، که تنها سرور پروتکل زمان شبکه Stratum 1 دانمارک را نیز در اختیار داشت، یک صورت‌حساب غیرمنتظره و بزرگ برای ترافیک ارسالی دریافت کرد. به طور خلاصه، دلیل آن این بود که توسعه دهندگان D-Link آدرس سرورهای NTP Stratum 1، از جمله سرور Kampa را در میان‌افزار خط سوئیچ‌ها، روترها و نقاط دسترسی شرکت نوشتند. این امر بلافاصله ترافیک سرور کامپا را نه برابر کرد و باعث شد که صرافی اینترنت دانمارک (نقطه تبادل اینترنت دانمارک) تعرفه خود را از "رایگان" به "9 دلار در سال" تغییر دهد.

مشکل این نبود که تعداد زیادی روتر D-Link وجود داشت، بلکه مشکل این بود که آنها "خارج از خط" بودند. همانند DNS، NTP باید به شکل سلسله مراتبی عمل کند - سرورهای Stratum 0 اطلاعات را به سرورهای Stratum 1، که اطلاعات را به سرورهای Stratum 2 منتقل می کنند و به همین ترتیب در سلسله مراتب ادامه می دهند. یک روتر معمولی خانگی، سوئیچ یا نقطه دسترسی مانند آنچه D-Link با آدرس های سرور NTP برنامه ریزی کرده بود، درخواست ها را به سرور Stratum 2 یا Stratum 3 ارسال می کند.

پروژه Chromium، احتمالاً با بهترین نیت، مشکل NTP را در مشکل DNS تکرار کرد و سرورهای ریشه اینترنت را با درخواست هایی بارگیری کرد که هرگز قرار نبودند آنها را رسیدگی کنند.

امید به یک راه حل سریع وجود دارد

پروژه Chromium یک منبع باز دارد حشره، که برای حل این مشکل نیاز به غیرفعال کردن Intranet Redirect Detector به طور پیش فرض دارد. ما باید به پروژه Chromium اعتبار بدهیم: اشکال پیدا شد قبل از آنچگونه مت توماس از Verisign توجه زیادی را به او جلب کرد روزه داری در وبلاگ APNIC این اشکال در ژوئن کشف شد، اما تا زمان ارسال توماس فراموش شد. پس از روزه گرفتن، تحت نظارت دقیق قرار گرفت.

امید است که این مشکل به زودی حل شود و سرورهای DNS ریشه دیگر مجبور نباشند هر روز به 60 میلیارد درخواست جعلی پاسخ دهند.

در حقوق تبلیغات

سرورهای حماسی - آیا VPS در ویندوز یا لینوکس با پردازنده های قدرتمند خانواده AMD EPYC و درایوهای بسیار سریع Intel NVMe. برای سفارش عجله کنید

یکی از ویژگی‌های Chromium بار زیادی را روی سرورهای DNS ریشه ایجاد می‌کند

منبع: www.habr.com

اضافه کردن نظر