HOWTO DNS сервер BIND (практика)

9 июля, 2011 Рубрики: DNS, HOWTO, Linux, Настройка сервера Linux, Сети

Доброго времени, читатели. Продолжая теоретический материал о DNS сервере BIND, в текущей статье хочу рассмотреть практический пример установки и настройки разных конфигураций сервера BIND. В статье я опишу настройку DNS-кэша и полноценного DNS master сервера. Начну описание с общих понятий и необходимых шагов для организации любого DNS сервера.

Общие сведения

демон named DNS сервера BINDNamed – это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен. Демон named может реализовывать функции серверов любого типа: master, slave, cache. На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND. Бинарник, который выполняет основную работу, расположен в /usr/sbin/named. Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind. В основном конфиге описывается рабочий каталог асервера, зачастую это каталог /var/cache/bind, в котором лежат файлы описания зон и другие служебные файлы. Соответствие названия зоны и файла описания зоны задает раздел zone с параметром file. Раздел zone так же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров сборки сервера из исходников).

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

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND. Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.

Исходные данные

Для корректной работы DNS нем необходимо иметь настроенную сеть. DNS в текущей статье будет настроен на дистрибутиве Debian, особенности других дистрибутивов тоже будут отмечены. Конфиг сети стенда следующий:

dns:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
 address 10.0.0.152
 netmask 255.255.255.0
 gateway 10.0.0.254

auto eth1
iface eth1 inet static
 address 192.168.1.1
 netmask 255.255.255.0

где 10.0.0.152/24 – внешний интерфейс (подсеть, выделенная провайдером), 192.168.1.1/24 – внутренний (Локальная сеть). Настраиваемая зона будет иметь имя example.com. В примере со slave сервером, вторичный сервер будет расположен на IP 10.0.0.191.

Установка BIND9

Для работы DNS сервера необходимо установить пакет bind9 (в некоторых дистрибутивах – bind). Как отмечено на схеме – основным конфигурационным файлом BIND является файл named.conf (данный файл может быть размещен в каталоге /etc, иногда в /etc/bind ).

Параметры (синтаксис) named.conf

Синтаксис файла named.conf придерживается следующих правил:

IP-адреса – список IP должен быть разделен символом “;” , возможно указывать подсеть в формате 192.168.1.1/24 или 192.168.1.1/255.255.255.0, (для исключения IP перед ним нужно поставить знак !), возможно указывать имена “any”, “none”, “localhost” в двойных кавычках.

Комментарии – строки начинающиеся на #, // и заключенные в /* и */ считаются комментариями.

В файлах описания зон – символ @ является “переменной” хранящей имя зоны, указанной в конфигурационном файле named.conf или в директиве @ $ORIGIN текущего описания зоны.

Каждая завершенная строка параметров должна завершаться символом ; .

Раздел Acl

Acl (access control list) – позволяет задать именованный список сетей. Формат раздела: acl “имя_сети” {ip; ip; ip; };

Раздел Options

Раздел Options задает глобальные параметры конфигурационного файла, управляющие всеми зонами. Данный раздел имеет формат: options {операторы_раздела_Options};. Options может быть “вложен” в раздел Zone, при этом он переопределяет глобальные параметры. Часто используемые операторы options:

  • allow-query {список_ip} – Разрешает ответы на запросы только из список_ip. При отсутствии – сервер отвечает на все запросы.
  • allow-recursion {список_ip} – На запросы из список_ip будут выполняться рекурсивные запросы. Для остальных – итеративные. Если не задан параметр, то сервер выполняет рекурсивные запросы для всех сетей.
  • allow-transfer {список_ip} – Указывает список серверов, которым разрешено брать зону с сервера (в основном тут указывают slave сервера)
  • directory /path/to/work/dir – указывает абсолютный путь к рабочему каталогу сервера. Этот оператор допустим только в разделе options.
  • forwarders {ip порт, ip порт...} – указывает адреса хостов и если нужно порты, куда переадресовывать запросы (обычно тут указываются DNS провайдеров ISP).
  • forward ONLY или forward FIRST – параметр first указывает, DNS-серверу пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders, и лишь в случае, если разрешить имя с помощью данных серверов не удалось, то будет осуществлять попытки разрешения имени самостоятельно.
  • notify YES|NOYES – уведомлять slave сервера об изменениях в зоне, NO – не уведомлять.
  • recursion YES|NOYES – выполнять рекурсивные запросы, если просит клиент, NO – не выполнять (только итеративные запросы). Если ответ найден в кэше, то возвращается из кэша. (может использоваться только в разделе Options)

Раздел Zone

Определяет описание зон(ы). Формат раздела: zone {операторы_раздела_zone}; Операторы, которые наиболее часто используются:

  • allow-update {список_ip} – указывает системы, которым разрешено динамически обновлять данную зону.
  • file “имя_файла” – указывает путь файла параметров зоны (должен быть расположен в каталоге, определенном в разделе options оператором directory)
  • masters {список_ip} -указывает список мастер-серверов. (допустим только в подчиненных зонах)
  • type “тип_зоны” – указывает тип зоны, описываемой в текущем разделе,тип_зоны может принимать следующие значения:
    • forward – указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону.
    • hint – указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кэше)
    • master – указывает работать в качестве мастер сервера для текущей зоны.
    • slave – указывает работать в качестве подчиненного сервера для текущей зоны.

Дополнительные параметры конфигурации

Значения времени в файлах зон по умолчанию указывается в секундах, если за ними не стоит одна из следующих букв: S – секунды, M – минуты, H- часы, D – дни, W – недели. Соответственно, запись 2h20m5s будет иметь значение 2 часа 20 минут 5 секунд и соответствовать 8405 секунд.

Любое имя хоста/записи, не оканчивающиеся точкой считается неFQDN именем и будет дополнено именем текущей зоны. Например, запись domen в файле зоны examle.com будет развернуто в FQDN-имя domen.examle.com. .

В конфигурационных файлах BIND могут применяться следующие директивы:

  • $TTL – определяет TTL по-умолчанию для всех записей в текущей зоне.
  • $ORIGIN – изменяет имя зоны с указанного в файле named.conf. При этом, область действия данной директивы не распространяется “выше” (то есть если файл включен директивой $INCLUDE, то область действия$ORIGN не распространяется на родительский)
  • $INCLUDE – включает указанный файл как часть файла зоны.

Для того чтобы локальный резолвер сервера тоже использовал локальный DNS, необходимо привести файл resolv.conf к следующему виду:

dns:~# cat /etc/resolv.conf
nameserver 127.0.0.1

Если в имени ресурсной записи встречается символ “*”, то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. Такую запись называют “wildcard запись“. Однако, символ “*” не может быть использован где угодно. Это может быть только первый символ в поле Name текущего домена, отделенный от остальных символом “.”

Настройка кэширующего DNS сервера

После установки bind, он полностью готов работать как кэширующий DNS сервер без дополнительной настройки. Единственный недостаток – он обрабатывает запросы на всех интерфейсах, что нам абсолютно не нужно, поэтому мы немного подредактируем настройки сервера.

Для того, чтобы BIND работал в качестве кэширующего сервера, необходимо иметь конфигурационные файлы заполненные необходимой информацией:

  • named.conf;
  • описание серверов корневой зоны (зона типа hint);
  • описание зоны 127.in-addr.arpa.
dns:~# cat /etc/bind/named.conf
acl "lan" {
           192.168.1.1/24;
           127.0.0.1;
};

options {
           directory "/var/cache/bind";

           // If there is a firewall between you and nameservers you want
           // to talk to, you may need to fix the firewall to allow multiple
           // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
           /*
           * Тут сказано, что если используется фаерволл, то необходимо
           *  нашему серверу создать соответствующие правила
           *  то есть открыть доступ по 53 TCP и UDP порту
           */

           forward first;              // задаем пересылку только первого запроса

           forwarders {                // указываем DNS сервера для пересылки
                      83.239.0.202;    // предоставленные провайдером
                      213.132.67.110;  // ибо до них ближе чем до корневых
           };

          listen-on { lan; };        // пусть слушает только нужные интерфейсы
          allow-query { lan; };      // разрешить запросы только из локальной сети
          allow-recursion { lan; };  // рекурсивные запросы тоже только из локальной
          allow-transfer { none; };  // трансфер зон нам не нужен

          version "unknown";         // не отображать версию DNS сервера при ответах

          auth-nxdomain no;    # для совместимости RFC1035
          listen-on-v6 { none; };    //IPv6 нам не нужен
          };

// описание настроек корневых серверов
zone "." {
          type hint;
          file "db.root";
};

// нижеописанные зоны определяют сервер авторитетным для петлевых
// интерфейсов, а так же для броадкаст-зон (согласно RFC 1912)

zone "localhost" {
          type master;
          file "localhost";
};

zone "127.in-addr.arpa" {
          type master;
          file "127.in-addr.arpa";
};

zone "0.in-addr.arpa" {
          type master;
          file "0.in-addr.arpa";
};

zone "255.in-addr.arpa" {
          type master;
          file "255.in-addr.arpa";
};

В данном примере приведен кэширующий DNS сервер, обрабатывающий запросы из списка сетей lan, в которую входит только одна локальная сеть 192.168.1.1/24 и петлевой интерфейс. При необходимости можно включить туда и другие сети. После определения списка сетей в директиве acl, в любом месте конфига можно будет ссылаться на этот список по имени (в нашем примере имя – lan), что, собственно и сделано в разделе options. Большинство параметров я прокомментировал, но отдельного внимания требует раздел, описывающий зону корневых серверов. В параметре file задан относительный путь к файлу описания корневых серверов (путь, относительно рабочего каталога сервера). За обновлениями данного файла необходимо следить, хотя он обновляется довольно редко (откуда брать обновленный файл я писал в теории DNS). Как вы заметили, имеется так же две записи для зоны localhost и две записи обратных зон для бродкаст доменов. Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону.

Чтобы не вносить неразбериху в куче конфигурационных файлов, в статье я привожу примеры на основе единого конфигурационного файла. На  самом деле, в последних версиях Debian (и других дистрибутивах Linux), файл named.conf выглядит следующим образом:

root@master:~# cat /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

То есть основной файл не содержит конфигураций, а включает в себя более узко специализированные файлы, которые отвечают за свои задачи, например named.conf.options – содержит глобальные параметры конфигурации, named.conf.default-zones – содержит описание localhost и broadcast зон, а named.conf.local содержит описания зон, за которые отвечает данный сервер.

 

Далее, хочу обратить внимание на наличие файлов зон в каталоге, указанном в разделе options в параметре directory с именами, соответствующими параметрам file в разделах, описывающих зоны:

dns:~# ls -l /var/cache/bind/
итого 24
-rw-r--r-- 1 root root  237 Май 28 01:28 0.in-addr.arpa
-rw-r--r-- 1 root root  271 Май 28 01:28 127.in-addr.arpa
-rw-r--r-- 1 root root  237 Май 28 01:28 255.in-addr.arpa
-rw-r--r-- 1 root root 2994 Май 28 01:28 db.root
-rw-r--r-- 1 root root  270 Май 28 01:28 localhost
dns:~# cat /var/cache/bind/127.in-addr.arpa
;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                              604800    ; Refresh
                              86400     ; Retry
                              2419200   ; Expire
                              604800 )  ; Negative Cache TTL
;
@       IN      NS      localhost.
1.0.0   IN      PTR     localhost.

Рассматривать файлы “петлевых” и бродкастовых зон не вижу смысла, т.к. после установки пакета bind настройки заданные по умолчанию в данных файлах вполне приемлемы. Далее, при организации мастер сервера мы рассмотрим пример описания файла зоны. Хочу обратить внимание, что мы настраиваем кэширующий сервер, а определяем мы его и как master для некоторых из зон. В нашем случае “кэширующий” говорит о том, что наш сервер не поддерживает ни одну из реально существующих зон, т.е. ему не делегировано прав на такое обслуживание.

Да, чуть не забыл, демон named должен быть разрешен для запуска на необходимых уровнях выполнения ОС (команда в RedHat – /sbin/chkconfig bind9 on, в Debian – /usr/sbin/update-rc.d bind9 defaults). После изменения конфигурационных файлов можно добавить сервис в автозагрузку и запустить демон:

dns:~# update-rc.d bind9 defaults
Adding system startup for /etc/init.d/bind9 ...
/etc/rc0.d/K20bind9 -> ../init.d/bind9
/etc/rc1.d/K20bind9 -> ../init.d/bind9
/etc/rc6.d/K20bind9 -> ../init.d/bind9
/etc/rc2.d/S20bind9 -> ../init.d/bind9
/etc/rc3.d/S20bind9 -> ../init.d/bind9
/etc/rc4.d/S20bind9 -> ../init.d/bind9
/etc/rc5.d/S20bind9 -> ../init.d/bind9
dns:~# /etc/init.d/bind9 start
Starting domain name service...: bind9.

На этом настройка кэширующего DNS завершена. Все запросы, которые попадают в кэш DNS сервера он хранит в оперативной памяти компьютера и при перезапуске демона эти данные обнуляются. Для проверки работы кэша можно выполнить команду nslookup mail.ru example.com., если в ответе содержится строка Non-authoritative answer, то адрес пришел из кэша, а так же если выполнить dig www.ru. (или другой домен, которого еще нет в кэше) и через некоторое время повторить команду, то время ответа должно быть гораздо меньше.

Давайте рассмотрим другие варианты сервера.

Главный (master) сервер зоны

Основной конфиг содержит следующие настройки:

dns:~# cat /etc/bind/named.conf
acl "lan" {
          192.168.1.1/24;
          127.0.0.1;
};

options {
          directory "/var/cache/bind";
          allow-query { any; };       // отвечать на зпросы со всех интерфейсов
          recursion no;               // запретить рекурсивные запросы
          auth-nxdomain no;           // для совместимости RFC1035
          listen-on-v6 { none; };     // IPv6 нам не нужен
          version "unknown";          // не отображать версию DNS сервера при ответах

          /*
          *  Раскомментируйте строки ниже, если
          *  хотите разрешить рекрусивные запросы
          *  из локальной сети.
          *  (так же, необходимо закомментировать
          *  recursion no; )
          */
          # forwarders {                 // указываем DNS сервера для пересылки
          #         83.239.0.202;        // предоставленные провайдером
          #         213.132.67.110;      // ибо до них ближе чем до корневых
          # };

          # allow-recursion { lan; };    // рекурсивные запросы тоже только из локальной

};

// описание настроек корневых серверов
zone "." {
          type hint;
          file "db.root";
};

// нижеописанные зоны определяют сервер авторитетным для петлевых
// интерфейсов, а так же для броадкаст-зон (согласно RFC 1912)

zone "localhost" {
          type master;
          file "localhost";
};

zone "127.in-addr.arpa" {
          type master;
          file "127.in-addr.arpa";
};

zone "0.in-addr.arpa" {
          type master;
          file "0.in-addr.arpa";
};

zone "255.in-addr.arpa" {
          type master;
          file "255.in-addr.arpa";
};

// описание основной зоны
zone "example.com" {
          type master;
          file "example.com";
          allow-transfer { 10.0.0.191; };
};

//описание обратных зон
zone "0.0.10.in-addr.arpa" {
          type master;
          file "0.0.10.in-addr.arpa";
          allow-transfer { 10.0.0.191; };
};

zone "1.168.192.in-addr.arpa" {
          type master;
          file "1.168.192.in-addr.arpa";
#         allow-transfer { 10.0.0.191; };  // зона описывает локальную сеть поэтому ее не передаем
};

// настройки логирования
logging {
          channel "misc" {
                    file "/var/log/bind/misc.log" versions 4 size 4m;
                    print-time yes;
                    print-severity yes;
                    print-category yes;
          };

          channel "query" {
                    file "/var/log/bind/query.log" versions 4 size 4m;
                    print-time yes;
                    print-severity no;
                    print-category no;
          };

          category default {
                    "misc";
          };

          category queries {
                    "query";
          };
};

Давайте кратко разберем конфигурационный файл и настройки master сервера: мы настраиваем мастер сервер для зоны example.com. . Согласно конфига, наш BIND имеет рабочий каталог /var/cache/bind, сервер отвечает на запросы со всех интерфейсов (allow-query {any ;};), рекурсивные запросы обрабатывает как итеративные (recursion no), является мастер-сервером для зоны example.com и локальных служебных зон (type master). При этом, если необходимо разрешить кэширование (то есть рекурсивные запросы) для локальной сети, то необходимо раскомментировать параметры forwarders и allow-recursion и закомментировать recursion no;.

Так же, для примера, я привел возможности BIND логировать все происходящее при работе сервера (можно для этой цели использовать syslog). В разделе logging задаются 2 параметра channel (можно и больше двух – на ваше усмотрение), эти параметры дословно можно назвать “канал” записи. Каждый канал определяет имя канала и настройки параметров записи (что записывать, а что – нет и куда писать). Директива category задает какую категорию сообщений в какой канал отправлять. Исходя из этого, мы имеем: запись стандартной информации в канал misc, а приходящие запросы посылаются в канал query. При этом, если файлы журнала достигают 4Мб (size 4m), он переименовывается добавлением к имени .1 и начинается запись в новый журнал, числа в конце других журналов увеличиваются. Журналы с номером, более указанного в version (в нашем случае 4) удаляются (Управлять ротацией логов можно так же с помощью logrotate). Параметры print* определяют заносить ли в журнал время появления, важность и категорию информации. Более подробно про настройки раздела logging можно почитать в man (5) named.conf.

Отдельно хочется описать параметр  allow-transfer { 10.0.0.191; };. Данный параметр описывает серверы, которым разрешено скачивать копию зоны – т.н. slave серверА. В следующем примере мы разберем настройку slave DNS.

Для корректной работы логирования необходимо создать соответствующий каталог и присвоить необходимые права:

dns:~# mkdir /var/log/bind/
dns:~# chmod 744 /var/log/bind/
dns:~# ps aux | grep named
bind      4298  0.0  3.4  46792 13272 ?        Ssl  Jul05   0:00 /usr/sbin/named -u bind
root      4815  0.0  0.1   3304   772 pts/4    S+   18:19   0:00 grep named
dns:~# chown bind /var/log/bind/
dns:~# ls -ld /var/log/bind/
drwxr--r-- 2 bind root 4096 Июл  6 18:18 /var/log/bind/

Давайте далее рассмотрим наш файл описания зоны example.com.:

dns:~# cat /var/cache/bind/example.com
$TTL 3D
@       IN      SOA     ns.example.com. root.example.com. (
                                        2011070601      ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        2W              ; expire
                                        1D)             ; minimum

@       IN      NS      ns.example.com.
@       IN      NS      ns2.example.com.
@       IN      A       10.0.0.152
@       IN      MX      5 mx.example.com.
ns      IN      A       10.0.0.152
ns2     IN      A       10.0.0.191
mx      IN      A       10.0.0.152
www     IN      CNAME   @

а так же в домене in-addr.arpa.

dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa
$TTL 3600
@       IN      SOA     ns.examle.com.  root.example.com. (
             2007042001 ; Serial
             3600       ; Refresh
             900        ; Retry
             3600000    ; Expire
             3600 )     ; Minimum
        IN      NS      ns.examle.com.
        IN      NS      ns2.example.com.
152     IN      PTR     examle.com.
191     IN      PTR     ns.example.com.
*       IN      PTR     examle.com.

dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa
$TTL 3600
@       IN      SOA     ns.examle.com.  root.example.com. (
             2007042001 ; Serial
             3600       ; Refresh
             900        ; Retry
             3600000    ; Expire
             3600 )     ; Minimum
        IN      NS      ns.examle.com.
        IN      NS      ns2.example.com.
*       IN      PTR     examle.com.

Наша сеть небольшая, предполагается, что в сети совсем мало машин. Все сервисы сети размещены на одном хосте example.com., поэтому и master DNS (ns.example.com.) и почтовый сервер (mx.example.com.) указывает на одну машину (10.0.0.152).

Вторичный (secondary, slave) авторитетный сервер зоны

Основная функция slave сервера – автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по протоколу TCP, посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).

Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.

Прежде чем приступить к настройке slave DNS сервера, необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:

root@debian:~# dig @10.0.0.152 example.com. axfr

; <<>> DiG 9.7.3 <<>> @10.0.0.152 example.com. axfr
; (1 server found)
;; global options: +cmd
example.com.            259200  IN      SOA     ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400
example.com.            259200  IN      NS      ns.example.com.
example.com.            259200  IN      NS      ns2.example.com.
example.com.            259200  IN      A       10.0.0.152
example.com.            259200  IN      MX      5 mx.example.com.
mx.example.com.         259200  IN      A       10.0.0.152
ns.example.com.         259200  IN      A       10.0.0.152
ns2.example.com.        259200  IN      A       10.0.0.191
www.example.com.        259200  IN      CNAME   example.com.
example.com.            259200  IN      SOA     ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400
;; Query time: 14 msec
;; SERVER: 10.0.0.152#53(10.0.0.152)
;; WHEN: Fri Jul  8 15:33:54 2011
;; XFR size: 11 records (messages 1, bytes 258)

Получение зоны прошло успешно. Далее, для настройки подчиненного сервера, алгоритм следующий:

  1. Скопировать конфигурационный файл named.conf с master сервера;
  2. Заменить параметр type master на type slave в тех зонах, для которых он будет вторичным;
  3. Параметр  allow-transfer { 10.0.0.191; }; заменить на masters { 10.0.0.152;}; в тех зонах, для которых он будет вторичным;
  4. Удалить зоны, которые не будет обслуживать текущий сервер, в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
  5. Создать каталоги для логов, как в предыдущем примере.

Итого, мы получаем конфиг slave сервера:

root@debian:~# cat /etc/bind/named.conf
options {
          directory "/var/cache/bind";
          allow-query { any; };      // отвечать на запросы со всех интерфейсов
          recursion no;              // запретить рекурсивные запросы
          auth-nxdomain no;          // для совместимости RFC1035
          listen-on-v6 { none; };    // IPv6 нам не нужен
          version "unknown";         // не отображать версию DNS сервера при ответах
};

// нижеописанные зоны определяют сервер авторитетным для петлевых
// интерфейсов, а так же для броадкаст-зон (согласно RFC 1912)

zone "localhost" {
          type master;
          file "localhost";
};

zone "127.in-addr.arpa" {
          type master;
          file "127.in-addr.arpa";
};

zone "0.in-addr.arpa" {
          type master;
          file "0.in-addr.arpa";
};

zone "255.in-addr.arpa" {
          type master;
          file "255.in-addr.arpa";
};

// описание основной зоны
zone "example.com" {
          type slave;
          file "example.com";
          masters { 10.0.0.152; };
};

//описание обратной зоны
zone "0.0.10.in-addr.arpa" {
          type slave;
          file "0.0.10.in-addr.arpa";
          masters { 10.0.0.152; };
};

// настройки логирования
logging {
          channel "misc" {
                    file "/var/log/bind/misc.log" versions 4 size 4m;
                    print-time YES;
                    print-severity YES;
                    print-category YES;
          };

          channel "query" {
                    file "/var/log/bind/query.log" versions 4 size 4m;
                    print-time YES;
                    print-severity NO;
                    print-category NO;
          };

          category default {
                    "misc";
          };

          category queries {
                    "query";
          };
};

после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в  каталоге:

root@debian:~# ls -la /var/cache/bind/
итого 28
drwxrwxr-x  2 root bind 4096 Июл  8 18:47 .
drwxr-xr-x 10 root root 4096 Июл  8 15:17 ..
-rw-r--r--  1 bind bind  416 Июл  8 18:32 0.0.10.in-addr.arpa
......
-rw-r--r--  1 bind bind  455 Июл  8 18:32 example.com
........

В принципе,/stroallow-transfer {pngp slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта DNS. Наличие копии зоны в файловой системе может избавить от сбоя при недоступности master сервера во время запуска slave DNS. Если не указать опцию file в разделе zone, то копия не создается.

Настройка netfilter (iptables) для DNS BIND

Собственно, настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 53/udp порту. Почитав статью о том, что такое netfilter и правила iptables и ознакомившись с практическими примерами iptables, можно создать правила фильтрации сетевого трафика:

dns ~ # iptables-save
# типовые правила iptables для DNS
*filter
:INPUT DROP [7511:662704]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
# разрешить доступ локальной сети к DNS серверу:
-A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# разрешить доступ DNS серверу совершать исходящие запросы
-A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
COMMIT

Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.

Устранение неполадок

Основным источником для выявления проблем с DNS является системный лог. Вот пример ошибок при запуске, когда я ошибся с путем к файлу зоны коревых серверов:

Jul  5 18:12:43 dns-server named[4224]: starting BIND 9.7.3 -u bind
Jul  5 18:12:43 dns-server named[4224]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=' 'CPPFLAGS='
Jul  5 18:12:43 dns-server named[4224]: adjusted limit on open files from 1024 to 1048576
Jul  5 18:12:43 dns-server named[4224]: found 1 CPU, using 1 worker thread
Jul  5 18:12:43 dns-server named[4224]: using up to 4096 sockets
Jul  5 18:12:43 dns-server named[4224]: loading configuration from '/etc/bind/named.conf'
Jul  5 18:12:43 dns-server named[4224]: reading built-in trusted keys from file '/etc/bind/bind.keys'
Jul  5 18:12:43 dns-server named[4224]: using default UDP/IPv4 port range: [1024, 65535]
Jul  5 18:12:43 dns-server named[4224]: using default UDP/IPv6 port range: [1024, 65535]
Jul  5 18:12:43 dns-server named[4224]: listening on IPv4 interface lo, 127.0.0.1#53
Jul  5 18:12:43 dns-server named[4224]: listening on IPv4 interface eth1, 192.168.1.1#53
Jul  5 18:12:43 dns-server named[4224]: generating session key for dynamic DNS
Jul  5 18:12:43 dns-server named[4224]: could not configure root hints from '/etc/bind/db.root': file not found
Jul  5 18:12:43 dns-server named[4224]: loading configuration: file not found             # файл не найден
Jul  5 18:12:43 dns-server named[4224]: exiting (due to fatal error)
Jul  5 18:15:05 dns-server named[4298]: starting BIND 9.7.3 -u bind
Jul  5 18:15:05 dns-server named[4298]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=' 'CPPFLAGS='
Jul  5 18:15:05 dns-server named[4298]: adjusted limit on open files from 1024 to 1048576
Jul  5 18:15:05 dns-server named[4298]: found 1 CPU, using 1 worker thread
Jul  5 18:15:05 dns-server named[4298]: using up to 4096 sockets
Jul  5 18:15:05 dns-server named[4298]: loading configuration from '/etc/bind/named.conf'
Jul  5 18:15:05 dns-server named[4298]: using default UDP/IPv4 port range: [1024, 65535]
Jul  5 18:15:05 dns-server named[4298]: using default UDP/IPv6 port range: [1024, 65535]
Jul  5 18:15:05 dns-server named[4298]: listening on IPv4 interface lo, 127.0.0.1#53
Jul  5 18:15:05 dns-server named[4298]: listening on IPv4 interface eth1, 192.168.1.1#53
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 254.169.IN-ADDR.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 100.51.198.IN-ADDR.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 113.0.203.IN-ADDR.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: D.F.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 8.E.F.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 9.E.F.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: A.E.F.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: B.E.F.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Jul  5 18:15:05 dns-server named[4298]: zone 0.in-addr.arpa/IN: loaded serial 1
Jul  5 18:15:05 dns-server named[4298]: zone 127.in-addr.arpa/IN: loaded serial 1
Jul  5 18:15:05 dns-server named[4298]: zone 255.in-addr.arpa/IN: loaded serial 1
Jul  5 18:15:05 dns-server named[4298]: zone localhost/IN: loaded serial 2
Jul  5 18:15:05 dns-server named[4298]: running                                  # запуск прошел удачно

Отличным инструментом для диагностики являются команды диагностики DNS.

Резюме

В текущей статье я описал настройку основных конфигураций DNS сервера BIND. Целью статьи было – дать представление о работе сервера BIND в UNIX. Я практически не затронул вопросы безопасности ДНС и мало затронул такие специфичные настройки, как работа сервера в пограничном режиме, когда в разные сети отдается разная информация о зоне(нах). Для более глубокого освоения я предоставлю список дополнительных источников, в которых, я надеюсь, удастся получить нужную информацию. На этом ставлю точку. До новых встреч.

Что читать:

Система доменных имен: http://citforum.ru/internet/dns/khramtsov/
RFC 1034 — Domain Names — Concepts and Facilities: http://tools.ietf.org/html/rfc1034
RFC 1035 — Domain Names — Implementation and Specification: http://tools.ietf.org/html/rfc1035
RFC 1537 — Common DNS Data File Configuration Errors: http://tools.ietf.org/html/rfc1537
RFC 1591 — Domain Name System Structure and Delegation: http://tools.ietf.org/html/rfc1591
RFC 1713 — Tools for DNS Debugging: http://tools.ietf.org/html/rfc1713
RFC 2606 — Reserved Top Level DNS Names: http://tools.ietf.org/html/rfc2606
Безопасность DNS (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 Administrator Reference Manual: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Secure BIND Template: http://www.cymru.com/Documents/secure-bind-template.html
Хорошо расписаны параметры конфига на русском: http://www.bog.pp.ru/work/bind.html
Автоматическое создание файла зоны: http://www.zonefile.org/?lang=en#zonefile

Upd 2012.02.14: добавил настройку netfilter для DNS

С Уважением, Mc.Sim!




Теги: , , , , ,

118 комментариев к “HOWTO DNS сервер BIND (практика)”

  1. 20 июля, 2011 at 00:27
    1

    Как показала практика, в Squeeze немного другое расположение конфигов.

    • 20 июля, 2011 at 11:59
      2

      не исключено )

  2. ruslan
    23 июля, 2011 at 19:00
    3

    С назначением типов записей вроде все понятно, надо экспериментировать. У меня вопрос немного другой. Есть дома компьютер, старенький, есть интернет с белым статическим IP. Хочу организовать страничку и почту ради интереса. При регистрации домена необходимо указать DNS сервера – первичный и вторичный. Регистратор предлагает свои. А могу ли я для своих целей использовать в качестве DNS сервера свой же компьютер, при чем один? Очень хочется быть сам себе хозяин.

    • 24 июля, 2011 at 23:08
      4

      Один можно, но тогда у тебя должно быть 2 внешних интерфейса с разными IP. На одном из IP должен светиться первичный ДНС, на другом – вторичный.

      • 24 июля, 2011 at 23:12
        5

        Можно, конечно завести 2 разных DNS имени на 1 IP и указать в качестве вторичного и первичного эти 2 разных имени. Но далеко не каждый регистратор такое примет… Они проверят работоспособность твоих серверов.
        Да и зачем такие извращения? Зная качество услуг на конечной мили…. :( Не приятно будет, когда отключат интернет и твой DNS не сможет ответить на нужный запрос.
        Сейчас можно отлично пользоваться бесплатным DNS-хостингм от яндекса. И его же почтой и jabber. Вполне себе не плохо справляется с задачей!

  3. ruslan
    25 июля, 2011 at 11:36
    6

    Спасибо. Я то же думаю, что DNS-ы лучше внешние. Дело в том, что все это я делаю в образовательных целях. Почту все равно буду у себя разворачивать. Еще раз спасибо.

    • 25 июля, 2011 at 12:47
      7

      Пожалуйста. Приходите еще. Буду рад новым комментам.

  4. Артур
    30 июля, 2011 at 14:48
    8

    Привет Макс! Хороший БЛОГ поднял, САЛЮТ !
    P.S. не нашёл того что искал, а именно:
    Конфигурирование видов(view) в bind9, использование раздельного кеша для них.
    На больших нагрузках у bind’а есть проблемы с производительностью(во время очистки кеша теряется около половины запросов), впрочем в итеративном режиме работает хорошо. Для кеширования хороши powerDNS recursion или unbound.
    ещё минус bind’у : жрёт оперативу, хотя при 20-30 клиентах это не проблема.
    Приятно читать развёрнутые статьи!

    • 30 июля, 2011 at 23:11
      9

      Спасибо за дельный коммент.
      Если бы я еще про View написал, то статья бы вообще была не подъемная! Со временем, если руки дойдут до реализации решения DNS на разные сети, то обязательно напишу! За powerDNS recursion или unbound спасибо – почитаю. Сам не слышал про них.

  5. Максим
    31 июля, 2011 at 15:39
    10

    Спасибо за такие развернутые статьи.
    Действительно хороший блог!

  6. FiSh
    26 августа, 2011 at 17:57
    11

    8) Статья отличная ! Блог в целом тоже хорош.
    Соглашусь с kma21 в первом посте и добавлю что лучше в главном конфиге не чего не трогать. Есть много доп. файлов в которых удобно всё расписывать.
    И вопрос…а где описание файла локальной обратной зоны 1.168.192.in-addr.arpa ??

    • 26 августа, 2011 at 21:32
      12

      Спасибо за отзыв и дополнения.
      По поводу наличия нескольких конфигов – сделал небольшую заметку в статье. По поводу описания обратной зоны 1.168.192.in-addr.arpa – изначально планировал, что мастер-сервер будет отвечать на запросы только на внешнем интерфейсе, а потом передумал :) поэтому забыл про нее. Но уже исправился, спасибо ))

  7. Vladimir
    24 октября, 2011 at 22:41
    13

    Прошу HELP! Суть проблемы. Есть домашняя сеть под убунту сервер. На сервере bind9
    LAMP. Подняты 3 сайта. На сервере сайты открываются с локальной сети нет. Не могу понять почему. Запарился. Заранее благодарен.

    • 25 октября, 2011 at 09:50
      14

      Доброго времени!
      клиенты в локальной сети на Linux/Windows?
      Можно узнать адреса сайтов?

  8. Vladimir
    25 октября, 2011 at 13:53
    15

    Сайты для локальной сети. VirtualHost 192.168.0.10 сайт bamboo.mshome.net, biz.mshome.net, company.mshome.net Клиенты 192.168.0.2 Ксономи – на основе Убунту, 192.168.0.3 – Windows XP

  9. Vladimir
    25 октября, 2011 at 13:55
    16

    VirtualHost 192.168.0.10 сайт bamboo.mshome.net, biz.mshome.net-192.168.0.11, company.mshome.net-192.168.0.12

    • 27 октября, 2011 at 12:17
      17

      С клиентов имена bamboo.mshome.net, biz.mshome.net, company.mshome.net резолвятся корректно?

      • 27 октября, 2011 at 12:17
        18

        можно продолжить общение по почте… i(собака)k-max.name

  10. greenfox82
    9 декабря, 2011 at 11:04
    19

    Отличная статья и замечательный блог!
    Помогите пожалуйста решить такую проблему:
    Есть локальная сеть с выходом в Интернет через PPPoE.
    Есть DNS сервер с локальным адресом IP_DNS_LOCAL и интернет адресом IP_DNS_INET.
    Так же имеется сайт с локальным адресом IP_WWW_LOCAL и интернет адресом IP_WWW_INET.
    Проблема в том, что невозможно получить доступ к сайту по локалке с отключенным инетом.
    При обращении к ДНС серверу по локальной сети он возвращает
    интернетный адрес сайта IP_WWW_INET, а не IP_WWW_LOCAL. Соответственно по IP_WWW_INET
    зайти на сайт невозможно, ведь интернет отключен.
    Мой днс сервер является кэширующим, а авторизированные сервера для моей зоны
    находятся у хостинг провайдера.Помогите плиз разобраться.
    Правильно я понимаю, что такое можно настроить с помощью VIEW. Например
    указать определенный view и сделать этот ДНС авторизированным сервером для моей
    зоны, но только в локальной сети. Пробовал, но пока не очень получается, хотя кое с чем разобрался.

    • 9 декабря, 2011 at 11:15
      20

      Да, верно. Это нужно реализовать через VIEW, либо сделать еще один DNS в локальной сети, указывающий на IP_WWW_LOCAL и подсунуть его локальным клиентам.

  11. greenfox82
    9 декабря, 2011 at 16:07
    21

    Спасибо! MC.Sim, может напишите статью по view, у вас хорошо объяснять получается =)

    • 9 декабря, 2011 at 16:13
      22

      Пожалуйста. Не исключено, что напишу, ибо в планах такое имеется… Но пока другие приоритеты…

  12. TerAnYu
    25 января, 2012 at 18:11
    23

    Уважаемый Mc.Sim, Вы писали: “Рассматривать файлы “петлевых” и бродкастовых зон не вижу смысла…”
    Привели хотя бы содержание этих файлов без объяснений, т.к. руководствуясь этой статьёй настраиваю BIND на Windows, а там этих файлов нет.
    Спасибо.

    • 26 января, 2012 at 17:11
      24

      Примерное содержимое данного файла приведено тут со слов

      // нижеописанные зоны определяют сервер авторитетным для петлевых
      // интерфейсов, а так же для броадкаст-зон (согласно RFC 1912)

      до слов

      // описание основной зоны

  13. TerAnYu
    26 января, 2012 at 18:54
    25

    Я хотел попросить выложить эти файлы:
    0.in-addr.arpa
    255.in-addr.arpa
    db.root – нашёл где он лежит: ftp://ftp.internic.net/domain/db.cache
    localhost

    А текст файла 127.in-addr.arpa уже приведён.

  14. TerAnYu
    27 января, 2012 at 19:04
    27

    Премного благодарен!
    Только ключи от DNS там не надо было выкладывать ….

    • 27 января, 2012 at 23:22
      28

      Это ключи с виртуалки, которая прожила всего 30 минут, так что не страшно :)

  15. Влад
    3 апреля, 2012 at 14:42
    29

    Приветствую.

    Тут уже второй день изучаю настройку BIND9. Огромное спасибо за хорошие и доступные публикации. У меня вопрос…

    Даже не вспомню уже как, но вышло что в /etc/bind/named.conf директория не:

    directory “/var/cache/bind”;

    а:

    directory “/etc/bind”;

    И, соответственно, там лежат db.root и прочие.

    Насколько это вообще корректно, в чем разница?

    И второе. При установке пакета руководствовался вот этим: http://system-administrators.info/?p=1798 но честно говоря, не сильно еще во всех этих премудростях разбираюсь, не могли бы вы прокомментировать написанное там, насколько оно корректно?

    Заранее огромное СПАСИБО! :)

    • 3 апреля, 2012 at 16:08
      30

      Приветствую

      Насколько это вообще корректно, в чем разница?

      Вполне корректно. Разница лишь в том, что при описании DNS зон в named.conf, если указывать не полный путь в file “….”, а только имя файла, то этот файл будет искаться в вашем случае в directory «/etc/bind»;.

      И второе. При установке пакета руководствовался вот этим: http://system-administrators.info/?p=1798 но честно говоря, не сильно еще во всех этих премудростях разбираюсь, не могли бы вы прокомментировать написанное там, насколько оно корректно?

      В указанной статье рассказывается, как установить и запустить bind в chroot среде. Я считаю это целесообразным только в том случае, если сервер работает и обрабатывает запросы из интернета. В остальных случаях – достаточно стандартного запуска bind без chroot. Если хочется побольше почитать об установке ПО в Linux, могу посоветовать мою статью: Управление программным обеспечением в Linux

      • Влад
        4 апреля, 2012 at 12:03
        31

        Почитал. Только не понял смысл “chroot среды”. Да, сервер нужен для обработки запросов с нета.

        Я просто где-то на инглыш ресурсе, чуть ли не официальном, читал про подобное, и там оно делалось иначе. Я более по веб-программированию, к администрированию и настройке только недавно начал переходить. Понимаю, что к одной цели можно прийти разными путями… Просто раздражает, когда ты делаешь что-то, но не понимаешь суть происходящего, в чем именно смысл…

        Бум разбираться потихоньку. А чем вообще, к примеру, грозит работа днс-сервера, обрабатывающего запросы с нета, без работы в chroot среде?

        • 4 апреля, 2012 at 17:43
          32

          Просто раздражает, когда ты делаешь что-то, но не понимаешь суть происходящего, в чем именно смысл…

          Это достойно уважения :)

          А чем вообще, к примеру, грозит работа днс-сервера, обрабатывающего запросы с нета, без работы в chroot среде?

          chroot – это когда для сервиса корень файловой системы изменяется на определенный каталог. В примере с bind из указанной статьи – это /var/lib/named. То есть, фактически, сервер работает из /var/lib/named, но думает, что это корень. И если bind сломают, то тот, кто получит доступ к среде, в которой работает bind. будет думать, что на машине кроме bind ничего нет… о chroot написано кратко в википедии.

  16. Влад
    3 апреля, 2012 at 14:54
    33

    Еще такой вопрос:

    recursion no; // запретить рекурсивные запросы

    А зачем их запрещать? В чем суть?

    • 3 апреля, 2012 at 16:16
      34

      Тут важно понимать разницу между итеративными запросами и рекурсивными. Для этого нужно почитать теорию о DNS.
      Весь смысл в назначении сервера. Если это, например, пограничный сервер с локальной сетью во внешнюю, и серверу нужно кэшировать проходящие рекурсивные запросы, то конечно есть смысл разрешить такие запросы. Но если это сервер, который обрабатывает запросы из интернета для своей зоны, то конечно лучше запретить рекурсивные запросы, чтобы, например, снизить нагрузку на сервер, но могут быть и другие причины, например – безопасность….

      • Влад
        4 апреля, 2012 at 12:07
        35

        Да, я раньше уже ознакамливался и знаю что это такое.

        Просто самого смысла отключения не понимаю. ДНС на веб-сервере для поддержки собственных доменов. Да, чисто теоретически, кто-то может сесть серваку на “уши”… Но на практике – в такое просто не верится. А если захотят нагрузить, нагрузят и без этого, ИМХО.

        А что в плане безопасности (отключения рекурсии)? Можно почитать что-то?

        • 4 апреля, 2012 at 17:58
          36

          Какую-то ссылку со всеми советами безопасности дать затрудняюсь… Разве что из ссылок “Что читать:”

  17. Влад
    3 апреля, 2012 at 14:59
    37

    Сорри за спам :) такой еще квесшн:

    Если в /etc/bind/named.conf указан allow-transfer то в описании зон:

    // описание основной зоны
    zone “example.com” {
    type master;
    file “example.com”;
    allow-transfer { 10.0.0.191; };
    };

    Его указывать уже не обязательно, он будет наследоваться (разве что чтоб указать специфический allow-transfer для конкретной зоны), верно? :)

    • 3 апреля, 2012 at 16:20
      38

      Все верно.

  18. Влад
    10 апреля, 2012 at 11:51
    39

    Приветствую снова.

    Подымаю первичный и вторичный ДНС-сервера под веб-сервер. Что-то никак не получается заставить слейв обновлять зоны. Ставил рефреш = 60 секундам, перезагружал сервера /etc/init.d/bind9 start (по одному и оба) перезагружал через rndc reload (аналогично). Результата 0,00. В логах чисто, попыток никаких нет.

    На мастере стоит:

    allow-transfer { slave_ip; };
    notify YES;

    На слейве:

    masters { master_ip; };
    allow-notify { master_ip; };

    Мне кажется, я как-то не так вношу изменения в зоны на мастере (просто редактирую их через nano). С другой стороны, сервер на мастере ребутился, уж после этого по-любасу должен был релоадить свой конфиг (в логах есть – zone example.com/IN: loaded serial …) и отсылать оповещения (или нет? в логах они вообще пишутся?). Про сериал не забываю.

    Да, и самое интересное, есть заребутить сам сервер, где стоит мастер, то на слейве в момент загрузки мастера проходит обновление. Слейв при этом ребутить не обязательно. Но если заребутить просто сам слейв – ничего.

    Что это может быть??? *CRAZY*

    • 10 апреля, 2012 at 13:21
      40

      чтобы дать какой-то ответ, нужно увидеть конфиг сети с мастера и слейва, конфиг named.conf со всеми включенными в него файлами и содержимое файлов зон.
      ну и так, чисто для теста, что выдает команда на слейв сервере:
      dig @ip.мастер.сервера передаваемая.зона. axfr

    • 10 апреля, 2012 at 13:24
      41

      под конифгом сети понимаю следующее:
      1. вывод ip addr show && ip link show && ip route show
      2. вывод iptables-save

      • Влад
        10 апреля, 2012 at 14:20
        42

        Покопался еще в настройках (уже дня три копаюсь, читаю, голова кругом от всего этого…), добился что слейв обновляется по /etc/init.d/bind9 restart или rndc reload на мастере. Т.е. через nano вношу изменения в файл зоны, сохраняю файл, после чего rndc reload – и через пару минут слейв все обновляет у себя.

        Но, честно говоря, смущает что слейв сам не обновляет (рефреш то для чего?). Или при рестарте работает не нотифи, а как раз рефреш, он и раньше все время “долбит” мастера, просто на том файлы обновлены, но сам он это не понимает? Х3, уже голова кругом.

        Вот данные, если что надо будет уточнить, спрашивайте, iptables еще не настроен:
        Показать »

        ###
        ###SLAVE
        ###

        root@Debian-60-squeeze-64-LAMP /etc/bind # dig @***MASTER_IP*** example.com axfr

        ; <> DiG 9.7.3 <> @***MASTER_IP*** example.com axfr
        ; (1 server found)
        ;; global options: +cmd
        example.com. 60 IN SOA localhost. root.localhost. 2012040990 60 60 60 60
        example.com. 60 IN NS localhost.
        example.com. 60 IN A 192.168.0.1
        http://www.example.com. 60 IN CNAME example.com.
        example.com. 60 IN SOA localhost. root.localhost. 2012040990 60 60 60 60
        ;; Query time: 1 msec
        ;; SERVER: ***MASTER_IP***#53(***MASTER_IP***)
        ;; WHEN: Tue Apr 10 11:58:02 2012
        ;; XFR size: 5 records (messages 1, bytes 163)

        ###
        ###MASTER
        ###

        root@Debian-60-squeeze-64-LAMP ~ # ip addr show && ip link show && ip route show
        1: lo: mtu 16436 qdisc noqueue state UNKNOWN
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
        inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
        2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
        link/ether … brd …
        inet ***MASTER_IP***/27 brd … scope global eth0
        inet6 …/64 scope link
        valid_lft forever preferred_lft forever
        1: lo: mtu 16436 qdisc noqueue state UNKNOWN
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
        link/ether … brd …
        …/27 via … dev eth0
        …/27 dev eth0 proto kernel scope link src ***MASTER_IP***
        default via … dev eth0

        ###
        ###SLAVE
        ###

        root@Debian-60-squeeze-64-LAMP /etc/bind # ip addr show && ip link show && ip route show
        1: lo: mtu 16436 qdisc noqueue state UNKNOWN
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
        inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
        2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
        link/ether … brd …
        inet ***SLAVE_IP***/29 brd … scope global eth0
        inet6 …/64 scope link
        valid_lft forever preferred_lft forever
        1: lo: mtu 16436 qdisc noqueue state UNKNOWN
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
        link/ether … brd …
        …/29 via … dev eth0
        …/29 dev eth0 proto kernel scope link src ***SLAVE_IP***
        default via … dev eth0

        ###
        ###named.conf (MASTER & SLAVE)
        ###

        root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/named.conf
        include “/etc/bind/named.conf.options”;
        include “/etc/bind/named.conf.local”;
        include “/etc/bind/named.conf.default-zones”;
        include “/etc/bind/myzones.conf”;

        ##
        ##myzones.conf MASTER
        ##

        root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/myzones.conf
        zone “example.com” {
        type master;
        file “/etc/bind/example.com”;
        };

        ##
        ##myzones.conf SLAVE
        ##

        root@Debian-60-squeeze-64-LAMP /etc/bind # cat myzones.conf
        zone “example.com” {
        type slave;
        file “/etc/bind/example.com”;
        masters { ***MASTER_IP***; };
        allow-notify { ***MASTER_IP***; };
        };

        ##
        ##example.com
        ##

        root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/example.com
        $ORIGIN example.com.
        $TTL 60;
        @ IN SOA localhost. root.localhost. (
        2012040990;
        60;
        60;
        60;
        60;
        )
        @ IN NS localhost.
        @ IN A 192.168.0.1
        www IN CNAME example.com.

        ##
        ###named.conf.options SLAVE
        ##

        root@Debian-60-squeeze-64-LAMP /etc/bind # cat /etc/bind/named.conf.options
        acl “net_params” { ***SLAVE_IP***; 127.0.0.1; };
        acl “master_ns” { ***MASTER_IP***; };

        options {
        directory “/etc/bind”;

        listen-on { net_params; };
        allow-query { any; };
        allow-query-cache { any; };
        allow-recursion { 127.0.0.1; };
        allow-notify { master_ns; };

        allow-transfer { none; };
        notify NO;

        version “unknown”;

        auth-nxdomain NO;
        listen-on-v6 { none; };
        };

        ##
        ###named.conf.options MASTER
        ##

        root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/named.conf.options
        acl “net_params” { ***MASTER_IP***; 127.0.0.1; };
        acl “slave_ns_list” { ***SLAVE_IP***; };

        options {
        directory “/etc/bind”;

        listen-on { net_params; };
        allow-query { any; };
        allow-query-cache { any; };
        allow-recursion { 127.0.0.1; };
        allow-notify { none; };

        allow-transfer { slave_ns_list; };
        notify YES;

        version “unknown”;

        auth-nxdomain no;
        listen-on-v6 { none; };
        };

        И такой еще вопрос: что можете посоветовать почитать по теме внесения новых зон на слейв-сервера? Сейчас пробую написать php-скрипт, и выполнять эти действия им, но что то мне подсказывает что должно быть более подходящее решение, поближе к системе. Перечитал сегодня с полдесятка различных статей по данной теме, ничего не понравилось.

        Заранее благодарю!

        • 10 апреля, 2012 at 15:51
          43

          Во-первых, все же я бы поставил параметр allow-transfer { slave_ns_list; }; для конкретной зоны, ибо установив его в разделе options мы тем самым разрешаем передачу всех ненужным для передачи зон (например localhost, 127.in-addr.arpa и др.).
          Во-вторых, файл зоны я бы записал в формате:
          root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/example.com
          $ORIGIN example.com.
          $TTL 60;
          @ IN SOA example.com. root.example.com. (
          2012040990;
          100;
          80;
          60;
          60;
          )
          @ IN NS example.com.
          @ IN A 192.168.0.1
          www IN CNAME example.com.

          Думаю, что вся проблема была в том, что у зоны в поле DATA имя главного DNS указан localhost, это некорректно. Вообще, в DNS использовать нотацию localhost нигде нельзя.
          А вот вопрос

          И такой еще вопрос: что можете посоветовать почитать по теме внесения новых зон на слейв-сервера?

          я не понял. Слейв сервер не предназначен для редактирования зон.
          Просто на тот сервер который отвечает за зоны в качестве slave-сервера разместить так же – mater зоны.

          • Влад
            10 апреля, 2012 at 16:10
            44

            Благодарю, исправлю.

            Скажите, так что с внесением изменением? Вот на мастере я правлю файл example.com в редакторе, нужно выполнять rndc reload чтобы мастер увидел изменения, и чтобы слейв обновил данные у себя? Или это вообще должно происходить автоматически, достаточно просто отредактировать файл? Вот это непонятно, и ни где не описывается.

            По поводу второго вопроса. Я вот что имею в виду. Добавляю на мастере в myzones.conf к примеру, example2.com, создаю файл example2.com – как сделать так, чтоб слейв то же самое автоматом сделал и у себя, такое можно?

            • 10 апреля, 2012 at 16:47
              45

              Да, после редактирования зоны необходимо делать релоад сервера, чтобы он перечитал конфиги. А перед релоадом желательно сделать
              named-checkconf
              и
              named-checkzone zonename filename
              это спасет от ошибок в конфигах bind и описании зон.

              По второму вопросу – если добавляется новая мастер-зона, то слейв-зону нужно обязательно описовать. Если вносятся изменения в существующую зону, то достаточно релоада.
              слэйв обновит информацию сам.

            • 10 апреля, 2012 at 16:50
              46

              Так же, если сервер смотри в интернет, то я бы посоветовал почитать про DNSSEC для повышения безопасности.

              • Влад
                10 апреля, 2012 at 16:59
                47

                Ок, благодарю, почитаю. Пока еще ничего в открытое плаванье не запускаю, тренируюсь. :)

                Если надо обязательно релоадить, значит все работает, гуд. :)

                “если добавляется новая мастер-зона, то слейв-зону нужно обязательно описывать” – т.е. BIND тут не помощник, мне самому придется руками, скриптами или еще какими другими средствами вносить в файл (к примеру, myzones.conf) на слейве инфу о новой зоне?

                ОГРОМНОЕ СПАСИБО ЗА ПОМОЩЬ! :)

              • 10 апреля, 2012 at 17:06
                48

                пожалуйста. Приходите еще! ))

  19. Влад
    11 апреля, 2012 at 20:09
    49

    Уже почти все что надо сделал. Но столкнулся со странной ошибкой на слейве.

    # cat named.conf.options
    acl “net_params” { …; };
    acl “master_ns” { 1.2.3.4; };

    options {

    Файл со списком моих зон:
    zone “domain.ru” {type slave;file “/etc/bind/slave/domain.ru”;masters {master_ns;};allow-notify {master_ns;};};

    При релоаде возникает ошибка:

    received control channel command ‘reload’
    loading configuration from ‘/etc/bind/named.conf’
    /etc/bind/myzones.conf:1: unable to find masters list ‘master_ns’
    reloading configuration failed: failure

    Если вместо master_ns указывать IP – все все проблем, ясная речь. В чем дело? На мастере все по тому же принципу прекрасно работает, если master_ns использовать в options из named.conf.options – тоже без проблем. Сам named.conf.options инклудится, конечно же, первым, myzones.conf – вообще последним… Что скажите?

    • 11 апреля, 2012 at 20:24
      50

      а если указать
      acl «net_params» { …; };
      acl «mn» { 1.2.3.4; };

      и
      zone «domain.ru» {
      type slave;
      file «/etc/bind/slave/domain.ru»;
      masters {mn;};
      allow-notify {mn;};};
      ?

      • Влад
        11 апреля, 2012 at 21:13
        51

        То же самое. Ерунда какая-то… %)

        • 11 апреля, 2012 at 21:17
          52

          можно все содержимое конфигов? Где-то видимо синтаксическая ошибка.

          • Влад
            11 апреля, 2012 at 21:32
            53

            Я тут обратил внимание на лог: /etc/bind/myzones.conf:1: unable to find masters list ‘master_ns’… masters list!?Сделал так:

            zone «domain.ru» {type slave;file «/etc/bind/slave/domain.ru»;masters {1.2.3.4;};allow-notify {master_ns;};};

            Все ок. Вообще ничего не пойму?

            Если надо, конфиг обязательно завтра скину, уже бегу-опаздываю… Всего хорошего.

            • 11 апреля, 2012 at 21:34
              54

              Всего :)

              • Влад
                12 апреля, 2012 at 14:08
                55

                Вот конфиги со слейва. Если что еще надо будет, пишите.

                root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/named.conf
                include “/etc/bind/named.conf.options”;
                include “/etc/bind/named.conf.local”;
                include “/etc/bind/named.conf.default-zones”;
                include “/etc/bind/zones.conf”;

                #
                #
                #

                root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/named.conf.options
                acl “net_params” { SLAVE_REAL_IP; 127.0.0.1; };
                acl “master_ns” { MASTER_REAL_IP; };

                options {
                directory “/etc/bind”;

                listen-on { net_params; };
                allow-query { any; };
                allow-query-cache { any; };
                allow-recursion { 127.0.0.1; };
                allow-notify { master_ns; };

                allow-transfer { none; };
                notify NO;

                version “unknown”;

                auth-nxdomain NO;
                listen-on-v6 { none; };
                };

                #
                #
                #

                root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/zones.conf
                zone “myrealdomain.ru” {type slave;file “/etc/bind/slave/myrealdomain.ru”;masters {MASTER_REAL_IP;}; allow-notify {master_ns;};};

                #
                #
                #

                root@Debian-60-squeeze-64-LAMP ~ # cat /etc/bind/slave/myrealdomain.ru
                $ORIGIN .
                $TTL 900 ; 15 minutes
                myrealdomain.ru IN SOA ns1.myrealdomain.ru. root.myrealdomain.ru. (
                2012041101 ; serial
                28800 ; refresh (8 hours)
                7200 ; retry (2 hours)
                1209600 ; expire (2 weeks)
                600 ; minimum (10 minutes)
                )
                NS ns1.myrealdomain.ru.
                NS ns2.myrealdomain.ru.
                A MASTER_REAL_IP
                $ORIGIN myrealdomain.ru.
                ns1 A MASTER_REAL_IP
                ns2 A SLAVE_REAL_IP
                www CNAME myrealdomain.ru.

                На мастере он ^^^ (myrealdomain.ru) немного иначе записан, слейв сам так его форматирует…

              • 12 апреля, 2012 at 18:47
                56

                попробуй везде, где используешь master_ns, заменить master_ns на mn.
                Проверь, заведется или нет…

              • Влад
                13 апреля, 2012 at 16:20
                57

                Нашел ответ – http://old.nabble.com/4.2-and-4.3-BIND:-masters_list-does-not-work-with-masters-option-td18329278.html

                Странно, но получается что для masters надо писать что-то типа: masters “master_ns” {1.2.3.4;}; и далее уже юзать masters {master_ns;}; но почему через acl нельзя???

                Кстати, можно создавать acl и masters с одинаковыми именами, работает. Но что-то мне эта идея не нравится. :)

  20. Влад
    12 апреля, 2012 at 15:55
    58

    Еще пара уточняющих вопросов.

    – е-майл в SOA записи можно указывать любой, не обязательно на том же домене, который описывает запись?
    – слышал, что в роли серийного номера можно использовать любое число (например, timestamp), лишь бы его значение увеличивалось при каждом внесении изменений, это верно? будут ли его в такой форме (timestamp, а не ГГГГММДДnn) корректно воспринимать остальные неймсервера?

    • 12 апреля, 2012 at 18:51
      59

      е-майл это информационное поле. Можно там указать хоть полную чушь.
      серийный номер можно использовать любой, лишь бы он обновлялся на большее значение при обновлении зоны. Я предпочитаю использовать именно в виде даты. Это очень наглядно и удобно.

      • Влад
        13 апреля, 2012 at 16:21
        60

        Понятно, спасибо. :)

  21. Влад
    14 апреля, 2012 at 16:20
    61

    Хм, столкнулся с еще одной интересной вещью.

    Смотрите, заводим новую зону. Как делаю:

    1. Заношу данные о зоне на мастере в файл типа zone.conf
    2. Создаю на мастере файл с настройками домена этой зоны.
    3. Заношу данные о зоне на слейве в файл типа zone.conf
    4. rndc reload на мастере
    5. rndc reload на слейве (чтоб он заметил обновления в zone.conf и запросил у мастера данные)

    Но заметил, что на 4-м шаге возникает ошибка:

    Apr 14 14:02:33 Debian-60-squeeze-64-LAMP named[1234]: client 1.2.3.4#12345: received notify for zone ‘domain.ru’: not authoritative

    Т.е. мастер видит новую зону, посылает слейву нотифи… НО слейв еще не видит обновления в своем zone.conf, и ругается что ему “пихают” какой-то левый домен.

    Это, конечно, не критично. Но может я все же не все делаю верно, есть более оптимальный путь?

    • 14 апреля, 2012 at 21:06
      62

      можно содержимое файла зоны и конфиг с мастера и слейва? )))

    • 14 апреля, 2012 at 21:07
      63

      на pastebin.com

    • 18 апреля, 2012 at 11:10
      64

      1. что за записи
      @ IN NS ns1.myserver.ru.
      @ IN NS ns2.myserver.ru.

      куда они указывают?
      2. в целом, ошибка
      Apr 14 14:02:33 Debian-60-squeeze-64-LAMP named[1234]: client 1.2.3.4#12345: received notify for zone ‘domain.ru’: not authoritative
      некритична, ведь в момент релоада мастер сервера, слейв еще об этой зоне ничего не знает, а местер пытается отправить уведомление о внесении изменений. Поэтому и ошибка.

      • Влад
        20 апреля, 2012 at 17:35
        65

        1. НС-сервера указываются. А что не так?

        2. Ну это понятно. Думал, может способ есть какой избежать этого или делается все чуть иначе, чтоб не возникало таких ошибок.

        • 22 апреля, 2012 at 02:21
          66

          1. ну то есть эти сервера указывают правильно на Ваш мастер и слейв?

          • Влад
            25 апреля, 2012 at 11:36
            67

            Должны :)

            $ORIGIN myserver.ru.
            $TTL 900;
            myserver.ru. IN SOA ns1.myserver.ru. root.myserver.ru. 2012041201 28800 7200 1209600 600
            @ IN NS ns1.myserver.ru.
            @ IN NS ns2.myserver.ru.
            @ IN A *MASTER_IP*
            ns1 IN A *MASTER_IP*
            ns2 IN A *SLAVE_IP*
            www IN CNAME myserver.ru.

            • 25 апреля, 2012 at 20:17
              68

              да, так прозрачнее :)

  22. Влад
    17 апреля, 2012 at 12:21
    69
  23. Евгений
    29 июня, 2012 at 17:06
    70

    Спасибо за статью! Очень хорошо и подробно написано.

    Делаю всё это первый раз, очень интересно.
    Задача: Надо было поднять одну сеть, в которой будут две зоны днс, и часть компов будет в zone1.lan другая часть в zone2.lan. Те что в zone1 могут резолвить все компы сети и сайты в интернете, ты что в zone2 только компы из своей зоны и некоторые сайты. В дальнейшем надо чтобы все компы сети могли видеть netbios имена друг друга и ходить по шарам (поэтому и одна сеть).
    Вопрос: целесообразно ли вообще так делать, или лучше просто поделить компы разных зон на две разных подсети в которых организовать свои зоны днс? Или надо вообще как-то по другому?

    Не знал как правильно, поэтому пошёл таким путём.

    acl “lan” { 192.168.0.0/16; };
    options {
    listen-on port 53 { lan; localhost; };
    listen-on-v6 port 53 { none; };
    allow-query { localhost; lan; };
    allow-transfer { none; };
    recursion yes;
    allow-recursion { localhost; };
    };
    zone “zone1.lan” IN {
    forward FIRST;
    forwarders { 8.8.8.8; };
    type master;
    file “zone1.ca”; # в нём прописал все компы сети
    };
    zone “zone2.lan” IN {
    type master;
    file “zone2.ca”; # в нём прописал только компы этой зоны, и некоторые сайты
    };
    zone “168.192.in-addr.arpa” {
    type master;
    file “168.192.in-addr.arpa.ca”; # в нём прописал все компы сети
    };

    Вопрос: если поставить recursion no, то сам сервер не сможет резолвить имена сети, остальные компы смогут. Никак не могу понять почему?
    Вопрос: комп из zone2 при обратном запросе компа из zone1 ответит его ip адресом. Можно ли сделать чтобы такого не было?

    Может я конечно глупости пишу, по незнанию, но это всё от того что ХОЧУ ПОНЯТЬ :), извините если что.

    • 14 июля, 2012 at 15:08
      71

      Приветствую, Евгений. Извиняюсь, что долго отвечал – жизненные перемены )
      Необходимо разделить понятие netbios и dns. Чтобы понять, что такое netbios и как работает, нужно почитать статью как работает самба и как работает самба часть 2. Про dns написано в текущей статье. Это 2 разные технологии, но выполняющие похожие функции.
      В результате, чтобы ходить по шарам и видеть нетбиос имена – достаточно настроить самбу на сервере.
      В вишем случае проще всего сделать 2 разные не связанные подсети и для шар, как я уже говорил, использовать самбу. ДНС же использовать как кэширующий для разрешения интернет-адресов.
      по второму вопросу – если для локальной сети для разрешения имен будет использоваться самба и будут 2 разные подсети, то использовать днс нет необходимости и компы из разных рабочих групп не будут резолвить друг-друга.
      Примерно так…

  24. 22 июля, 2012 at 15:49
    72

    Хорошая статья, но вот тут явно неточность:

    Да, чуть не забыл, демон named должен быть разрешен для запуска на необходимых уровнях выполнения ОС (команда в RedHat – /sbin/chkconfig dhcpd on, в Debian – /usr/sbin/update-rc.d dhcpd defaults).

    ИМХО – dhcpd вроде как демон DHCP )) а тут статья про ДНС… но я по RHEL-based не оч ориентируюсь…

    • 29 июля, 2012 at 12:01
      73

      Конечно, MetalMad. Спасибо за замечание!
      Исправил опечатку.

  25. Лев
    11 января, 2013 at 20:35
    74

    Макс!
    Извини заранее за ламерский вопрос, но не совсем понял касательно настройки зон и вариантов запросов…

    Чем различаются вот эти параметры в описании зон?

    @ – в описании SOA
    $ORIGIN
    @ORIGIN
    Или они означают одно и то же в настройках зоны?

    $TTL – чем отличаются настройки перед SOA и уже перед самими хостами?

    Итеративный и рекурсивные запросы – в чём конкретно разница? По мне, речь идёт об одном и том же..

    Заранее благодарен за ответ и за хорошую статью! Очень многое узнал благодаря тебе *THUMBS UP*

    • 28 января, 2013 at 21:44
      75

      Приветствую, Лев.
      Для большего понимания всего описанного, необходимо перед данной статьей прочитать основы DNS. Там хорошо расписаны Итеративный и рекурсивные запросы и остальные параметры.
      В двух словах,
      1. при задании $TTL в начале файла зоны – задаются глобальные параметры TTL. При задании индивидуальных значений TTL – они как бы переписывают глобальные значения что ли… Как-то так.
      2. символ @ – это переменная, хранящая имя зоны, которая указана в конфигурационном файле named.conf или в директиве @ORIGIN текущего описания зоны. То есть мы тупо вместо имени, которое задано в named.conf подставляем символ @. Это позволяет нам менять имя зоны только в одном месте. Например мы решили переименовать домен и нам не надо в каждом файле искать и менять имя. Мы меняем в named.conf и в файлах зоны оно подхватывается автоматом, т.к. задано символом @.
      3. $ORIGIN – изменяет имя зоны с указанного в файле named.conf. @ORIGIN – это опечатка. Вместо символа @ – $. )))

  26. Лев
    28 января, 2013 at 22:36
    76

    Макс, спасибо огромное! Теперь практически всё стало понятно ))
    Только еще раз хотел уточнить про запросы, правильно ли я понимаю: %)
    1. Итеративный запрос – это когда DNS-сервер получая запрос от клиента, просматривает свой кэш и выдает наилучший ответ из имеющихся у него. Это может быть ссылка на другой DNS-сервер. Далее клиент сам (не DNS сервер) продолжает резолвинг нужного доменного имени. Так?
    2. Рекурсивный – это когда DNS-сервер получая запрос от клиента, должен опросить другие сервера (если нужной информации нет в своем кэше) и
    вернуть клиенту уже готовый ответ. И то, что с использованием рекурсивных запросов достигается лучшая производительность, т.к. нагрузка на свой DNS сервер минимальна. Так?

    Еще раз спасибо!

    • 28 января, 2013 at 23:01
      77

      Примерно так. только:
      1. Итеративный запрос — это когда DNS-сервер получая запрос от клиента, просматривает свой кэш, кроме кэша сервер просматривает свои зоны, если они у него заданы и выдает наилучший ответ из имеющихся у него. Это может быть ссылка на другой DNS-сервер (я не помню, то ли возвращается адрес корневых NS серверов, то ли ответственных за зону…), если DNS-сервер не обнаружил у себя нужную запись. Далее клиент сам (не DNS сервер) продолжает резолвинг нужного доменного имени. Так? (при этом, необходимо понимать, что под клиентом в данных утверждениях имеется в виду резолвер).

      2. Рекурсивный – это когда DNS-сервер получая запрос от клиента, должен опросить другие сервера (если нужной информации нет в своем кэше) и
      вернуть клиенту уже готовый ответ. И то, что с использованием рекурсивных запросов достигается лучшая производительность клиентов, т.к. нагрузка на свой DNS сервер минимальна сервер собирает и кэширует всю полученную информацию. В результате закэшированные данные отдаются клиенту быстрей. Так?

      а так же
      И то, что с использованием рекурсивных итеративных запросов достигается лучшая производительность серверов, т.к. нагрузка на свой DNS сервер минимальна за счет того, что сервер не взаимодействует с вышестоящими серверами, ответственными за другие зоны, а тупо выдает только то, что у него есть.

      • Лев
        29 января, 2013 at 13:37
        78

        (при этом, необходимо понимать, что под клиентом в данных утверждениях имеется в виду резолвер).
        т.е. резолвер клиентской машины, а не DNS сервера?

        • 4 февраля, 2013 at 00:19
          79

          В данном контексте – да.

  27. Лев
    4 февраля, 2013 at 22:20
    80

    Макс, спасибо большое!
    Ты очень помог и твой блог – просто супер! =)

  28. Кирилл
    5 июня, 2013 at 01:08
    81

    Доброй ночи,

    Возникла такая проблемма. Есть виртуальный сервер на котором поднял LAMP. Всё настроенно всё работает. Так как регестрировали домены в nic.lv то прописывали там name server типа A на конкретные два IP адресса с которыми работает сервер.
    Но пришло время где надо было зарегестрировать доменное имя на godaddy и там требуются два NS. И теперь я столкнулся с проблеммой как всё оформить.
    Изпользовать какой то бесплатный DNS чтобы прописать ns1.example.com и ns2.example.com или поднять у себя bind9 который будет с ними работать?

    чтобы вы посоветовали?

    • 6 июня, 2013 at 13:43
      82

      Здравствуйте.

      Так как регестрировали домены в nic.lv то прописывали там name server типа A на конкретные два IP адресса с которыми работает сервер.

      На nic.lv вы прописали не name server, а ресурсные записи, которые в результате записались в конфиг DNS серверов на nic.lv.
      Для того чтобы заработал Ваш домен на godaddy, Вам необходимо поднять 2 DNS сервера, IP адреса которых указать в панели управления регистратора. Но обычно у регистраторов имеются высокие требования к данным серверам (должны быть размещены в разных подсетях, стабильно отвечать на запросы в течении такого-то времени и т.п.), поэтому проще купить услугу http://www.godaddy.com/domains/dns-hosting.aspx. Есть бесплатный вариант на яндексе: http://help.yandex.ru/pdd/hosting.xml

      • Кирилл
        9 июня, 2013 at 16:07
        83

        Ясно, большое спасибо за ответ. Будем пользоваться яндексом.
        Просто думали изначально что будет не так сложно поднять DNS сервер, но оказалось не так просто :)

        • 12 июня, 2013 at 20:01
          84

          но оказалось не так просто :)

          не вы первые )))

  29. инакентий
    3 сентября, 2013 at 13:31
    85

    Как правильно открыть доступ на сервере убунту к компютеру гду стоит виндовс. Сисадним (уволился) сказал что надо это делать через прокси сервер используя днс имя.
    *CRAZY* и тут я монял что я нечего не понял
    хотел прокинуть порты но мне сказали что ето не правильно

    • 5 сентября, 2013 at 22:10
      86

      Чтобы избежать двусмысленности…
      что вы понимаете под словами “открыть доступ”?

      • 9 сентября, 2013 at 21:22
        87

        Ну есть сервер, в качестве шлюза, на ньом лежит сайт,белый IP. Внутри сети есть еще один сервер. Но он не доступен с интернета. как бы так это сделать?
        пробовал открыть порт. не открывается

        • 21 сентября, 2013 at 21:21
          88

          Внутри сети есть еще один сервер.

          повторю свой вопрос…
          что вы понимаете под словами «открыть доступ»?
          уточняю: как какой службе на “еще одном сервере” нужно «открыть доступ»? )

  30. Nurlan
    12 сентября, 2013 at 23:10
    89

    у вас DNS сервер дома что ли!?

    • 21 сентября, 2013 at 21:15
      90

      Кеширующий дома имеется…

  31. Алексей
    30 сентября, 2013 at 10:08
    91

    Доброго времени суток,
    хочу обратиться за советом в решении задачи.
    У меня есть несколько клиентов которые регистрируют в ДНСе более одного из своих интерфейсов (кроме локального подключения еще и ВПН адрес, через который он подключается к моей сети).
    Ситуация требует чтобы этот ВПН адрес не регистрировался вовсе. Или каким-то образом прописать в зоне соответсвие хостнейм-ИПадрес, с указанием что этому хостнейму должен соответствовать только этот ИПадрес.
    При условии что с ВПНадреса клиент должен иметь возможность резольвить хосты в этом ДНСе. Т.е. насмерть запретить его нельзя.
    Буду очень признателен за помощь.
    Спасибо.

    • 26 октября, 2013 at 11:59
      92

      Доброго времени, Алексей.
      Что за клиенты? (какая ОС и что за ПО в качестве ВПН клиента?)

  32. stend
    10 января, 2014 at 09:02
    93

    C данными конструкциями следует быть аккуратными
    A INPUT -m conntrack
    т.к. идёт отслеживание состояния соединений что на нагруженных серверах может привести к переполнению таблицы
    net.ipv4.ip_conntrack_max = 65536
    все последующие соединения будут отбрасываться, что приведёт к деградации сервиса.

    • 17 января, 2014 at 15:22
      94

      О! Это важный нюанс. Спасибо.

  33. BSCheshir
    15 февраля, 2014 at 01:03
    95

    Доброго времени суток!

    Решил настроить dns-сервер в локальной сети для работы с машиной,
    на которой поднят Apache 2.4 и созданы virtualhost.

    Ваши статьи по работе DNS и настройке BING9 очень помогли,
    фактически – первая хорошая статья из 7-8 пересмотренных.

    Однако, я хотел бы прояснить некоторые моменты:

    – два сервера dns (две записи NS) – необходимое условие функционирования сервера имён или требование стандарта и для локальной сети, можно им пренебречь?

    – При создании виртуальных хостов с алиасами поддоменов машины вебсервера необходимо для каждого
    добавить запись в файл описания зоны?
    Возможно, есть какой-то механизм задания отдельно от него,
    у Вас вроде бы упоминался $INCLUDE, не могли бы привести пример использования?

    – У Вас в домене in-addr.arpa.
    присутствуют записи
    * IN PTR examle.com.
    Насколько я понял, это отображение любого из IP сети в доменное имя examle.com. ?
    Для чего это сделано?

    • 4 марта, 2014 at 10:41
      96

      Доброго времени, BSCheshir
      Спасибо за отзыв.

      – два сервера dns (две записи NS) — необходимое условие функционирования сервера имён или требование стандарта и для локальной сети, можно им пренебречь?

      В локальной сети этим требованием можно пренебреч. Это требование RFC для DNS серверов, работающих в глобальной сети.

      – При создании виртуальных хостов с алиасами поддоменов машины вебсервера необходимо для каждого
      добавить запись в файл описания зоны?
      Возможно, есть какой-то механизм задания отдельно от него,
      у Вас вроде бы упоминался $INCLUDE, не могли бы привести пример использования?

      В данной статье есть некое упоминание о “wildcard запись”.

      Если в имени ресурсной записи встречается символ “*”, то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. Такую запись называют “wildcard запись”. Однако, символ “*” не может быть использован где угодно. Это может быть только первый символ в поле Name текущего домена, отделенный от остальных символом “.”

      Думаю, что данного функционала для Вашей задачи будет достаточно. Без $INCLUDE тут можно обойтись.

      – У Вас в домене in-addr.arpa.
      присутствуют записи
      * IN PTR examle.com.
      Насколько я понял, это отображение любого из IP сети в доменное имя examle.com. ?
      Для чего это сделано?

      Это и есть тот самый wildcard. (на примере зоны 0.0.10.in-addr.arpa) данная запись указывает, что все IP из диапазона 1-255.0.0.10.in-addr.arpa, кроме 152 и 191 (т.к. они указаны в зоне явно) будут разрешаться в examle.com.

  34. Vadim
    17 марта, 2014 at 12:33
    97

    Уважаемый Максим!
    Вопрос, видимо, не совсем по теме, извините, однако помогите……

    Суть: при запуске демона named для файла описания одной из зон выдается ошибка:
    Error in named configuration:
    /var/named/kvm.loc.zone:1: unknown option ‘$ORIGIN’
    Ошибка именно по первой строке (можно менять значение переменной на $TTL) суть не меняется.

    Доступ к файлу на чтение-запись есть…
    Файл расположен в директории из “options”…

    Пожалуйста!
    С уважением!

    • 20 марта, 2014 at 10:51
      98

      Показывайте файлы конфигурации и права доступа. (файлы конфигурации желательно архивом)

  35. Андрей
    12 мая, 2014 at 15:20
    99

    Здравствуйте.
    Установил bind9 на debian 7.0
    На всех компьтерах нашей организации прописал ip DNS только что поднятого сервера DNS, альтернативный указал несуществующий.

    Задачи:
    1. Теперь нужно сделать в настройках bind так, чтобы все вводимые адреса в браузере (на компьютерах организации) переадресовывали на сайт организации.
    2. Сделать так чтобы при вводе отдельных сайтов, работник организации попадал на определенный (заранее установленный настрйками bind) сайт.

    Заранее спасибо за ответ.

    • 24 июня, 2014 at 20:33
      100

      Для данных задач больше подходит squid, нежели bind.

    • stend
      29 декабря, 2014 at 18:06
      101

      Рекомендую обратить внимание в сторону RPZ.

  36. Artem
    22 сентября, 2014 at 03:56
    102

    Прочитал статью от сих до сих и не только эту, всё что связано с DNS, узнал много нового и интересного, автору респект, Вы очень прогрессивный человек :)

    Сразу много вопрос родилось, создали бы онлайн чатиГ :)

    • 17 декабря, 2014 at 22:02
      103

      Спасибо.
      К сожалению – на блог времени совсем не остается, а про чат вообще молчу. )

  37. Александр
    29 сентября, 2014 at 11:43
    104

    Здравствуйте ! Подскажите,есть ли разница по производительности 32 и 64 бит ДНС сервер (конфигурация -Центос 6.5 – кеширующий + примари обратных зон + несколько своих зон) клиентов посылающих запросы на данный сервер 25000 – 35000 .Будет еще ДНС Секондари для PTR и своих зон.Главное,есть ли смысл ставить 64 бита.

    • 18 декабря, 2014 at 00:05
      105

      Думаю, что вы не заметите никакой разницы в производительности между 32 и 64 бит. Тут не важно количество клиентов. Тут важен размер зон и настройки сервера (будет ли разрешено кэширование и рекурсивные запросы). Исходя из этого, можно прогнозировать объем занимаемой DNSом памяти. Если получиться больше 2 Гб на процесс, то можно попытаться ставить 64 бит. Но что-то я не представляю себе конфигурацию, при которой сервер может скушать 2 Гб ОЗУ )

  38. Георгий
    21 июля, 2015 at 18:10
    106

    Здравствуйте! Есть DNS-сервер на нем висит одно доменное имя, пусть будет domain1.ru – сайт работает нормально, при попытке повесить еще одно доменное имя на этот же DNS-сервер например domain2.com ничего не получается, вернул запись в состояние для первого домена, подскажите пожалуйста как надо изменить эту запись:

    $ORIGIN domain1.ru. ; default zone domain
    $TTL %ttl% ; default time to live
    domain1.ru. IN SOA ns1 hostmaster (
    2015071801 ; serial number
    600 ; Refresh
    60 ; Retry
    1209600 ; Expire
    %ttl% ; Min TTL
    )

    domain1.ru. %ttl% IN NS ns1.domain1.ru.

    domain1.ru. %ttl% IN A 83.252.91.241
    ns1 %ttl% IN A 83.252.91.241

    • 10 октября, 2015 at 13:28
      107

      В эту запись не стоит включать другой домен.
      Завидите новую зону.
      Теория DNS

  39. Сергей
    7 ноября, 2016 at 14:29
    108

    dns:~# cat /etc/network/interfaces
    auto lo
    iface lo inet loopback

    auto eth0
    iface eth0 inet static
    address 10.0.0.152
    netmask 255.255.255.0
    gateway 10.0.0.254

    auto eth1
    iface eth1 inet static !!!!! По моему тут вместо inetдолжно быть lan !!!!!
    address 192.168.1.1
    netmask 255.255.255.0

    • 17 мая, 2018 at 09:25
      109

      Почему вы так считаете?

  40. Алексей
    14 ноября, 2016 at 18:01
    110

    Добрый день!

    Спасибо большое за статью! Очень сильно помогла разобраться с сервисом bind.
    Единственное наткнулся на проблемы с настройкой логирования.
    Использую ubunu 16.04.1.
    После создания секции logging {} сервис отказывается стартовать. Вот вывод syslog

    Nov 14 17:52:27 named[2938]: isc_stdio_open ‘/tmp/bind/misc.log’ failed: permission denied

    Думал напутал что-то с разрешениями, поэтому перенес из /var/log в /tmp. Но это не помогло.

    Вот вывод ls

    root@:/tmp/bind# ls -la
    total 8
    drwxrwxrwx 2 bind root 4096 Nov 14 17:49 .
    drwxrwxrwt 11 root root 4096 Nov 14 17:49 ..

    Подскажите куда копать?
    Спасибо!

    • 17 мая, 2018 at 09:28
      111

      Загрузите полный конфиг на pastebin?
      Если еще актуально…

  41. 2 мая, 2019 at 09:52
    112

    Автору спасибо, наглядно и доходчиво…

  42. fkdoqyy
    19 мая, 2019 at 13:26
    113

    Спасибо за информацию!!!!!

  43. 4 февраля, 2021 at 15:05
    114

    Сижу познаю секреты bind. Самая подробная и качественная статья только у вас! Спасибо большое за ваш труд!

    • 10 апреля, 2021 at 22:37
      115

      Спасибо, Александр.
      Приходите еще.

  44. Max
    24 февраля, 2021 at 21:14
    116

    Отличная статья, спасибо! Я настраиваю BIND9 на pfSense. У меня есть 2 статичных IP, 2 оператора связи. Сейчас сделал 2 NS записи на разные IP и BIND прослушивает 53 порт для этих IP и выдает IP веб сервера в своей локалке. Это правильно?

    • 10 апреля, 2021 at 22:55
      117

      Правильно или нет, зависит от того, что в итоге вы хотите получить.
      Вы описали несколько фактов, но что нужно в итоге – не совсем понятно.

  45. Юрий
    1 октября, 2023 at 14:18
    118

    Привет. А где прописываются статические записи хостов и как можно вывести все записи зоны, а также все имеющиеся зоны из командной стррки для обработки в скриптах?
    Спасибо.

Написать комментарий