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

دریافت پاسخ و انتخاب برگرداندن آن دو گام متفاوت است.

همان نام را روی هر دو resolver مقایسه کنید

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

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

رد شدن را بخوانید نه نشانه را

گزینه stop-dns-rebind در dnsmasq پاسخ‌های نشانی خصوصی واجد شرایط را که از بالادست می‌رسند رد می‌کند و هنگام این کار آن‌ها را ثبت می‌کند. این محافظت دلیلی خوب دارد: نامی عمومی که ناگهان به نشانی خصوصی تبدیل می‌شود همان حمله کلاسیک rebinding است. اما با سرویسی که عمداً خصوصی است هم تلاقی می‌کند، و این همان مورد شماست.

پیش از تغییر هر چیزی رد شدن را در گزارش جست‌وجو کنید، چون پیام سازوکار را نام می‌برد.

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

استثنا را به یک دامنه محدود کنید

برای دامنه‌ای تأییدشده، راهنمای dnsmasq استثنایی محدود به دامنه ارائه می‌دهد نه یک کلید سراسری.

rebind-domain-ok=corp.example

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

استثنا از تشخیص rebinding دقیقاً یک کار می‌کند: پاسخ‌های همان دامنه را عبور می‌دهد.

این استثنا یک ارجاع‌دهنده split-DNS را پیکربندی نمی‌کند، منبع بالادست دست‌نیافتنی را دست‌یافتنی نمی‌کند و مسیری به نشانی برگردانده‌شده نمی‌سازد. هر یک از این‌ها خواسته‌ای جدا با امضای خرابی خودش است، و هرکدام در کلاینت به شکلی متفاوت شکست می‌خورد.

بدون برداشتن مرز بررسی کنید

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

دلیل استثنا را کنار پیکربندی نگه دارید، با تاریخ و مسئول.

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

مقالات مرتبط