DNS رمز‌نگاری‌شده بدون VPN پرس‌وجو را پنهان می‌کند، نه نشانی شما را

آزمون نشتی DNS که شبکه خانگی شما را نشان می‌دهد شاهدی بر شکست DNS رمز‌نگاری‌شده نیست و شاهدی بر موفقیت چیزی هم نیست. آزمون به یک پرسش پاسخ می‌دهد: این پرس‌وجو از این شبکه به کدام resolver رسید. اینکه این مشکل باشد بستگی دارد به اینکه از چه و از چه کسی محافظت می‌کردید.

پیش از اجرای هر آزمونی هدف را بنویسید.

گام 1: محافظتی را که واقعاً می‌خواهید نام ببرید

سه هدف با هم اشتباه می‌شوند. ممکن است بخواهید ناظری در مسیر خواندن پرس‌وجوها را متوقف کند. ممکن است بخواهید resolver مشخصی دریافت آنها را متوقف کند. ممکن است بخواهید وب‌سایت‌هایی که بازدید می‌کنید دیدن نشانی خانگی شما را متوقف کنند. DNS رمز‌نگاری‌شده به هدف اول خدمت می‌کند، تغییر می‌دهد چه کسی دومی را برآورده می‌کند، و برای سومی هیچ کاری نمی‌کند.

VPN به هدف سوم و بسته به ارائه‌دهنده به هدف اول خدمت می‌کند. هیچ‌یک از این دو ابزار ابرمجموعه دیگری نیست.

گام 2: یک resolver انتخاب کنید و هویت آن را بررسی کنید

DNS over TLS پرس‌وجو را در یک نشست TLS با resolver می‌پیچد و DNS over HTTPS آن را در یک درخواست HTTP می‌پیچد؛ RFC 7858 و RFC 8484 هر دو را توصیف می‌کنند و هیچ‌کدام به تونل نیاز ندارد. آنچه عملیاتی مهم است این است که گواهی در برابر نامی که پیکربندی کرده‌اید بررسی شود، زیرا نشست رمز‌نگاری‌شده با طرف اشتباه بدتر از متن ساده با طرف درست است. این یعنی حالت سخت‌گیرانه هر جا که بستر ارائه می‌دهد، نه حالت فرصت‌طلبانه که وقتی بررسی شکست می‌خورد عقب می‌نشیند. پیش از اعتماد به تنطیم، نشست را مستقیم بررسی کنید: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

دست‌دادن باید resolverی را که پیکربندی کرده‌اید نام ببرد و زنجیره‌ای برگرداند که بتوانید بررسی کنید.

گام 3: رفتار در شکست را تعیین کنید

هر پیاده‌سازی سیاستی برای resolver رمز‌نگاری‌شده غیرقابل‌دسترس دارد و همان سیاست تصمیم حریم خصوصی است. حالت سخت‌گیرانه جست‌وجو را شکست می‌دهد، که آشکار و آزاردهنده است. حالت فرصت‌طلبانه با متن ساده دوباره تلاش می‌کند، که نامرئی است و هدف را دقیقاً در روزی که اهمیت دارد از بین می‌برد. آگاهانه انتخاب کنید و سپس انتخاب را کنار نیازمندی ثبت کنید.

در systemd-resolved این یعنی DNSOverTLS=yes نه opportunistic؛ و در Android یعنی حالت نام میزبان Private DNS به‌جای خودکار.

با این بررسی کنید که واقعاً چه چیزی اعمال می‌شود: resolvectl status | grep -i -A1 "dns over tls"، چون فایل drop-inی که هرگز دوباره بارگذاری نشده چیزی را تغییر نمی‌دهد.

گام 4: بررسی کنید که برنامه‌ها از resolver سیستم پیروی می‌کنند

مرورگری که تنطیم DNS امن خودش را دارد پیکربندی سیستم را کاملاً دور می‌زند، و همچنین runtime کانتینری با resolver جاسازی‌شده یا runtime زبانی که فهرستی سخت‌کدشده را می‌خواند. یا آنها را وادار کنید از سیستم پیروی کنند یا صریحاً پیکربندی کنید و ثبت کنید. سپس رفتار عقب‌نشینی هرکدام را ببینید، چون همه آنها به صورت بسته شکست نمی‌خورند. فهرست در عمل کوتاه است: مرورگر، runtime کانتینر و هر کلاینت VPNی که شما هم اجرا می‌کنید.

نام‌های خصوصی سازمان روی resolver داخلی تأییدشده می‌مانند. فرستادن آنها به سرویس عمومی تا آزمون مرتب به نظر برسد، عمداً مشکل دیگری می‌سازد.

گام 5: آزمون نشتی را در برابر نیازمندی بخوانید

آزمونی که resolver غیرمنتظره گزارش می‌کند یک نشانه است، نه حکم. ممکن است resolver رمز‌نگاری‌شده موردنظر شما، تنطیمی مخصوص یک برنامه، یا عقب‌نشینی به متن ساده‌ای را که نمی‌دانستید مشاهده کرده باشد. resolver گزارش‌شده را با آنچه گام 2 پیکربندی کرد مقایسه کنید و نتیجه را با هدف گام 1 بسنجید.

اگر هدف دور نگه داشتن پرس‌وجوها از شبکه محلی بود، آزمونی که resolver معمولی شما را نشان می‌دهد یافته‌ای واقعی است. اگر هدف ناشناس ماندن هنگام مرور بود، هیچ تنطیم DNSای هرگز آن را فراهم نمی‌کرد.

خط پذیرش را به زبان هدف بنویسید: این جست‌وجوها تحت این شرایط از این resolver تأییدشده استفاده می‌کنند. هر چیزی گسترده‌تر ادعایی است که نمی‌توانید بیازمایید.