چه کسی 1.1.1.1 را اداره می‌کند؟ بررسی یک نشانی DNS پیش از اعتماد به آن
نشانی DNS که همراه VPN استفاده می‌شود لزوماً توسط همان VPN اداره نمی‌شود. حل‌کننده را مشخص کنید، سپس مسیر و سیاست نام‌های خصوصی را جداگانه بررسی کنید.
1.1.1.1 را در فیلد DNS وی‌پی‌ان چسباندید، صفحه بارگذاری شد و آموزش اکنون تأییدشده به نظر می‌رسد. این مشاهده باریک‌تر از آن است که حس می‌شود: برنامه طور دیگری رفتار کرد و تغییر هنوز چیزی درباره اینکه چه کسی به پرس‌وجو پاسخ داد یا چرا چیدمان قدیمی شکست خورد نمی‌گوید. آموزش کپی‌شده اغلب یک نشانی عمومی آشنا را «DNS وی‌پی‌ان» می‌نامد و این ادعایی درباره مالکیت است، نه درباره دسترسی. بررسی اینکه نشانی نماینده چیست پنج دقیقه وقت می‌گیرد و از تغییری دائمی که به دلیل اشتباه انجام شده جلوگیری می‌کند.
تنظیمی که کار می‌کند هویت نیست
نشانی در فیلد تنظیمات یک نقطه پایانی است و نقطه پایانی یک اپراتور دارد. این دو واقعیت جدا هستند و دومی همان است که مردم از آن می‌گذرند. برای جفتی که بیشتر از همه کپی می‌شود، پاسخ عمومی است: Cloudflare 1.1.1.1 و 1.0.0.1 را به عنوان نشانی‌های حل‌کننده خود منتشر می‌کند و آن‌ها را در مرجع رسمی نشانی‌ها خود فهرست می‌کند. به همین دلیل نام اپراتور کنار نشانی می‌آید، نه در آموزشی جداگانه.
وارد کردن آن جفت هنگام فعال بودن تونل، شرکت وی‌پی‌ان را اپراتور آن نمی‌کند و ترافیک را ناشناس نمی‌کند. پرس‌وجو ماشین شما را به سمت شرکتی ترک می‌کند که محدوده نشانی را منتشر می‌کند، و آن شرکت می‌تواند خوش‌نام باشد و در عین حال همان طرفی نباشد که آموزش به آن اشاره داشت. برچسب در دستورالعمل‌ها و اپراتور در واقعیت دو ادعای متفاوت هستند. هیچ‌یک نمی‌گوید مسیر شبکه میان آن‌ها را چه کسی اداره می‌کند.
برای تأیید یک جفت نشانی یا نقطه پایانی رمزنگاری‌شده از مرجع منتشرشده خود حل‌کننده استفاده کنید. توصیه یک فروشنده دیگر می‌تواند مشروع باشد و «توصیه‌شده توسط»، «دسترسی‌یافته از طریق» و «اداره‌شده توسط» هنوز سه رابطه متفاوت را توصیف می‌کنند.
سه چیزی را که یک رکورد لازم دارد مقایسه کنید
رکورد آماده بازبینی سه پرسش را جدا می‌کند: چه کسی باید پرس‌وجو را دریافت کند، تبادل ساده است یا رمزنگاری‌شده، و کدام مسیر باید آن را حمل کند. نام ارائه‌دهنده نمی‌تواند دومی یا سومی را پر کند و برچسب کشور نمی‌تواند هیچ‌یک را پر کند. سه مدخل را پیش از تغییر بنویسید و بعد آن‌ها را مقایسه کنید. آن مدخل‌ها جایگزین‌پذیر نیستند و برخورد با آن‌ها به عنوان یکی همان راهی است که یک گمان به مستند تبدیل می‌شود.
همین مقایسه است که تنظیم کارآمد را به تصمیمی مستند تبدیل می‌کند. بدون آن، نفر بعدی نشانی‌ای را به ارث می‌برد که هیچ دلیلی به آن پیوست نیست. ابتدا ستون سوم جدول زیر را بخوانید، چون بیشتر توضیحات مطمئن در واقع همان‌جا متوقف می‌شوند.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
جدول عمداً کوتاه است. نکته‌اش این است که هر مدخل به پرسش دیگری پاسخ می‌دهد و هیچ فیلد واحدی هر سه را پر نمی‌کند.
یک هدایتگر محلی منبع واقعی را پنهان می‌کند
دستگاهی که برای استفاده از روتر خود به عنوان DNS تنظیم شده، به یک هدایتگر اشاره می‌کند. آن نشانی گیرنده بعدی پرس‌وجو را مشخص می‌کند، نه حل‌کننده‌ای که در نهایت پاسخ می‌دهد. یک حل‌کننده stub محلی همان گام اضافه را می‌افزاید، و اشتباه گرفتن آن با چیز واقعی آسان است چون در هر خروجی وضعیت دیده می‌شود.
stub به منابعی هدایت می‌کند که همان خروجی نیز آن‌ها را فهرست می‌کند، معمولاً پایین‌تر. پیش از هر نتیجه‌ای درباره اپراتور، کل زنجیره را بخوانید، چون خط اول تمام پاسخ نیست. در غیر این صورت شما پذیرش را شرکت می‌نامید.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'فرمان دوم از نام پژواک حل‌کننده، جایی که اپراتور یکی منتشر می‌کند، برای گزارش نشانی مبدأیی که می‌بیند استفاده می‌کند. سومی سروری را که پاسخ داد نام می‌برد و این اغلب نشانی‌ای نیست که شما تنظیم کرده‌اید. پیش از نوشتن اپراتور، هر سه خروجی را مقایسه کنید.
DNS رمزنگاری‌شده آنچه دیده می‌شود را تغییر می‌دهد، نه آنکه چه کسی می‌بیند
DNS over HTTPS و DNS over TLS تبادل میان کارخواه و حل‌کننده را محافظت می‌کنند. حل‌کننده هنوز هر نامی را که پرسیده می‌شود می‌خواند، چون پاسخ دادن کار اوست. آنچه تغییر می‌کند این است که چه کسی می‌تواند تبادل را تماشا کند: شبکه محلی اتصالی به یک نقطه پایانی می‌بیند نه جریانی از پرس‌وجوهای متن ساده.
آنچه تغییر نمی‌کند رابطه اعتماد است که هنوز به سازمانی اشاره می‌کند که آن نقطه پایانی را اداره می‌کند. مرورگری با تنظیم DNS امن خود می‌تواند حل‌کننده سیستم‌عامل را کاملاً دور بزند. با آن‌ها مانند دو پیکربندی که می‌توانند ناسازگار باشند رفتار کنید، نه مانند یک تنظیم که دو بار اعمال شده است.
نام‌های خصوصی دوباره تصمیم خودشان را می‌خواهند. یک تونل کاری می‌تواند دامنه‌های انتخابی را به حل‌کننده‌های سازمانی هدایت کند و جایگزین کردن آن با یک سرویس عمومی می‌تواند جست‌وجوهای داخلی را بشکند یا نام‌های داخلی را به طرف اشتباه افشا کند. پیش از جایگزینی تنظیمات یک آداپتور کامل، سیاست دامنه‌ها را بررسی کنید.
مشاهده را باریک نگه دارید
هنگام مقایسه، پیکربندی قدیمی را حفظ کنید و هر بار یک تنظیم را تغییر دهید. برنامه، عملیات، سیاست حل‌کننده و اینکه آیا نام‌های عمومی و خصوصی مجاز پس از اتصال دوباره هنوز حل می‌شوند را ثبت کنید. مقایسه‌ای با دو تغییر هیچ‌یک را اثبات نمی‌کند. نتیجه را جایی بنویسید که نفر بعدی آن را پیدا کند، درست کنار خود تنظیم.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comاگر برنامه شروع به کار کرد، ادعا را تا آنجا که شواهد اجازه می‌دهد کوچک نگه دارید. آن تغییر به یک آزمون کمک کرد و هیچ نمی‌گوید که آیا حل‌کننده پیشین بدخواهانه عمل کرد، آیا تونل خراب بود یا آیا دستگاه دیگری به همان جایگزینی نیاز دارد. نتیجه پایدار پیکربندی‌ای است که اپراتور و هدف آن را می‌توانید توضیح دهید.