VPN арқылы BIND: шартты қайта жіберу ме, әлде 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 сұрауы сәтсіз болса, forward аймағы қалай әрекет етсе де, stub аймағы жұмыс істей алмайды.

Туннельді емес, жауапты тексеріңіз

Кеңсе resolverі арқылы ешқашан сұрамаған атауды сұрап, жауаптың authority бөлігін қарап, оның корпоративтік аймақтан келгенін тексеріңіз. Кэштегі жауап ағымдағы жол туралы ештеңе дәлелдемейді, ал upstreamке тікелей сәтті сұрау resolverіңіздің сол аймақты таңдағанын дәлелдемейді. Сол сұрауды TCP арқылы қайталап, жолдың кесуге төзетінін растаңыз.

Клиенттерді кеңсе resolverіне бағыттап ұстаңыз, және DNSSEC тексеруін қосулы ұстаңыз. Тәуелсіз шифрланған resolverмен конфигурацияланған браузер бұл құрылымды толығымен айналып өтеді, ал күтпеген жауап дұрыс көрінуі үшін тексеруді өшіру көрінетін ақауды көрінбейтін ақауға айырбастайды.

Үш түрдің қайсысын таңдағаныңызды және неге екенін жазып қойыңыз. Аймақтың істен шыққанын көретін келесі адамға конфигурация файлынан гөрі сол сөйлем көбірек қажет болады.

Қатысты мақалалар