BIND преко VPN-а: условно прослеђивање или stub зона?

Ваш канцеларијски resolver одговара на све осим на један корпоративни простор имена, а корпоративни DNS сервер који га зна налази се иза VPN-а. BIND може тај једини простор имена да преда upstream-у на три различита начина, и они падају на различит начин. Условно прослеђивање је најмања обавеза, stub зона чува податке о делегацији, а secondary чува потпуну копију. Бирајте према ономе шта ће upstream дозволити и шта желите да ваш resolver чува, а не према томе који сте исечак први пронашли.

Три распореда за један простор имена

Условно прослеђивање: најмања обавеза

Претпоставите канцеларијски 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-ом потпуно заобилази овај распоред, а искључивање валидације да би неочекиван одговор изгледао исправан мења видљив отказ за невидљив.

Запишите који сте од три типа изабрали и зашто. Следећој особи која буде видела да зона пада та реченица ће требати више од конфигурационе датотеке.