گزارش DNS در VPN: چه چیزی را بگنجانیم تا قابل بازتولید باشد
گزارش مفید DNS دستهٔ خطا، مسیر resolver و پاسخ دقیق را نام می‌برد. فضای نام را پنهان کنید و روابطی را که آن را توضیح می‌دهند نگه دارید.
«DNS خراب است» یک نتیجه‌گیری است و نتیجه‌گیری‌ای نیست که کمک‌کننده بتواند بر اساس آن کاری انجام دهد. بخش مفید گزارش، شکل خطاست: کدام نام، از طریق کدام resolver، با کدام پاسخ. سه جزئیات شکایت را به چیزی قابل بازتولید تبدیل می‌کند و هر سه پس از تغییر نام بخش‌های خصوصی برای اشتراک‌گذاری بی‌خطرند. آنچه در پی می‌آید کمینه‌ای است که یک گزارش DNS در VPN پیش از آنکه کسی بتواند کمک کند نیاز دارد.
دستهٔ نام، نه حکم
با خود نام شروع کنید و آن را دسته‌بندی کنید: عمومی، داخلی، کوتاه، کاملاً واجد شرایط، یا تحت سرویس یک پسوند مشخص. نام داخلی‌ای که شکست می‌خورد در حالی که نام‌های عمومی حل می‌شوند، به انتخاب resolver اشاره دارد نه به دسترس‌پذیری. اگر همهٔ نام‌ها شکست بخورند، این به مسیر رسیدن به resolver اشاره دارد که تحقیقی متفاوت با شواهد متفاوت است. دسته تشخیص را حمل می‌کند و رشتهٔ دقیق را می‌توان پنهان کرد.
بگویید آیا خطا به برپا بودن تونل نیاز دارد یا پس از قطع آن رخ می‌دهد. نامی که فقط وقتی VPN فعال است می‌شکند به پیکربندی هر پیوند اشاره دارد، و نامی که پس از قطع شدن می‌شکند به وضعیت باقی‌مانده. گزارش‌ها معمولاً این را حذف می‌کنند و بعد می‌پرسند چرا پیشنهاد اول کمک نمی‌کند.
مسیر resolver را ثبت کنید
پرسشی که به یک سرور صریحاً انتخاب‌شده فرستاده می‌شود و جستجوی معمول یک برنامه دو آزمایش متفاوت‌اند. بگویید کدام یک خطا را ایجاد کرد، چون پرسش دستی از یک سرور کارکننده فقط ثابت می‌کند که سرور کار می‌کند. دستورهای زیر مسیر سیستم را از یک پرسش مستقیم جدا می‌کنند.
resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53خروجی وضعیت سرورهای هر پیوند و دامنه‌های مسیریابی را نام می‌برد، که همان جایی است که split DNS تصمیم گرفته می‌شود. فراخوانی getent همان مسیری را طی می‌کند که برنامه طی می‌کند، از جمله ترتیب nsswitch. پرسش مستقیم هر دو را دور می‌زند و یک سرور را جداگانه آزمایش می‌کند. بگویید کدام یک از سه شکست خورد و کدام موفق شد، و خواننده دیگر لازم نیست مسیر را حدس بزند.
مقایسهٔ کنترل‌شده را بیان کنید
یک متغیر را تغییر دهید و بگویید چه چیزی عوض شد. حل شدن نام‌های عمومی در حالی که نام‌های داخلی شکست می‌خورند یک مشکل انتخاب است؛ تمام شدن زمان همهٔ نام‌ها یک مشکل مسیر است؛ و نام خصوصی‌ای که به نشانی عمومی حل می‌شود نشت به resolver اشتباه است. دو مورد از این سه هیچ ارتباطی با برپا بودن تونل ندارند. گزارشی که ادعا می‌کند همهٔ پرسش‌ها خراب‌اند معمولاً مقایسه‌ای دارد که هرگز اجرا نشده است.
حل کردن را از تحویل جدا کنید. وقتی نام حل می‌شود و سایت هنوز شکست می‌خورد، مرحلهٔ DNS موفق بوده و گزارش باید این را بگوید، چون گام بعدی یک مسیر یا یک شنونده است نه یک resolver. همین یک تمایز بیشتر از هر بخش از گزارش، یک دور پرسش را صرفه‌جویی می‌کند.
فضای نام را پنهان کنید، روابط را نگه دارید
نام‌های داخلی را می‌توان جایگزین کرد، به شرط آنکه جایگزین‌ها ساختار را حفظ کنند. هر سرور و پسوند متمایز را به برچسبی پایدار نگاشت کنید و آن نگاشت را بیرون از نسخهٔ مشترک نگه دارید. جایگزین کردن هر میزبان داخلی با همان نگه‌دارنده دقیقاً شواهدی را نابود می‌کند که گزارش نیاز دارد، چون خواننده دیگر نمی‌تواند ببیند یک پسوند حل شد و دیگری نشد. همین قاعده برای نشانی‌ها هم صادق است: روابط پیشوند را نگه دارید و اگر سیاست می‌خواهد بیت‌های میزبان را تغییر دهید.
رکورد را از کانال تأییدشده بفرستید و آنچه را تشخیص هرگز لازم ندارد بیرون بگذارید. گذرواژه‌ها، کلیدهای خصوصی و نام شرکت‌های بی‌ربط بخشی از پرسش DNS نیستند. آنچه خواننده لازم دارد دستهٔ خطا، مسیر resolver، خطای دقیق و همان یک مقایسه‌ای است که اجرا کردید.