BIND9 & MS DNS

Требования безопасности:
На внешнем интерфейсе должны быть открыты порты tcp/25 и, по-желанию, tcp/22. DNS не должен принимать клиентские запросы с внешнего интерфейса. Чтобы обеспечить видимость доменного имени в интернете, два провайдера должны держать вторичную зону и именно их серверы необходимо прописать в базу RIPN. Наш сервер отдает зону только вторичным серверам и серверам-тестировщикам RIPN. Схемка выглядит примерно так:

BIND9 & MS DNS

допустим:

  • все серверы установлены, поднята AD;
  • на unix/linux поднят кэширующий DNS;
  • на unix/linux установлен dhcp, но не запущен и не сконфигурен.
  • на unix/linux установлен в качестве dns bind 9. Для версии 4 и 8 view не работает, в этом случае надо будет запускать два демона с разными конфигами и привязывать на разные интерфейсы.

Отмазка:

все ашипки на совесть маей супруги каторая диржала карректуру этой статьи.

решение:

    dns:
  1. создаем на gate две зоны для domain.tld
    1. вторичную зону с AD;
    2. первичную с внешними адресами;
  2. разрешаем экспорт зоны на контроллере для gate.
    dhcp:
  3. настраиваем на gate DHCP так, чтобы он выдавал ip из того же диапазона, что и MS DHCP и регистрировал их на контроллере домена.
    почта:
  4. почту пока не трогаем, будет ещё статья.

начинаем делать п.1:

заходим по ssh на gate и правим конфиг dns сервера: в /etc/namedb/named.conf пишем:


# список доступа для внутренней сети.
acl insiders { 192.168.0.0/24; 127.0.0.1; };

# список доступа для всех остальных
acl external { any; };

# список доступа для вторичных dns провайдеров
# ns1.provider1.ru = 23.111.1.1
# ns2.provider2.ru = 9.9.9.1
#

acl secondaries { 23.111.1.1; 9.9.9.1; };
# ripn тестировал зоны с этих серверов, сейчас это вроде бы, делает nic.ru откуда не знаю :(
acl ripn-tester { 194.85.119.3; 194.85.119.4; };

options {
# выполняем требования безопасности
# слушаем на внутреннем интерфейсе:

  listen 192.168.0.3 port 53;

# помним, что обращения к внешним серверам имен должны
# исходить от имени внешнего интерфейса

  query-source 23.0.0.1;
# можно также указать с какого ip будет осуществляться передача зон к провайдеру.
   transfer-source 23.0.0.1;
# т.к. передача зоны будет вестись с внешнего интерфейса,
# это необходимо учесть в правилах брандмауэра.

}; #end of options


# определение внутреннего представления
view "int-zones" {
  match-clients { "internal"; };
  allow-transfer { "local-sec"; "tester"; "dmz-machine"; };

# параметры зоны прямого просмотра
  zone "domain.tld" {
    type slave;
    file "sec/int.domain.tld";
    masters { 192.168.0.1; };
    allow-query { internal; };
    notify no;
  }; # end zone

# параметры зоны обратного просмотра
  zone "0.168.192.in-addr.arpa" IN {
    type slave;
    file "rev.domain.tld";
    masters { 192.168.0.1; };
  }; # end zone

  zone "localhost" {
    type master;
    file "prim/localhost.dns";
    allow-transfer { none; };
  };# end localhost

  zone "0.0.127.in-addr.arpa" {
    type master;
    file "prim/reverse.localhost.dns";
    allow-transfer { none; };
  };# end 0.127.in-addr.arpa
}; # end view internal

создаем представление для внешнего просмотра. 


view "ext-zones" {
  zone "domain.tld" {
    type master;
    file "prim/ext.domain.tld";
    allow-transfer { "secondaries"; "ripn-tester"; };
    notify yes;
  }; # end zone domain.tld
}; # end view external

создаем файл первичной зоны для domain.tld
(на той FreeBSD, которая у меня есть зоны лежат в /etc/namedb на linux'овых машинах в /var/named) и пишем туда:

$ORIGIN domain.tld.
$TTL 86400; 1 day
@        IN SOA gate.domain.tld. hostmaster.domain.tld. (
                2005031101; serial
                28800  ; refresh (8 hours)
                7200   ; retry (2 hours)
                604800 ; expire (1 week)
                86400  ; minimum (1 day)
                )
# можно в базе ripn указать вторичные dns провайдеров (stealth dns),
# тогда все изменения в зоне будут делаться Вами, исключая переписку с провайдером.


@            NS  dns1.provider1.ru.
@            NS  dns2.provider2.ru.
@            A   23.0.0.1

# это новомодное требование для антиспамерских проверок.
@            IN  TXT   "v=spf1 +MX +ip4:23.0.0.1/28 ~all"

# $ORIGIN будет добавляться после имени, если в конце нет точки.
@            IN  MX 100 gate
@            IN  MX 200  mail.provider1.ru.
@            IN  MX 300  mail.provider2.ru.
gate         IN  A 23.0.0.1
www          IN  CNAME bsd01.best-hosting.ru.
# всем остальным ip тоже присваиваем имена.
$GENERATE 3-254 host-$ A    23.0.0.$

вот, теперь фришный dns отдает правильные ip как для внешних, так и для внутренних запросов.
делаем dhcp:
ищем, где лежит dhcpd.conf (у меня в /etc) и правим его:
# описываем хост с динамическим dns, т.е. контроллер домена
ddns-hostname           "dc";

# прописываем доменное имя 
ddns-domainname         "domain.tld";

# тоже самое для обратной зоны
ddns-rev-domainname     "0.168.192.in-addr.arpa";
default-lease-time      604800; # 1W
max-lease-time          10368000;
ddns-update-style       ad-hoc;

subnet 192.168.0.0 netmask 255.255.255.0 {

# первые 10 резервируем для серверов
    range 192.168.0.10 192.168.23.254;

# шлюз указывает на unix
    option routers      192.168.0.3;

# это понятно
    option domain-name  "domain.tld";

# сервера имен
    option domain-name-servers 192.168.0.1,192.168.0.3;

# сначала wins, потом широковещательная рассылка
    option netbios-node-type 8;
# указываем wins сервер ( у нас это DC)
    option netbios-name-servers 192.168.0.1;

# разрешить динамические обновления
    ddns-updates        on;

# проверка пингом перед выдачей ip
    ping-check          on;
    authoritative;
}

Небольшая тонкость:
ISC'овский dhcpd отдает ip, начиная со старших адресов, а микрософтовский наоборот. Можно на всех dhcp серверах указать один диапазон и, при небольшом количестве машин, выдаваемые ip не будут пересекаться.
Выдаваемые диапазоны можно разнести по разным серверам, например MS DNS будет выдавать c 10 по 127, а dhcpd на unix c с 254 по 128.

дальше разрешаем трансфер прямой и обратной зон на контроллере домена:

BIND9 & MS DNS

и

BIND9 & MS DNS

и небезопасные обновления:

BIND9 & MS DNS

в /etc/resolv.conf указываются dns провайдера, а на dns контроллера домена указывается форвард на gate, там и будет лежать кэш.

Перезапуск dns командой

rndc reload

В каталоге /etc/namedb/sec (или в /var/named/sec) должны появиться файлы int.domain.tld и rev.domain.tld

Проверка:
c рабочей станции делаем запрос к unix-серверу:

nslookup -q=any gc.domain.tld 192.168.0.3
Если не получили корректного результата - ищите ошибку в файлах журналов /var/log/messages /var/log/syslog /var/log/debug
Если запустить dns командой
# named -g -u named
то он будет выполняться в оперативном режиме, и все диагностические сообщения будут выводиться на экран.

тоже самое для обратной зоны:
nslookup -q=ptr 1.0.168.192.in-addr.arpa 192.168.0.3
Если вы получили адрес глобального каталога и указатель на сервер, значит зоны странсферились, запрос выполнился, наступило Щастье.

настройки для FeeBSD и linux'а почти одинаковые, разница может быть только в расположении конфигурационных файлов.

все нижеизложенное было взято с реальных машин и перепроверено на стенде.

стенд состоял из сервера w2k, рабочей станции c winxp и шлюза с linux (trustix).

BIND9 & MS DNS
http://pc-inform.ru/articles/BIND9_MS_DNS.html
Sergey Yegorov