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

دو نام انتخاب کنید و اول هر دو پاسخ را پیش‌بینی کنید

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

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

پیش‌بینی را کنار پاسخ مشاهده‌شده در همان تیکت بنویسید. آزمایشی بدون پیش‌بینی نمی‌تواند شکست بخورد، و آزمایشی که نمی‌تواند شکست بخورد چیزی یاد نمی‌دهد.

مسیری را که برنامه استفاده می‌کند بیازمایید، نه سروری که خودتان انتخاب کرده‌اید

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

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

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

دسته پاسخ را ثبت کنید، نه فقط موفقیت یا شکست

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

پیش از تفسیر نبود یک پرس‌وجوی تازه، حافظه پنهان را در نظر بگیرید، چون پاسخ منفی نگه‌داشته‌شده در حافظه پنهان دقیقاً مانند نامی است که وجود ندارد. پاسخ را پیش از پاک کردن هر چیزی با ابزارهای پشتیبانی‌شده ثبت کنید، چون نخستین پاسخ همان مدرک است.

دو شاخه را بدون حدس تفسیر کنید

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

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

سپس نتیجه را با دو دسته‌ای که مشاهده کردید و نام‌های حذف‌شده به صاحب فضای نام بدهید. این گفت‌وگویی پنج‌دقیقه‌ای است به‌جای یک هفته گمانه‌زنی.

مقالات مرتبط