Smart DNS یک VPN نیست: آن تنظیم DNS در واقع چه چیزی را تغییر می‌دهد
یک تنظیم Smart DNS جست‌وجوی نام را برای چند سرویس هدایت می‌کند. این یک تونل رمزنگاری‌شده نیست، و همین شکاف تعیین می‌کند چه کسی می‌تواند ترافیک شما را ببیند.
تلویزیون را به یک resolver Smart DNS وصل می‌کنید، یک اپ پخش جریانی کار می‌کند، و نتیجه خودش نوشته می‌شود: این یک VPN است که کمتر هزینه دارد و سریع‌تر نصب می‌شود. نیست، و این تفاوت نکته‌گیری نیست. چیزی که تغییر کرد پاسخ تلویزیون بود وقتی پرسید یک نام میزبان کجا زندگی می‌کند؛ چیزی که تغییر نکرد این است که هر بسته هنوز خانه شما را آشکار، در همان مسیر، از همان نشانی‌ای که ISP از قبل می‌شناسد ترک می‌کند. افسانه این است که تنظیم DNS یک تونل است. واقعیت باریک‌تر و کارآمدتر است، وقتی آن را ببینید.
افسانه: تغییر DNS ترافیک شما را تغییر مسیر می‌دهد
DNS معمولی به یک برنامه می‌گوید کجا وصل شود. سرویس Smart DNS به نام‌های میزبان انتخاب‌شده با نشانی‌هایی پاسخ می‌دهد که به زیرساخت خود ارائه‌دهنده تعلق دارند، بنابراین برنامه به جای خود سرویس، به آنجا وصل می‌شود. سپس ارائه‌دهنده همان یک جریان را به مقصد واقعی هدایت می‌کند. هیچ چیز دیگری در دستگاه جابه‌جا نمی‌شود.
دقیقاً به همین دلیل است که این حقه اصلاً روی تلویزیون یا کنسول کار می‌کند. نه کلاینتی هست، نه رابطی، نه ورودی‌ای در جدول مسیرها، نه لایه رمزنگاری. دستگاه دقیقاً همان کاری را می‌کند که همیشه می‌کرد: یک نام را بازمی‌گشاید و به هر چیزی که برگردد وصل می‌شود. شما پاسخ را تغییر دادید، نه مسیر هر بسته را.
این برچسب را پروژه‌های DNS نامرتبط هم به کار می‌برند، پس مستندات خود ارائه‌دهنده را بررسی کنید، نه اینکه از نام، مجموعه‌ای از امکانات را فرض کنید. هیچ پروتکل استاندارد Smart DNS وجود ندارد؛ پوشش یک محصول هیچ چیز قابل اعتمادی درباره محصول دیگر نمی‌گوید.
واقعاً چه چیزی هدایت می‌شود و چه چیزی نه
تفاوت را آسان می‌بینید، وقتی آن را بر اساس جریان فهرست کنید نه بر اساس دستگاه.
| Flow | Steered by Smart DNS? | Why |
|---|---|---|
| A supported streaming hostname | Yes, usually | The resolver returns a provider address for that name |
| The same app's other hostnames | Only if the provider lists them | Steering is per-name, and lists are curated |
| Your browser, email, game downloads | No | Their names resolve to the ordinary destination |
| Traffic from devices not using that resolver | No | Nothing forces a device onto a particular resolver |
| Payload encryption | No | Unrelated to name resolution |
می‌توانید آن را ببینید. از resolver ارائه‌دهنده یک نام میزبان بپرسید و همان را از یک resolver عمومی بپرسید:
dig +short @<provider-resolver> example-stream.example
dig +short @1.1.1.1 example-stream.exampleپاسخ‌های متفاوت یعنی هدایت در لایه نام. پاسخ یکسان یعنی یا سرویس آن نام را پوشش نمی‌دهد یا دستگاه از آن resolver استفاده نمی‌کند — خرابی‌ای که شبیه پیکربندی اشتباه DNS به نظر می‌رسد و اغلب با حساب خراب اشتباه گرفته می‌شود.
خرابی دومی با همان بو وجود دارد. بسیاری از ارائه‌دهندگان بر اساس نشانی عمومی‌ای که اکنون استفاده می‌کنید مجوز می‌دهند، پس حساب کار می‌کند تا نشانی تغییر کند. چرخش NAT در سطح اپراتور، یا یک VPN روی آن، آن نشانی را جابه‌جا می‌کند و رله شما را رد می‌کند، در حالی که بازگشایی نام همچنان موفق است. ثبت در رجیستری یک کنترل دسترسی است، نه مدرکی بر خروج انحصاری.
DNS رمزنگاری‌شده چیز سومی است تماماً
DNS روی HTTPS و DNS روی TLS تبادل میان دستگاه شما و resolver را محافظت می‌کنند. پرس‌وجو را رمزنگاری و احراز هویت می‌کنند تا شبکه محلی نتواند آن را بخواند یا بازنویسی کند، و DoH آن را در ترافیک معمولی HTTPS روی پورت 443 حمل می‌کند، که همین دلیل شبیه بودنش به ترافیک وب برای یک فیلتر است. این یک ویژگی محرمانگی برای جست‌وجوهاست.
هدایت یک سرویس کارکردی دیگر است: خود پاسخ به یک واسطه اشاره می‌کند. یک محصول می‌تواند هر دو را همزمان ارائه دهد، و بسیاری می‌دهند، اما یکی مستلزم دیگری نیست. رمزنگاری جست‌وجوهای شما هرگز یک بایت ویدیو را از کشوری دیگر عبور نداده است.
پس «DNS رمزنگاری‌شده» به این پرسش پاسخ می‌دهد که چه کسی می‌تواند پرس‌وجوهای شما را بخواند. به این پاسخ نمی‌دهد که چه کسی می‌تواند ترافیک شما را ببیند، و نشانی خروج جدیدی به شما نمی‌دهد. مشخصات DNS over HTTPS مرجع درست برای این است که آن حفاظت چه چیزی را پوشش می‌دهد، و درباره مسیریابی چیزی نمی‌گوید.
در هر ترتیبی چه کسی چه چیزی می‌بیند
با Smart DNS، resolver نام‌هایی را که جست‌وجو می‌کنید می‌بیند، رله ارائه‌دهنده اتصالاتی را که حمل می‌کند می‌بیند، و ISP شما هنوز همه چیز دیگر را در ساختار متن آشکار می‌بیند: به کدام نشانی‌ها وصل شدید، چه وقت و چه اندازه. محتوا در جریان هدایت‌شده تا مقصد با TLS محافظت می‌شود، پس رله نشستی رمزنگاری‌شده را که نمی‌تواند بخواند هدایت می‌کند — اما می‌بیند که وصل شدید، از کجا و برای چه مدت.
با یک VPN، اپراتور تونل ترافیک و مقاصد شما را می‌بیند، که یک تصمیم اعتماد متمرکز است، و ISP شما فقط یک جریان رمزنگاری‌شده به یک نقطه پایانی می‌بیند. قرارگیری متفاوت، نه به‌طور خودکار کمتر. هیچ‌یک از این دو مدل را نباید با باز شدن یک سایت سنجید.
سرعت از مسیر پیروی می‌کند، نه از برچسب. یک رله گزینشی می‌تواند ترافیک نامرتبط را از انحراف دور نگه دارد، که برای دستگاهی که وگرنه همه چیز را تونل می‌کرد مزیت واقعی است. این هم ضمانت نیست، و هیچ ترتیبی دسترسی دائمی به سرویسی که فعالانه در پی شناسایی آن است وعده نمی‌دهد.
چه زمانی Smart DNS ابزار درست است
واقعاً ابزار درست است وقتی دستگاه اصلاً نمی‌تواند کلاینت VPN اجرا کند — تلویزیون، کنسول، یک ست‌تاپ با پشته شبکه قفل‌شده — و وقتی فقط یک سرویس نام‌برده اهمیت دارد. همچنین منطقی است وقتی آگاهانه نمی‌خواهید هر بسته روی آن دستگاه تونل شود.
ابزار اشتباه است وقتی نیاز رمزنگاری، نشانی خروج برای کل دستگاه، یا محافظت از شبکه محلی و ISP است. این‌ها ویژگی‌های تونل‌اند و هیچ تنظیم resolver آن‌ها را تولید نمی‌کند. و اگر VPN را روی همان دستگاه نگه دارید، انتظار داشته باشید مجوز مبتنی بر ثبت خراب شود، چون نشانی عمومی شما اکنون نشانی تونل است.
این تصمیم را به ترتیب اجرا کنید و در نخستین خطی که درست است بایستید:
- آیا ترافیک رمزنگاری‌شده و کل دستگاه روی یک خروج جدید لازم دارید؟ از VPN استفاده کنید، و مسیرها و استثناهایش را بررسی کنید نه نشانگر اتصالش.
- آیا فقط چند سرویس نام‌برده روی دستگاهی که نمی‌تواند تونل کند لازم دارید؟ Smart DNS متناسب است.
- آیا جست‌وجوهایتان خصوصی لازم است اما جابه‌جایی ترافیک نه؟ این DNS رمزنگاری‌شده است، که هیچ‌یک از موارد بالا نیست.
- آیا ارائه‌دهنده به نشانی فعلی شما تکیه دارد؟ انتظار اختلال را در همان لحظه‌ای داشته باشید که تغییر کند.