سبد خرید شما خالی است.
تفاوت DNS over HTTPS و DNS over TLS: امنیت و سرعت
6دقیقه
آنچه در این مقاله میخوانید [پنهانسازی]
پاسخ کوتاه: تفاوت DNS over HTTPS و DNS over TLS از نظر امنیت و سرعت مطلق نیست. هر دو محتوا و رکوردهای DNS را با TLS رمزنگاری میکنند. از نظر امنیت شبکه، DoH به دلیل استفاده از پورت 443 سختتر شناسایی و مسدود میشود، اما هر دو سطح حفاظت مشابهی روی متن پرسوجو ارائه میدهند. از نظر سرعت، در شبکههای پایدار DoT معمولا اندکی سبکتر است، ولی DoH با HTTP/2 یا HTTP/3 روی لینکهای پرنوسان و موبایل میتواند عملکرد بهتری داشته باشد. انتخاب درست به شرایط شبکه، ابزار کلاینت و سیاست سازمانی شما بستگی دارد.
تصویر کلی: DoH و DoT دقیقا چه میکنند؟
هر دو فناوری جایگزین DNS سنتی روی پورت 53 هستند و پرسوجو/پاسخ DNS را داخل تونل TLS منتقل میکنند. تفاوت در لایه بالاتر است: DoT مستقیما DNS را روی TLS (پورت 853) میفرستد؛ DoH همان پیام DNS را داخل درخواست/پاسخ HTTP(S) روی پورت 443 کپسوله میکند. نتیجه در هر دو حالت این است که محتوای پرسوجوها از دید ناظر شبکه خوانا نیست.
مقایسه سریع
| معیار | DNS over HTTPS (DoH) | DNS over TLS (DoT) |
|---|---|---|
| پروتکل حمل | HTTP/2 یا HTTP/3 روی TLS | TLS روی TCP (پورت 853) |
| قابلیت مسدودسازی | دشوارتر؛ روی پورت 443 پنهان میشود | آسانتر؛ پورت 853 قابل تشخیص است |
| Multiplexing | بله (HTTP/2/3) | نه (هر اتصال TLS جریان واحد) |
| Overhead پروتکلی | بیشتر بهخاطر HTTP | کمتر؛ مستقیم روی TLS |
| عملکرد روی شبکه ناپایدار | اغلب بهتر (بهخصوص با HTTP/3/QUIC) | پایدار در شبکههای تمیز؛ حساستر به از دست رفتن بسته |
| سازگاری با ابزارها | پیادهسازی آسان در مرورگرها | پیکربندی ساده در سطح سیستم/شبکه |
امنیت: دقیقا چه چیزی پنهان میشود و چه چیزی نمیشود؟
پاسخ مستقل: هر دو روش محتوای پرسوجو و پاسخ DNS را از دید شبکه پنهان میکنند، اما آدرس IP سرور ریزالور و حجم/الگوی ترافیک همچنان قابل مشاهده است.
- محتوای رمزنگاریشده: نام دامنه پرسوجو (QNAME)، نوع رکورد، و پاسخها.
- قابل مشاهده برای ناظر شبکه: IP مقصد، زمانبندی بستهها و اندازه کلی ترافیک. نام دامنه سرور هم اگر با SNI ست شود ممکن است دیده شود.
- نکته مهم: ریزالور مقصد (سرویسدهنده DNS شما) همچنان پرسوجوها را به صورت رمزگشاییشده میبیند. این روشها شما را در برابر خود ریزالور «ناشناس» نمیکنند؛ باید به سیاستهای حریم خصوصی سرویسدهنده اعتماد کنید.
- مسدودسازی و فیلترینگ: DoT به دلیل پورت اختصاصی 853 بهراحتی شناسایی و مسدود میشود. DoH به دلیل استفاده از 443 (همانند وب عادی) کمتر جلب توجه میکند و در بسیاری از شبکهها عبور میکند.
- کنترل سازمانی: در شبکههای سازمانی، فعالسازی DoH در سطح مرورگر ممکن است سیاستهای DNS داخلی را دور بزند. DoT بهصورت متمرکز در گیتوی یا سیستمعامل قابل مدیریتتر است.
سرعت: چرا «همیشه سریعتر» نداریم؟
پاسخ مستقل: سرعت به کیفیت شبکه، قابلیت نگهداری اتصال، و پیادهسازی کلاینت/سرور بستگی دارد. DoT سبکتر است، DoH قابلیتهای بهینهسازی حمل را دارد.
عوامل موثر به نفع DoT
- کمهزینهتر بودن پروتکلی: بدون سربار HTTP، پیام DNS مستقیم روی TLS ارسال میشود.
- سادهسازی پیادهسازی: مسیر کوتاهتر پردازش در کلاینت/سرور میتواند تاخیر را اندکی کاهش دهد.
عوامل موثر به نفع DoH
- Multiplexing: چند پرسوجو بهصورت همزمان روی یک اتصال فعال میشوند، بدون نیاز به ایجاد اتصالهای متعدد.
- HTTP/3 روی QUIC: بازیابی بهتر در برابر از دست رفتن بسته و جابجایی اتصال در شبکههای موبایل، که میتواند تاخیر تجربهشده را کاهش دهد.
- Reuse اتصال وب: در برخی سناریوها، کلاینت میتواند از ارتباطات HTTPS موجود به همان میزبان بهره ببرد.
معیار انتخاب: در چه شرایطی کدام بهتر است؟
- اگر شبکه شما محدودکننده است و DoT روی پورت 853 مسدود میشود: DoH انتخاب عملیتری است.
- اگر مدیریت متمرکز در سطح سیستم/سازمان میخواهید و امکان اجازه روی پورت 853 دارید: DoT شفاف و قابلکنترل است.
- اگر کاربران شما بیشتر در شبکههای موبایل و پرنوسان هستند: DoH (ترجیحا با پشتیبانی HTTP/3) میتواند تجربه پایدارتری بدهد.
- اگر به کمترین سربار پروتکلی و سادگی مسیر نیاز دارید: DoT معمولا پاسخگو است.
- در هر دو حالت: ریزالوری را انتخاب کنید که از ویژگیهای امنیتی تکمیلی مانند QNAME minimization و اعتبارسنجی DNSSEC پشتیبانی میکند.
چطور مطمئن شویم واقعا DoH/DoT فعال است؟
دو روش عملی: مشاهده جزئیات TLS و اجرای پرسوجوی آزمایشی با ابزارهای سازگار.
بررسی سریع با kdig
kdig (از مجموعه Knot DNS) هم DoT و هم DoH را پشتیبانی میکند. با دستورات زیر، نوع اتصال و «Query time» را خواهید دید.
# DoT نمونه با Cloudflare
kdig @tls://1.1.1.1 example.com A +tls-hostname=cloudflare-dns.com -d
# DoT نمونه با Google
kdig @tls://dns.google example.com A -d
# DoH نمونه با Cloudflare
kdig @https://cloudflare-dns.com/dns-query example.com A -d
# DoH نمونه با Google
kdig @https://dns.google/dns-query example.com A -d
خروجی دارای خطوطی درباره TLS handshake است که نشان میدهد ارتباط برقرار شده و رشته «Query time» زمان تقریبی پاسخ را نمایش میدهد.
مشاهده دستدهی TLS با openssl (برای DoT)
برای اطمینان از باز بودن پورت 853 و مشاهده گواهی:
openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com اگر دستدهی موفق باشد، اطلاعات گواهی و Cipher به شما نشان داده میشود. بسته به ریزالور، ممکن است برای اعتبارسنجی نام میزبان به servername نیاز داشته باشید.
سنجش عملی تاخیر: یک تست کوتاه
برای مقایسه نسبی تاخیر در شبکه خودتان، چند بار پرسوجو را تکرار و میانگین را مقایسه کنید. این اعداد به مسیر شبکه شما وابستهاند و قطعی نیستند.
# 5 بار پرسوجو DoT
for i in {1..5}; do kdig @tls://1.1.1.1 example.com A +tls-hostname=cloudflare-dns.com | grep "Query time"; done
# 5 بار پرسوجو DoH
for i in {1..5}; do kdig @https://cloudflare-dns.com/dns-query example.com A | grep "Query time"; done
اگر اتصال برقرار است و کش محلی تاثیر نگذاشته، میتوانید برای خنثیسازی کش، هر بار نامهای متفاوتی را تست کنید یا پارامترهای ضدکش استفاده کنید. برای نتیجه بیطرفانهتر، تست را در چند بازه زمانی و با چند ریزالور تکرار کنید.
نکات عملی امنیتی
- تایید گواهی: چه در DoH و چه در DoT، کلاینت باید گواهی معتبر ریزالور را تایید کند. تنظیم به IP بدون اعتبارسنجی نام گواهی میتواند شما را در برابر حمله مرد میانی آسیبپذیر کند.
- انتخاب ریزالور معتبر: رمزنگاری مسیر، مشکل اعتماد به ریزالور را حل نمیکند. سیاست حریم خصوصی و قابلیتهای امنیتی ریزالور را بررسی کنید.
- سیاست سازمانی: تصمیم بگیرید DNS رمزنگاریشده در سطح سیستم پیادهسازی شود یا فقط در برنامهها (مثل مرورگر). ناسازگاری این دو میتواند عیبیابی شبکه را دشوار کند.
خطاها و سوءبرداشتهای رایج
- «DoH/DoT ناشناسی کامل میدهد»: نادرست. محتوا در مسیر رمز میشود، اما ریزالور مقصد همه پرسوجوها را میبیند.
- «DoH همیشه سریعتر است» یا «DoT همیشه سریعتر است»: نادرست. تفاوت به شرایط شبکه، پیادهسازی، کش و فاصله تا ریزالور بستگی دارد.
- فعالسازی DoH در مرورگر و انتظار تبعیت کل سیستم: نادرست. برنامههای دیگر ممکن است همچنان از DNS سنتی استفاده کنند مگر اینکه در سطح سیستم DoT/DoH تنظیم شود.
کدام گزینه مناسبتر است؟
اگر اولویت شما عبور قابل اعتماد از شبکههای محدود و سازگاری خوب با مرورگرهاست، DoH عملیتر است. اگر مدیریتپذیری در سطح سیستم و سربار کمتر میخواهید و پورت 853 مشکلی ندارد، DoT شفاف و کمهزینه است. در هر دو حالت، یک ریزالور مطمئن انتخاب کنید و با روشهای بالا صحت رمزنگاری و تاخیر را در شبکه خود بسنجید.
