BIND روی VPN: ارسال شرطی یا ناحیه stub؟

سه راه برای حل یک ناحیه خصوصی از طریق VPN و اینکه هر کدام چه زمانی مناسب است: forward، stub یا secondary، به‌همراه بررسی آدرس مبدأ که تصمیم را می‌گیرد.

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

سه آرایش برای یک فضای نام

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

ارسال شرطی: کوچک‌ترین تعهد

فرض کنید resolver دفتر در 192.168.10.53 و سرور سازمانی در 10.40.0.53 است که از طریق تونل تأییدشده در دسترس است. اعلان سه خط است و خط جالب forward only است، چون رفتار خطا را تغییر می‌دهد نه مسیر را.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

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

stub یا secondary: وقتی تفویض اهمیت دارد

ناحیه stub از سرور سازمانی رکوردهای NS ناحیه را می‌پرسد و سپس مستقیماً از سرورهای معتبر می‌پرسد. آن را وقتی انتخاب کنید که منطقه upstream بزرگ یا تقسیم‌شده است و می‌خواهید resolver شما تفویض را دنبال کند نه اینکه همه چیز را به یک آدرس سنجاق کند. هزینه آن وابستگی به به‌روز بودن داده‌های NS و به در دسترس بودن هر سرور نام فهرست‌شده از آدرس مبدأ resolver شماست.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

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

بررسی‌ای که بین آن‌ها تصمیم می‌گیرد

BIND پرس‌وجوی خروجی خودش را تولید می‌کند، پس پرسش این نیست که آیا لپ‌تاپ به 10.40.0.53 می‌رسد، بلکه این است که آیا میزبان resolver از آدرس مبدأیی که سرور سازمانی می‌بیند می‌رسد. اول از هسته بپرسید، سپس از سرور، به همین ترتیب.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

UDP و TCP را در مسیر مجاز کنید: پاسخ بریده TCP را تحمیل می‌کند و سیاستی که فقط UDP را مجاز می‌داند خرابی‌های متناوبی تولید می‌کند که شبیه افت بسته است. سمت سازمانی هم به قاعده پذیرش برای مبدأ resolver شما نیاز دارد و هم به مسیر بازگشت به آن؛ آن مبدأ می‌تواند آدرس مسیریابی‌شده resolver یا آدرسی به‌صراحت ترجمه‌شده باشد و به‌ندرت آدرس یک استخر کلاینت است. اگر پرس‌وجوی NS شکست بخورد، ناحیه stub هر طور که ناحیه forward رفتار کند کار نمی‌کند.

پاسخ را بررسی کنید، نه تونل را

از طریق resolver دفتر نامی را بپرسید که هرگز درخواست نکرده‌اید و بخش authority پاسخ را ببینید تا بدانید از ناحیه سازمانی آمده است یا نه. پاسخ ذخیره‌شده در حافظه هیچ چیزی درباره مسیر فعلی اثبات نمی‌کند و پرس‌وجوی موفق مستقیم به upstream اثبات نمی‌کند که resolver شما آن ناحیه را انتخاب کرده است. همان پرس‌وجو را از طریق TCP تکرار کنید تا تأیید کنید مسیر بریدن را تحمل می‌کند.

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

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

مقالات مرتبط