قرار دادن یک resolver داخلی در جایگاه اول و یک resolver عمومی در جایگاه دوم به Squid نمی‌گوید کدام نام‌ها به کدام فضای نام تعلق دارند.

در Squid 6 و 7، dns_nameservers فهرست معمول resolverها را با نشانی‌های سرور جایگزین می‌کند. نحو آن نگاشت به‌ازای هر دامنه ندارد. پاسخ منفی معتبر نیز با resolver غیرقابل‌دسترس متفاوت است، بنابراین جایگزین‌ها راه مطمئنی برای جست‌وجو در فضاهای نام ناسازگار نیستند.

مسیردهی پرس‌وجوها بر اساس دامنه

یک forwarder محلی DNS می‌تواند سیاستی را که وجود ندارد بیان کند. در پیکربندی موجود dnsmasq، یک پسوند خصوصی را می‌توان چنین مسیردهی کرد:

server=/internal.example/192.0.2.53

دامنه و نشانی را جایگزین کنید. یک upstream پیش‌فرض تأییدشده برای نام‌های دیگر، یک شنونده مناسب و محدودیت‌های دسترسی پیکربندی کنید. سپس Squid را با پیکربندی پشتیبانی‌شده در نسخه نصب‌شده به آن resolver اشاره دهید.

در غیر این صورت، از یک سرویس DNS سازمانی استفاده کنید که هر دو فضای نام را درست تجزیه می‌کند. از مسیر بازگشتی عمومی که نام‌های خصوصی را افشا می‌کند و نمی‌تواند به آن‌ها پاسخ دهد بپرهیزید.

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

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

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

خانواده‌های نشانی موردنیاز کلاینت را لحاظ کنید. یک جست‌وجوی A موفق ثابت نمی‌کند که AAAA از سیاست پیروی می‌کند یا مقصدی قابل‌دسترس برمی‌گرداند. وضعیت cache را هم در نظر بگیرید: پاسخ ذخیره‌شده می‌تواند پنهان کند که یک پرس‌وجوی تازه کدام upstream را انتخاب می‌کرد.

مقالات مرتبط