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

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

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.

O'xshash maqolalar