DNS روی TLS به همراه VPN: کدام بخش محافظت می‌شود
DoT گام تا یک resolver انتخابی را رمزنگاری می‌کند، نه خود نام را. چهار بررسی: هویت resolver، مسیر عبور، نام‌های داخلی و جایگزین.
DNS روی TLS تبادل میان کلاینت و resolverی را که انتخاب کرده رمزنگاری می‌کند و resolver همچنان نام را می‌خواند. این جمله بیشتر سردرگمی پیرامون DoT به همراه VPN را حل می‌کند. تونل تعیین می‌کند پرس‌وجوی رمزنگاری‌شده از کدام مسیر می‌رود، در حالی که resolver همچنان می‌فهمد چه چیزی پرسیده شده است. هیچ‌کدام جایگزین دیگری نیست و هیچ‌کدام دیگری را زائد نمی‌کند.
چهار بررسی تعیین می‌کند آیا ترتیبی که دارید همان چیزی است که فکر می‌کنید دارید.
بررسی 1: رمزنگاری چه چیزی را پوشش می‌دهد
DoT تبادل DNS را در TLS می‌پیچد، بنابراین ناظری روی مسیر به‌جای نامی در پرس‌وجو، اتصالی به یک نشانی و درگاه می‌بیند. خود resolver رمزگشایی می‌کند و پاسخ می‌دهد. آن را با DNS روی HTTPS مقایسه کنید: هر دو رمزنگاری می‌کنند و از حامل‌های متفاوتی استفاده می‌کنند، بنابراین شبکه‌ای که ترافیک وب را مجاز می‌کند به‌طور خودکار اتصال DoT را مجاز نمی‌کند.
این تفاوت وقتی مهم می‌شود که یک پورتال اسیر یا یک جعبه میانی فیلترکننده درگاه 443 را مجاز کند و 853 را مسدود کند. ابزاری که آنجا کار کرد مدرکی نیست بر اینکه دیگری کار خواهد کرد.
بررسی 2: پرس‌وجو از کدام مسیر می‌رود
مسیر پرسشی از سیاست کلاینت است. به resolver DoT می‌توان از طریق تونل، بیرون از آن، یا از مسیری که با شبکه تغییر می‌کند رسید. اینکه کدام رخ دهد به مسیرها و به این بستگی دارد که آیا کلاینت از سوکت DNS خودش محافظت می‌کند. تونلی که همه ترافیک را می‌گیرد معمولاً پرس‌وجو را با خود می‌برد، هر چه نشانی resolver بگوید.
دیدن نشانی resolver شخص ثالث در یک آزمون دور زدن را اثبات نمی‌کند، و دیدن رمزنگاری گیرنده موردنظر را اثبات نمی‌کند. resolver و مسیر را جداگانه بخوانید، سپس تصمیم بگیرید آیا این جفت همان چیزی است که طراحی کرده‌اید.
بررسی 3: نام‌های داخلی
سازمانی که نام‌های داخلی منتشر می‌کند به resolverی نیاز دارد که آن رکوردها را نگه دارد. یک سرویس DoT عمومی فضای نام خصوصی شما را نمی‌شناسد و نشانه‌رفتن کلاینت به یکی از آن‌ها تضمین می‌کند که آن نام‌ها شکست بخورند. این رایج‌ترین پس‌رفت عملی است وقتی کسی DNS رمزنگاری‌شده را روی دستگاه مدیریت‌شده فعال می‌کند.
resolver داخلی را برای پسوندهای داخلی نگه دارید و اگر سیاست لازم می‌داند آن گام را رمزنگاری کنید، به‌جای جایگزین کردن آن با یک ارائه‌دهنده عمومی.
بررسی 4: رفتار در خطا
تنظیم سخت‌گیرانه resolver بدون resolver قابل‌دسترس، خطای تحلیل نام تولید می‌کند در حالی که تونل بالا می‌ماند. به حالت سکو و جایگزین مستند آن نگاه کنید نه اینکه به کلیدها یا گواهی‌ها دست بزنید.
جایگزینی که بی‌صدا از DNS ساده استفاده می‌کند تصمیمی سیاستی است، نه یک راحتی. تصمیم بگیرید که آیا خطا باید دیده شود یا باید به چیزی ضعیف‌تر تنزل کند، و پاسخ را بنویسید.
به گواهی اعتماد کنید، نه به پاسخ
از نام میزبان ارائه‌دهنده و پیکربندی تأییدی که برای سرویس مستند شده استفاده کنید. غیرفعال کردن بررسی‌های TLS تا resolver ناآشنایی پاسخ دهد، کانال رمزنگاری‌شده‌ای به یک نقطه پایانی تأییدنشده می‌دهد، که از پرس‌وجوی ساده‌ای که جایگزینش شد از یک جهت مشخص بدتر است: امن به نظر می‌رسد. مشخصات DNS روی TLS انتظار احراز هویت را که پشت آن بررسی است بیان می‌کند.
پاسخی از resolverی که نمی‌توانید احراز هویت کنید یک ادعاست، نه یک نتیجه.
این چه چیزی را توضیح‌نشده می‌گذارد
DoT نام را از resolver پنهان نمی‌کند، نشانی مقصد اتصال را از شبکه پنهان نمی‌کند و تعیین نمی‌کند که آیا پرس‌وجو از تونل گذشته است. این‌ها سه پرسش جدا با سه پاسخ جدا هستند.
هویت resolver، مسیر عبور و سیاست نام‌های داخلی را در سه خط بنویسید. پرسش بعدی DNS که دریافت می‌کنید یکی از آن‌ها خواهد بود.