گزارش‌های حل‌کننده DNS در برابر گزارش‌های اتصال VPN: هرکدام چه چیزی نگه می‌دارد
حل‌کننده نام‌هایی را ثبت می‌کند که برای پاسخ دادن به آن‌ها پرسیده شده است؛ VPN رویدادهای تونل را از پیاده‌سازی خود ثبت می‌کند. یک سیاست نگهداری دیگری را پوشش نمی‌دهد.
گزارش حل‌کننده DNS و گزارش اتصال VPN هر دو گزارش شبکه‌اند، هر دو سودمندند و جای یکدیگر را نمی‌گیرند. حل‌کننده نام‌هایی را دریافت می‌کند که برای پاسخ دادن به آن‌ها پرسیده شده است. نقطه پایان VPN اتصال‌های تونل را مدیریت می‌کند و هر آنچه پیاده‌سازی‌اش برگزیده درباره آن‌ها ثبت کند می‌نویسد. می‌توانند در یک ساختمان باشند، یک تیم آن‌ها را اداره کند و یک اطلاعیه حریم خصوصی آن‌ها را پوشش دهد، و باز هم رویدادهای متفاوتی با شناسه‌های متفاوت و نگهداری متفاوت را توصیف می‌کنند. خواندن یکی به گمان آنکه دیگری است، همان راهی است که تحقیقات از مسیر بیرون می‌رود.
دو گزارش، دو رویداد
یک ورودی حل‌کننده به پرسشی درباره نام‌گذاری پاسخ می‌دهد: این کارخواه در این زمان این نام را خواست و پاسخ این بود. یک ورودی VPN به پرسشی درباره اتصال‌پذیری پاسخ می‌دهد: این همتا تونلی برقرار کرد یا از دست داد، این نشانی به آن داده شد و پیش از رفتن تقریباً این حجم داده را منتقل کرد. هیچ‌یک ثبت آنچه کاربر درون یک نشست HTTPS کرد نیست و هیچ‌یک جای دیگری را نمی‌گیرد.
این تمایز پیامد عملی برای وعده‌ها دارد. این گفته که فراهم‌کننده VPN فعالیت تونل را ثبت نمی‌کند هیچ چیزی درباره حل‌کننده‌ای که تحویل می‌دهد نمی‌گوید، و سیاست نگهداری یک حل‌کننده هیچ چیزی درباره اینکه چه کسی به تونل وصل شد نمی‌گوید. هر ادعا به گرداننده و سامانه خودش تعلق دارد.
پیش از خواندن هرکدام از دو گزارش، پرس‌وجو را دنبال کنید
یک پرس‌وجو تنها زمانی به حل‌کننده می‌رسد که مسیر واقعاً از آن بپرسد. یک برنامه می‌تواند از حل‌کننده سیستم‌عامل استفاده کند، کارخواه DNS رمزنگاری‌شده خودش را اجرا کند، یا پاسخی ذخیره‌شده را بخواند و هرگز چیزی نفرستد. پس گزارشی از حل‌کننده که چیزی نشان نمی‌دهد دلیل آن نیست که نامی هرگز به کار نرفته است؛ دلیل آن است که از این حل‌کننده پرسیده نشده است.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerآن فرمان آخر گزارش روزانه خودِ حل‌کننده محلی را می‌خواند، که همان گزارش کارساز بالادستی نیست. اگر پرس‌وجوهای شما از راه DNS over HTTPS به یک فراهم‌کننده بیرون بروند، ممکن است واسط محلی چیزی نشان ندهد در حالی که فراهم‌کننده گزارش کامل را دارد، و فراهم‌کننده گرداننده‌ای دیگر با سیاستی دیگر است.
هر گزارش چه چیزی را می‌تواند و چه چیزی را نمی‌تواند نشان دهد
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
پیوند دادن آن‌ها همان کار واقعی است و پیوند دادنشان همیشه ممکن نیست. حل‌کننده‌ای که نشانی کارخواه‌ها را ثبت می‌کند را می‌توان با VPNای مقایسه کرد که نشانی‌ها را از مجموعه‌ای شناخته‌شده تخصیص می‌دهد، و آن مقایسه پیوندی باورپذیر میان یک نام پرسیده‌شده و یک تونل می‌سازد، که همچنان پیوندی میان دو گزارش است نه گزارشی از یک شخص.
DNS رمزنگاری‌شده حمل‌ونقل را عوض می‌کند، نه دیدپذیری در نقطه پایان را. حل‌کننده هنوز پرسشی را که به آن پاسخ می‌دهد دریافت می‌کند، همان‌طور که RFC 8484 روشن می‌سازد، و نگهداری در آن حل‌کننده تصمیمی سیاستی است نه ویژگی‌ای از پروتکل.
جایی که DNS تقسیم‌شده و حافظه‌های موقت داستان را پیچیده می‌کنند
چند حل‌کننده امری عادی است. طراحی DNS تقسیم‌شده نام‌های درونی را به کارساز درونی و بقیه را به کارساز عمومی می‌فرستد، پس یک تحقیق می‌تواند دو گزارشی را درگیر کند که هرگز برای ترکیب شدن در نظر گرفته نشده بودند و دو تنظیم نگهداری که هرگز برای مقایسه شدن در نظر گرفته نشده بودند. دیدن پرس‌وجوها در هر دو نشانه کارکرد طراحی است، نه نشانه نشت.
حافظه‌های موقت در جهت دیگر می‌برند. نامی پرطرفدار ممکن است ساعت‌ها از حافظه موقت پاسخ بگیرد، پس گزارش حل‌کننده نخستین پرس‌وجو و سپس هیچ چیز را نشان می‌دهد، در حالی که برنامه کاربر همچنان با خوشی همان نام را بازمی‌کاود. نبودِ ورودی پس از زمانی معین به آن معنا نیست که هیچ‌کس پس از آن زمان نام را به کار نبرده است.
ترافیک پس‌زمینه سومین اعوجاج است. تلفنی که هنگام راه‌اندازی نامی برای سنجش از دور بازمی‌کاود، مرورگری که دامنه پیشنهاد جست‌وجو را بازمی‌کاود، و به‌روزرسانی که هر ساعت تماس می‌گیرد، همگی در گزارش حل‌کننده در کنار نامی که واقعاً برایتان مهم است پدیدار می‌شوند. حجم در آن گزارش توجه نیست و شمردن پرس‌وجوها شمردن بازدیدها نیست. گزارش حل‌کننده گزارشی از پرسش‌هاست و ساختن پرسش ارزان است.
پرسش‌های نگهداری را جداگانه بپرسید
برای هر سامانه سه پرسش بپرسید: چه کسی گردآوری می‌کند، چه چیزی گردآوری می‌شود، و چه مدت نگه داشته می‌شود. سپس بپرسید چه کسی می‌تواند آن را بخواند و با چه فرایندی. بحث RFC 8484 درباره DNS over HTTPS یادآور خوبی است که حمل‌ونقل رمزنگاری‌شده نقطه پایان را برنمی‌دارد، و مستندات خودِ گرداننده تنها گزاره قابل اعتماد درباره آن است که آن نقطه پایان چه چیزی نگه می‌دارد.
وقتی ادعایی درباره حریم خصوصی درباره «VPN» مطرح می‌شود، پیش از پذیرفتن آن را به اجزا بشکافید: گرداننده تونل، حل‌کننده‌ای که تونل تحویل می‌دهد، هر حل‌کننده بالادستی که این پرس‌وجوها به آن می‌رسند، و برنامه‌های روی دستگاه. هر یک پاسخ خودش را دارد، و ادعایی که برای یکی درست است به‌طور معمول چنان تکرار می‌شود که گویی هر چهار را پوشش می‌دهد.
برای عیب‌یابی، از همان تقسیم‌بندی استفاده کنید. بپرسید کدام برنامه پرس‌وجو را ساخت و کدام حل‌کننده به آن پاسخ داد، سپس به گزارشی نگاه کنید که واقعاً مالک آن رویداد است. حدس زدن از گزارش دیگر یک دقیقه صرفه‌جویی می‌کند و یک بعدازظهر هزینه دارد.