ثبت Split-DNS: بگویید هر مشاهده در کجا گرفته شده است

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

یک جست‌وجو، چند نقطه مشاهده

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

هر یک به پرسشی متفاوت پاسخ می‌دهد و هیچ‌یک به‌تنهایی ثابت نمی‌کند پرس‌وجو کجا رفته است.

ثبت روی آداپتور بسته‌ها را نشان می‌دهد، نه نیت را. نمی‌گوید کلاینت کدام resolver را انتخاب کرده، و ثبت خالی می‌تواند به معنای پاسخ ذخیره‌شده یا API resolver دیگری باشد، نه بسته‌ای که دور ریخته شده. هر مشاهده را شاهدی درباره یک مرحله بدانید. سپس مراحل را به یک مسیر تبدیل کنید.

فیلتر کلاینت میان برنامه و سیم قرار دارد

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

راهنمای Split-DNS در Secure Client از Cisco تطبیق دامنه و فیلتر Windows را پوشش می‌دهد و آنچه برنامه هنگام استفاده از API بومی resolver می‌بیند را از آنچه ابزاری مانند nslookup می‌بیند جدا می‌کند. همین تفاوت‌ها نکته اصلی است.

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

nslookup مسیری متفاوت از برنامه طی می‌کند

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

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

سیاست را بخوانید و سپس همان پرسش را از resolver معمولی بپرسید:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

resolverهای رمزگذاری‌شده پرس‌وجو را پنهان می‌کنند، نه اتصال را

مرورگری با resolver اختصاصی DNS-over-HTTPS خود، موردی کاملاً دیگر است. پرس‌وجو درون TLS خارج می‌شود، پس ثبت بسته اتصالی به نشانی resolver نشان می‌دهد اما نامی را که پرسیده می‌شود نشان نمی‌دهد.

نخست سیاست مدیریت‌شده مرورگر را روشن کنید، سپس آن را با جست‌وجوی سیستم‌عامل مقایسه کنید. مرورگری که اجازه دارد resolver خودش را انتخاب کند شاید هرگز سیاست Split-DNS را نبیند.

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

با یک آزمون برچسب‌دار مقایسه کنید

یک نام داخلی تأییدشده برای آزمون انتخاب کنید، به‌همراه یک نام عمومی که معنای حساسی ندارد. برای هر یک، زمان، نوع رکورد، پاسخ و سیاستی را که انتظار داشتید ثبت کنید.

هر جا مجاز است، دریافت resolver را با یک مشاهده باریک از کلاینت یا دروازه مقایسه کنید:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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