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, напълно заобикаля тази подредба, а изключването на проверката, за да изглежда неочакван отговор правилен, разменя видим отказ за невидим.

Запишете кой от трите типа избрахте и защо. Следващият човек, който види зоната да се проваля, ще има нужда от това изречение повече от конфигурационния файл.

Подобни статии