سالها توصیهٔ رایج برای تغییر حلکنندهٔ سامانهٔ نام دامنه (DNS) این بود که سراغ ۱.۱.۱.۱ کلادفلر یا ۸.۸.۸.۸ گوگل بروید تا شاید جستوجوی نشانیها اندکی سریعتر یا مطمئنتر شود. مقایسههای تازهتر نشان دادهاند که تفاوت اصلی میان DNS گوگل و DNS کلادفلر صرفاً به سرعت خام محدود نمیشود؛ بااینحال، سرعت معمولاً ملموسترین دلیل برای اهمیتدادن به این موضوع بود.
در ۲۰۲۶، DNS بیش از هر زمان دیگری با حریم خصوصی در وب گره خورده است. فناوریهای جدیدتر میتوانند اطلاعاتی را پنهان کنند که HTTPS پیشتر آشکار باقی میگذاشت، اما این سازوکارهای حفاظتی زمانی بهترین کارایی را دارند که درخواستهای DNS شما نیز محافظت شوند. اکنون تنظیمات DNS تعیین میکند چه کسانی میتوانند دامنههای درخواستی شما را ببینند، از کدام گزینههای DNS رمزگذاریشده میتوانید بهره ببرید، چه چیزهایی پالایش شوند و تا چه اندازه از قابلیتهای نوین حریم خصوصی مانند «ClientHello رمزگذاریشده» بهرهمند شوید.
HTTPS سرانجام یکی از قدیمیترین رخنههایش را میبندد
ECH مشکلی را حل میکند که HTTPS هرگز بهطور کامل برطرف نکرد
HTTPS سالهاست از محتوای ترافیک وب محافظت میکند، اما از گذشته یک سرنخ آشکار بر جا میگذاشت. هنگامی که مرورگر شما اتصال امنی را آغاز میکرد، «نشانگر نام سرور» (SNI) در پیام TLS ClientHello میتوانست نام میزبانی را که قصد دسترسی به آن داشتید آشکار کند.
تصور کنید نامهای قفلشده میفرستید، اما مقصد را با خطی خوانا روی پاکت نوشتهاید. شرکت ارائهدهندهٔ اینترنت نمیتوانست محتوای نامه را بخواند، ولی اغلب میتوانست تشخیص دهد که به کدام وبسایت متصل میشوید.
«ClientHello رمزگذاریشده» (ECH) دقیقاً برای رفع همین مشکل طراحی شده است. ECH که در مارس ۲۰۲۶ با RFC ۹۸۴۹ استاندارد شد، بخش حساس TLS ClientHello، از جمله نام واقعی سرور، را رمزگذاری میکند. اندروید ۱۷ با افزودن پشتیبانی گسترده از ECH به یکی از سیستمعاملهای بزرگ موبایل، این روند را یک گام جلوتر برد؛ ضمن آنکه ECH از پیش در بیشتر مرورگرهای دسکتاپ در دسترس بود. استفادهٔ عملی از آن همچنان به پشتیبانی کتابخانهٔ شبکهٔ برنامه و سرور مقصد بستگی دارد، اما مسیر روشن است: پنهانکردن نام میزبان، بهجای قابلیتی آزمایشی در مرورگر، در حال تبدیلشدن به بخشی عادی از زیرساخت وب است.
DNS پیوند نزدیکی با این فرایند دارد. وبسایتی که از ECH پشتیبانی میکند، اطلاعات موردنیاز کارخواه را از طریق رکوردهای HTTPS در DNS منتشر میکند. این اطلاعات میتواند شامل پیکربندی ECH باشد که کلید عمومی و دیگر پارامترهای لازم برای دستدهی رمزگذاریشده را در بر میگیرد.
روند کلی تقریباً چنین است:
دستگاه شما ← رکورد HTTPS را از DNS درخواست میکند ← پیکربندی ECH را دریافت میکند ← با استفاده از ECH به وبسایت متصل میشود
به حلکنندهٔ ویژهای برای DNS نیاز ندارید که بهنوعی ECH را «بفهمد». مسئلهٔ مهمتر این است که آیا خود درخواست DNS در معرض دید قرار دارد یا نه.
اگر دستگاه شما نام دامنهٔ example.com را با DNS معمولی و رمزگذارینشده درخواست کند، ممکن است شرکت ارائهدهندهٔ اینترنت پیش از آنکه ECH فرصت پنهانکردن نام میزبان در اتصال HTTPS را پیدا کند، آن را دیده باشد. در این حالت یک رخنه را بستهاید، اما همان اطلاعات لحظهای زودتر از جای دیگری بیرون رفته است.
به همین دلیل DNS رمزگذاریشده و ECH در کنار یکدیگر بسیار کارآمدند. ECH نام وبسایت را هنگام دستدهی TLS پنهان میکند و DNS رمزگذاریشده نیز درخواست پیش از آن را از دید دیگران دور نگه میدارد.
رمزگذاری DNS به بخشی عادی از زیرساخت اینترنت بدل میشود
DoT، DoH و DoQ یک رخنهٔ مشترک را به سه شیوه میبندند
DNS سنتی پرسوجوها را بدون رمزگذاری و بهصورت متن ساده میفرستد. دستگاه شما نشانی IP مربوط به یک نام دامنه را از حلکننده میپرسد و هر کسی که بتواند این ترافیک را زیر نظر بگیرد، ممکن است درخواست شما را ببیند.
در گذر سالها چندین جایگزین رمزگذاریشده پدید آمدهاند. «DNS بر بستر TLS» یا DNS-over-TLS (DoT)، پرسوجوهای DNS را درون یک اتصال TLS قرار میدهد و معمولاً از درگاه ۸۵۳ استفاده میکند. «DNS بر بستر HTTPS» یا DNS-over-HTTPS (DoH)، آنها را از راه HTTPS و درگاه ۴۴۳ میفرستد تا ترافیک DNS در کنار ترافیک معمول وب جابهجا شود. نسخههای نوین DoH همچنین میتوانند بهجای اتکای کامل به TCP، بر بستر HTTP/۳ و QUIC، یعنی اتصالهای سریع اینترنتی مبتنی بر UDP، اجرا شوند.
«DNS بر بستر QUIC» یا DNS-over-QUIC (DoQ)، گزینهای جدیدتر در کنار DoH و DoT است که دادههای رمزگذاریشدهٔ DNS را مستقیماً از طریق QUIC منتقل میکند. QUIC از جریانهای مستقل پشتیبانی میکند؛ بنابراین گمشدن بستهای که بر یک درخواست DNS اثر میگذارد، لزوماً درخواستهای نامرتبط پس از آن را متوقف نمیکند. در شبکههای ناپایدار یا پرترافیک، این ویژگی میتواند DoQ را از روشهای قدیمی مبتنی بر TCP کارآمدتر کند.
نیازی نیست جزئیات این زیرساخت را به خاطر بسپارید. نکتهٔ کاربردی برای بیشتر مردم این است که DoH، DoT و DoQ همگی ترافیک DNS میان دستگاه و حلکننده را رمزگذاری میکنند.
DoQ نیز مدتهاست از مرحلهٔ آزمایشی فراتر رفته است. ارائهدهندگان عمومی DNS اکنون آن را در شبکههای عملیاتی خود به کار میگیرند؛ بااینحال، امکان استفاده از آن همچنان به پشتیبانی سیستمعامل، روتر، مرورگر یا برنامهٔ DNS شما بستگی دارد.
نکتهای که بهآسانی از نظر پنهان میماند این است که تغییر ارائهدهندهٔ DNS، بهخودیخود چیزی را رمزگذاری نمیکند. ممکن است دستگاهتان را به ۱.۱.۱.۱ متصل کنید، اما همچنان درخواستهای معمولی DNS را بهصورت متن ساده بفرستید. تغییر حلکننده فقط مشخص میکند چه کسی به این درخواستها پاسخ دهد؛ برای محافظت از خود ترافیک باید از روشی رمزگذاریشده مانند DoH، DoT یا DoQ استفاده کنید.
اکنون که مرورگرها و سیستمعاملها جزئیات فنی را پشت نامهایی مانند «DNS امن» و «DNS خصوصی» پنهان کردهاند، نادیدهگرفتن این نکته آسانتر هم شده است. در بسیاری از موارد، همین تنظیمات تعیین میکنند که ترافیک DNS شما رمزگذاری شود یا نه. DNS روی HTTPS نیز میتواند مانع از آن شود که شرکت ارائهدهندهٔ اینترنتتان جستوجوی تکتک دامنهها را ببیند؛ نه اینکه صرفاً حلکنندهٔ پاسخگو را تغییر دهد.
حلکنندهٔ DNS اکنون بخشی از سیاست حریم خصوصی شماست
رمزگذاری اعتماد را از میان نمیبرد؛ فقط طرف مورد اعتماد را عوض میکند
DNS رمزگذاریشده نمیگذارد کسانی که میان شما و حلکننده قرار دارند، درخواستهای DNS شما را بهسادگی بخوانند؛ اما خود حلکننده را از این میان حذف نمیکند. حلکننده همچنان دامنههایی را که برای یافتن نشانیشان میپرسید میبیند؛ بنابراین، انتخاب آن تا اندازهای تصمیمی دربارهٔ حریم خصوصی و خطمشی است.
ارائهدهندگان مختلف دربارهٔ ثبت رویدادها، مدت نگهداری دادهها، مسدودسازی بدافزار، پالایش محتوا، DNSSEC و حوزهٔ قضایی، قواعد متفاوتی دارند. برای نمونه، Quad9 از سوئیس فعالیت میکند و تمرکز ویژهای بر حریم خصوصی و مسدودکردن دامنههای مخرب دارد. برخی ارائهدهندگان رایگان DNS نیز بسته به اینکه پالایش، امنیت، حریم خصوصی یا کار دیگری اولویت شما باشد، در زمینههای مشخصی از Google و Cloudflare بهتر عمل میکنند.
حتی اگر یکی از ارائهدهندگان بزرگ و شناختهشده را انتخاب کنید، لزوماً به یک مجموعه قواعد محدود نمیشوید. سرویسهای بزرگ اغلب حالتهای جایگزین DNS برای مسدودسازی بدافزار و دیگر گونههای پالایش ارائه میکنند؛ بنابراین، با تغییر نشانی حلکننده میتوانید بدون عوضکردن کامل ارائهدهنده، موارد مسدودشده را تغییر دهید.
ممکن است شرکت ارائهدهندهٔ اینترنت شما نیز برخی از همین امکانات را عرضه کند، اما استفاده از حلکنندهای دیگر به شما اجازه میدهد قواعد و سیاست حریم خصوصی دلخواهتان را برگزینید. هیچ ارائهدهندهٔ DNS واحدی برای همه بهترین نیست. نکتهٔ مهم این است که حلکنندهٔ پیشفرض شرکت اینترنتی شما نیز یک انتخاب به شمار میآید؛ حتی اگر خودتان هرگز آگاهانه آن را انتخاب نکرده باشید.
تغییر DNS همچنان جای VPN را نمیگیرد
تغییر تنظیمات DNS میتواند حریم خصوصی شما را بهبود دهد، اما شما را در اینترنت نامرئی نمیکند.
DNS رمزگذاریشده نمیگذارد کسانی که ارتباط میان دستگاه شما و ارائهدهندهٔ DNS را زیر نظر دارند، بهسادگی نام دامنههایی را که جستوجو میکنید بخوانند. ECH نیز میتواند نام وبسایتی را پنهان کند که پیشتر هنگام برقراری اتصال اولیهٔ HTTPS آشکار میشد. این دو در کنار هم، دو روزنهٔ مهم برای مشاهدهٔ وبگردی شما را میبندند.
بااینحال، شرکت ارائهدهندهٔ اینترنتتان هنوز میتواند نشانیهای IP مقصد دستگاه شما را ببیند و وبسایتهایی که بازدید میکنید نیز همچنان نشانی IP شما را میبینند. در برخی موارد، همین نشانیهای IP و سرنخهای دیگر میتوانند مقصد ترافیکتان را آشکار کنند یا دستکم دامنهٔ احتمالات را کاهش دهند. پس DNS رمزگذاریشده و ECH ردیابی را دشوارتر میکنند، اما بهاندازهٔ VPN از حریم خصوصی شما محافظت نمیکنند.
محل فعالکردن DNS رمزگذاریشده نیز اهمیت دارد. برای نمونه، اگر «DNS امن» را فقط در Chrome فعال کنید، تنها Chrome از این محافظت بهرهمند میشود و برنامههای دیگر ممکن است همچنان تنظیمات عادی DNS دستگاه را به کار ببرند. «DNS خصوصی» در Android پوشش گستردهتری دارد، زیرا در سطح سیستمعامل اعمال میشود؛ هرچند برنامههایی که خودشان DNS را مدیریت میکنند، ممکن است همچنان رفتار متفاوتی داشته باشند.
بنابراین، تنها نشانی DNS شرکت اینترنتی خود را عوض نکنید و تصور نکنید کار تمام شده است. ارائهدهندهٔ DNS مورد اعتمادی برگزینید و سپس مطمئن شوید واقعاً از گزینهای رمزگذاریشده استفاده میکنید، نه DNS معمولی با متن ساده.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Oluwademilade Afolabi است. مشاهده مقاله اصلی