چگونه پرس‌وجوهای بازگشتی و تکرارشونده DNS کارایی شبکه را با امنیت معامله می‌کنند

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

اسناد بنیادین دفترچه آدرس اینترنت، یعنی RFC 1034 و RFC 1035، این قابلیت دوگانه را در همان ابتدای پیدایش پروتکل ایجاد کردند، هرچند پیاده‌سازی عملی به شدت به سمت واگذاری متمایل شده است. در یک پرس‌وجوی بازگشتی، تحلیل‌گر خرد روی یک لپ‌تاپ یا گوشی هوشمند، یک درخواست واحد را به یک سرور DNS بازگشتی ارسال می‌کند که معمولاً توسط یک ارائه‌دهنده خدمات اینترنت یا یک نهاد عمومی مانند کلودفلر یا گوگل اداره می‌شود. سپس کلاینت منتظر می‌ماند. این سرور بازگشتی است که بار یافتن پاسخ را بر عهده می‌گیرد و اگر آدرس IP از قبل در حافظه پنهان محلی آن ذخیره نشده باشد، سلسله‌مراتب جهانی را می‌پیماید.[1][2][4]

در مقابل، تحلیل تکرارشونده یک فرآیند عملی و درگیرانه است. همان‌طور که مستندات فنی کلودفلر توضیح می‌دهد: «در یک پرس‌وجوی تکرارشونده DNS، هر پرس‌وجوی DNS مستقیماً با آدرس یک سرور DNS دیگر برای پرسیدن به کلاینت پاسخ می‌دهد و کلاینت به پرس‌وجو از سرورهای DNS ادامه می‌دهد تا زمانی که یکی از آن‌ها با آدرس IP صحیح برای دامنه مورد نظر پاسخ دهد.» درخواست‌کننده باید یک پرس‌وجوی جدید برای آن سرور ارجاع‌داده‌شده تولید کند و این چرخه را از طریق یکی از ۱۳ خوشه منطقی سرور ریشه، سرورهای دامنه سطح بالا و در نهایت سرورهای نام معتبر تکرار کند.[2][6]

این تمایز اغلب به عنوان مسئله‌ای در کارایی شبکه مطرح می‌شود. یک جستجوی بازگشتی دقیقاً به یک پرس‌وجوی خروجی از کلاینت نیاز دارد و یک پاسخ به همراه دارد. یک جستجوی تکرارشونده برای دامنه‌ای که در حافظه پنهان نیست، به حداقل سه پرس‌وجوی متوالی نیاز دارد که بار اضافی شبکه را برای دستگاه آغازکننده درخواست سه برابر می‌کند. برای دستگاه‌های موبایل باتری‌دار که در شبکه‌های بی‌سیم محدود کار می‌کنند، این بار اضافی غیرقابل‌قبول تلقی می‌شود، به همین دلیل است که تقریباً تمام سیستم‌عامل‌های مصرف‌کننده به طور پیش‌فرض از تحلیل‌گرهای خرد بازگشتی استفاده می‌کنند.[2][7]

با این حال، راحتی روش بازگشتی خطرات ساختاری قابل‌توجهی را به همراه دارد؛ واقعیتی که مهندسان شبکه و پژوهشگران امنیتی دائماً درباره آن بحث می‌کنند. از آنجا که یک سرور بازگشتی یک پرس‌وجوی کوچک - که از نظر تاریخی به ۵۱۲ بایت روی UDP محدود شده است - را می‌پذیرد و کار گسترده‌ای برای تولید پاسخ انجام می‌دهد، به شدت در برابر حملات تقویت DNS آسیب‌پذیر است. عوامل مخرب می‌توانند آدرس IP یک قربانی را جعل کرده و هزاران پرس‌وجوی بازگشتی را به تحلیل‌گرهای باز ارسال کنند، که باعث می‌شود آن سرورها قربانی را با بسته‌های پاسخ عظیم و ناخواسته غرق کنند.[4][5]

علاوه بر این، اتکا به یک تحلیل‌گر بازگشتی مرکزی، یک نقطه شکست واحد برای مسموم‌سازی حافظه پنهان ایجاد می‌کند. اگر یک مهاجم با موفقیت یک آدرس IP جعلی را به حافظه پنهان یک سرور بازگشتی تزریق کند، هر کلاینتی که برای آن دامنه به آن سرور متکی است، بی‌صدا به یک مقصد مخرب هدایت می‌شود. در یک مدل تکرارشونده، کلاینت خودش زنجیره ارجاعات را تأیید می‌کند، که این امر جعل پاسخ معتبر نهایی را برای مهاجم بدون به خطر انداختن سرورهای ریشه یا TLD بسیار دشوارتر می‌کند.[2][5]

صنعت به جای کنار گذاشتن تحلیل بازگشتی، تلاش کرده است تا آسیب‌پذیری‌های آن را وصله کند. پروتکل‌هایی مانند DNSSEC امضاهای رمزنگاری‌شده را به رکوردهای DNS اضافه می‌کنند و به تحلیل‌گرهای بازگشتی اجازه می‌دهند تا تأیید کنند پاسخ‌هایی که از سرورهای معتبر دریافت می‌کنند دستکاری نشده‌اند. با این حال، همان‌طور که بحث‌ها در نشست‌های مهندسی اخیر مانند IETF 122 در آوریل ۲۰۲۵ برجسته می‌کنند، استقرار DNSSEC همچنان ناقص است و بسیاری از مسیرهای بازگشتی را در برابر دستکاری آسیب‌پذیر باقی می‌گذارد.[3][5]

در عمل، اینترنت مدرن بر یک رویکرد ترکیبی تکیه دارد. پرش اولیه از دستگاه کاربر به سرور DNS محلی تقریباً همیشه بازگشتی است و سرعت و پهنای باند کم را در اولویت قرار می‌دهد. اما سفر بعدی - زمانی که آن سرور محلی باید پاسخی را پیدا کند که در اختیار ندارد - به صورت تکرارشونده انجام می‌شود. سرور بازگشتی خودش به عنوان یک کلاینت عمل می‌کند و به صورت تکرارشونده از سلسله‌مراتب جهانی پرس‌وجو می‌کند تا دستگاه کاربر نهایی مجبور به انجام این کار نباشد.[2][6][7]