VPN ustida BIND: shartli yo‘naltirish yoki stub zonasimi?
VPN orqali bitta xususiy zonani hal qilishning uch yo‘li va har biri qachon mos: forward, stub yoki secondary, hamda qarorni belgilovchi manba manzil tekshiruvi.
Ofis resolveryingiz bitta korporativ nom maydonidan tashqari hamma narsaga javob beradi va uni biladigan korporativ DNS serveri VPN ortida turadi. BIND o‘sha bitta zonani upstreamga uch xil usulda topshirishi mumkin va ular turlicha muvaffaqiyatsizlikka uchraydi. Shartli yo‘naltirish eng kichik majburiyat, stub zonasi delegatsiya ma’lumotlarini saqlaydi, secondary esa to‘liq nusxani saqlaydi. Birinchi topgan snippetga qarab emas, upstream nimaga ruxsat berishi va resolveryingiz nimani saqlashini xohishingizga qarab tanlang.
Bitta nom maydoni uchun uchta tuzilma
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
Shartli yo‘naltirish: eng kichik majburiyat
Ofis resolvery 192.168.10.53 da, korporativ server esa 10.40.0.53 da bo‘lib, tasdiqlangan tunnel orqali yetib boriladi deb faraz qiling. E’lon uch satr, eng qiziqarlisi esa forward only, chunki u yo‘lni emas, xato paytidagi xatti-harakatni o‘zgartiradi.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};
forward only bilan yetib bo‘lmaydigan upstream bu zona uchun iterativ hal qilishga qaytish o‘rniga SERVFAIL beradi. Xususiy nom maydoni uchun odatda shu kerak, chunki qaytish xususiy nomlarni ommaviy resolverga yuborib, internetdan foydasiz javob keltirardi. BIND ma’lumotnomasi ikkala siyosatni ham hujjatlashtiradi va farq snippet ko‘rsatganidan muhimroq. Zonani xuddi shu nom uchun allaqachon mavjud zonani almashtirish o‘rniga mavjud konfiguratsiyaga qo‘shing.
stub yoki secondary: delegatsiya muhim bo‘lganda
stub zonasi korporativ serverdan zonaning NS yozuvlarini so‘raydi, so‘ngra vakolatli serverlardan to‘g‘ridan-to‘g‘ri so‘raydi. Uni upstream hududi katta yoki bo‘lingan bo‘lganda va resolveryingiz hamma narsani bitta manzilga qadab qo‘yish o‘rniga delegatsiyani kuzatishini xohlaganda tanlang. Narxi — NS ma’lumotlarining dolzarbligiga va ro‘yxatdagi har bir nom serveriga resolveryingizning manba manzilidan yetib borishiga bog‘liqlik.
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 mahalliy ma’lumotlardan javob beradi va upstream uzilishiga chidaydi, shuning uchun uzatishga bog‘liqlikni qabul qilish arziydi. Bu shuni ham bildiradi ki, resolveryingiz endi o‘ziga tegishli bo‘lmagan zonaning nusxasini saqlaydi, shuning uchun fayl yo‘li, birlamchi serverdagi uzatish ACL va yangilash taymerlari operatsion yuzangizning qismiga aylanadi.
Ular orasida qaror qiladigan tekshiruv
BIND o‘zining chiquvchi so‘rovini o‘zi yaratadi, shuning uchun savol noutbuk 10.40.0.53 ga yeta oladimi emas, resolver xosti korporativ server ko‘radigan manba manzilidan yeta oladimi. Avval yadroga, keyin serverga so‘rang, shu tartibda.
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
Yo‘lda UDP va TCP ga ruxsat bering: kesilgan javob TCP ni majbur qiladi, faqat UDP ga ruxsat beruvchi siyosat esa paket yo‘qolishiga o‘xshash uzilishli nosozliklar keltiradi. Korporativ tomonga resolveryingiz manbasi uchun qabul qoidasi ham, u tomonga qaytish yo‘li ham kerak; bu manba resolverning marshrutlangan manzili yoki aniq tarjima qilingan manzil bo‘lishi mumkin va kamdan-kam mijozlar puli manzili bo‘ladi. Agar NS so‘rovi bajarilmasa, forward zonasi qanday tutsa ham stub zonasi ishlay olmaydi.
Tunnelni emas, javobni tekshiring
Ofis resolvery orqali hech qachon so‘ramagan nomingizni so‘rang va javobning authority qismiga qarab u korporativ zonadan kelganmi-yo‘qmi aniqlang. Keshdagi javob joriy yo‘l haqida hech narsani isbotlamaydi, upstreamga to‘g‘ridan-to‘g‘ri muvaffaqiyatli so‘rov esa resolveryingiz o‘sha zonani tanlaganini isbotlamaydi. Xuddi shu so‘rovni TCP orqali takrorlab, yo‘l kesishga chidayotganini tasdiqlang.
Mijozlarni ofis resolveriga qaratib turing, va DNSSEC tekshiruvini yoniq holda qoldiring. Mustaqil shifrlangan resolver bilan sozlangan brauzer bu tuzilmani butunlay chetlab o‘tadi, kutilmagan javob to‘g‘ri ko‘rinishi uchun tekshiruvni o‘chirish esa ko‘rinadigan nosozlikni ko‘rinmaydiganiga almashtiradi.
Uch turdan qaysinisini tanlaganingizni va nima uchunligini yozib qo‘ying. Zonaning ishlamay qolganini ko‘radigan keyingi odamga konfiguratsiya faylidan ko‘ra o‘sha gap ko‘proq kerak bo‘ladi.