به VPN وصل شوید، nslookup را اجرا کنید و سرصفحه نشانی resolver را با فیلد نام که با Unknown پر شده نشان می‌دهد. آن واژه بالای پاسخ می‌نشیند و بیشتر مردم پیش از بخش مهم خواندن را رها می‌کنند. برچسب توصیف می‌کند که آیا resolver نام معکوس خودش را دارد؛ هنوز هیچ نمی‌گوید که نام میزبان مورد پرسش شما حل شده است یا نه. بستن زودهنگام آن پنجره تمام مهارت اینجاست.

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

ابزار پیش از پاسخ دادن به شما چه می‌کند

nslookup ممکن است برای نشانی سروری که در آستانه استفاده از آن است نامی بیابد، که همان جست‌وجوی معکوس در دامنه in-addr.arpa یا ip6.arpa است. اگر آن رکورد PTR وجود نداشته باشد، با سیاستی فیلتر شده باشد یا به‌سادگی منتشر نشده باشد، ابزار Unknown را چاپ می‌کند و ادامه می‌دهد. حل رو به جلو از این شکست دست‌نخورده می‌ماند، چون پرسش دیگری است که به همان سرور فرستاده می‌شود.

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

دو پرس‌وجو را عمداً اجرا کنید

درباره میزبانی که برایتان مهم است بپرسید، سپس درباره نشانی خود resolver. درخواست اول نامی را که لازم دارید حمل می‌کند؛ دومی از سرور می‌پرسد آیا می‌تواند خودش را نام‌گذاری کند. وقتی نوشته شوند چنین به نظر می‌رسند: nslookup app.corp.example 10.77.0.53 برای میزبان و nslookup 10.77.0.53 10.77.0.53 برای نام معکوس resolver.

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

سه نتیجه که شبیه به هم‌اند و نیستند

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

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

بخش‌ها را بخوانید، نه سرصفحه را

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

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

وقتی نام معکوس واقعاً اهمیت دارد

بعضی سرویس‌ها واقعاً به رکوردهای PTR اهمیت می‌دهند: گزارش‌گیری که نشانی‌های کلاینت را حل می‌کند، بررسی‌های اعتبار ایمیل، یا ابزارهای اداری که نام‌ها را نمایش می‌دهند. اگر یکی از آن‌ها شکست بخورد، رکورد را منتشر کنید یا ناحیه‌ای را که باید آن را نگه دارد درست کنید. آن کار مشروع است و از این پرسش جدا است که آیا VPN پرس‌وجوها را درست منتقل می‌کند.

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

مقالات مرتبط