Установка bind centos 7. Основные записи DNS. Проверка MX с помощью dig

04.04.2019

В этом руководстве речь пойдёт об установке и настройке DNS-сервера BIND.

Для выполнения инструкций рекомендуется настроить как минимум два облачных сервера для запуска серверов имен (nameservers); наличие нескольких серверов имён позволяет использовать запасные ресурсы в случае возникновения ошибки. Также можно рассмотреть возможность использования двух разных точек присутствия (POP). Предполагается использование первичного (мастер) и вторичного сервера имен (слейв).

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

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

Установка BIND

Чтобы установить пакеты BIND и bind-utils, используйте yum:

Затем откройте конфигурационный файл BIND и внесите в него некоторые коррективы.

nano -w /etc/named.conf

В файле найдите раздел options, который выглядит так (вместо 2.2.2.2 – IP-адрес второго сервера):

options {

directory "/var/named";

allow-query { any; };
allow-transfer { localhost; 2.2.2.2; };
recursion no;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */

};

Директива listen-on должна быть закомментирована для прослушивания доступных интерфейсов. Директива recursion должна иметь значение off, чтобы предотвратить reflection DDoS-атаки. Директива allow-transfer добавляет в белый список IP-адрес вторичного сервера. кроме того, нужно изменить значение директивы allow-query на any, чтобы предоставить пользователям доступ к зонам.

Затем нужно добавить новую зону для первого домена. Для этого поместите в конце файла named.conf следующий код:

zone "mydomain.com" IN {
type master;
file "mydomain.com.zone";
allow-update { none; };
};

Сохраните изменения в named.conf. После этого можно приступать к созданию файла описания зоны (zone-файла).

Настройка зон BIND

Для начала нужно открыть zone-файл, указав имя, внесённое в предыдущий конфигурационный файл (mydomain.com.zone).

nano -w /var/named/mydomain.com.zone

Внесите в файл нижеприведённый код. Замените условные IP-адреса адресами ваших серверов (1.1.1.1 – IP-адрес первого сервера, 2.2.2.2 – IP-адрес второго сервера, 3.3.3.3 – IP, на который нужно направить домен (например, веб-сервер)). При необходимости внесите в код другие поправки.

$TTL 86400
@ IN SOA ns1.mydomain.com. root.mydomain.com. (
2013042201 ;Serial
3600 ;Refresh
1800 ;Retry
604800 ;Expire
86400 ;Minimum TTL
; Specify our two nameservers
IN NS ns1.mydomain.com.
IN NS ns2.mydomain.com.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
ns1 IN A 1.1.1.1
ns2 IN A 2.2.2.2
; Define hostname -> IP pairs which you wish to resolve
@ IN A 3.3.3.3
www IN A 3.3

Запустите named. Запуск может занять несколько минут, поскольку при первом запуске named создаёт файл rndc.key.

service named restart

После успешного запуска демона named нужно убедиться, что он включён как сервис:

chkconfig named on

Теперь первичный сервер имён полностью готов. Чтобы убедиться в том, что BIND работает должным образом, запустите следующую команду, указав IP сервера вместо 1.1.1.1:

dig @1.1.1.1 mydomain.com

Если полученный результат содержит разделы answer и authority, значит, настройка выполнена правильно.

Настройка слейв сервера

Итак, мастер сервер готов к работе. Теперь нужно настроить вторичный сервер имён на втором облачном сервере.

Убедитесь, что система находится в актуальном состоянии.

Установите BIND и его утилиты на второй облачный сервер:

yum install bind bind-utils -y

Откройте named.conf и внесите в него такие же коррективы, как и на первом сервере, пропустив директиву allow transfer – эта директива не нужна, поскольку записи буду передаваться только с первичного сервера имен.

nano -w /etc/named.conf
options {
#listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
recursion no;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};

Добавьте зоны, настроенные на предыдущем сервере, заменив значение директивы type на slave. Укажите IP первого сервера вместо 1.1.1.1:

zone "mydomain.com" IN {
type slave;
masters { 1.1.1.1; };
file "mydomain.com.zone";
};

Настроив зону slave, запустите демон named. Опять же, на это может уйти несколько минут, поскольку при первом запуске на сервере демон создаёт файл rndc.key.

service named start

Как и на первом облачном сервере, проверьте, работает ли демон named:

chkconfig named on

Вторичный сервер имён теперь готов к работе. Чтобы убедиться, что он работает должным образом, используйте следующую команду, заменив 2.2.2.2 IP-адресом второго облачного сервера.

dig @2.2.2.2 mydomain.com

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

Чтобы перезапустить файлы зоны, используйте следующую команду сначала на мастере, а потом на слейве:

BIND в окружении chroot

В системе CentOS это очень просто. Нужно только отметить, что активные пути BIND будут заменены на chroot-эквиваленты (к примеру, var/named станет /var/named/chroot/var/named). В CentOS 6 не нужно перемещать никаких файлов, поскольку пакет самостоятельно создаст символьные ссылки на не-chroot каталоги.

Чтобы включить эту функцию, используйте:

yum install bind-chroot -y
service named restart

Tags: ,

Представляем вашему вниманию новый курс от команды The Codeby - "Тестирование Веб-Приложений на проникновение с нуля". Общая теория, подготовка рабочего окружения, пассивный фаззинг и фингерпринт, Активный фаззинг, Уязвимости, Пост-эксплуатация, Инструментальные средства, Social Engeneering и многое другое.

Домены имеют как минимум два DNS сервера, один называется первичным сервером имён (ns1), а другой — вторичным сервером имён (ns2). Вторичные сервера обычно задействуются при проблемах с первичным сервером DNS: если один сервер недоступен, то второй становится активным. Возможны и более сложные схемы с использованием балансировки нагрузки, файерволов и кластеров.

Все DNS записи определённого домена добавляются в первичный сервер имён. Вторичный сервер просто синхронизирует всю информацию, получая её от первичного, на основании параметров, заданных на первичном сервере.

Эта инструкция опишет, как создать первичный DNS сервер, работающий на CentOS . Пожалуйста, обратите внимание, что DNS сервер, представленный в этой инструкции, будет публичным DNS, это означает, что сервер будет отвечать на запросы от любого IP адреса. Как ограничить доступ к серверу, описано в этой инструкции.

Перед тем, как мы начнём, хотелось бы упомянуть, что DNS может быть установлен с или без chroot jail окружением. Окружение chroot jail ограничивает DNS сервер определённой директорией в системе, в отличие от полного системного доступа на сервере. Таким образом, любая уязвимость DNS сервера не скомпромитирует всю систему. Ограничение DNS сервера в определённой директории (процесс называется chrooting) также полезно в тестовых условиях.

Цель

Мы настроим DNS сервер в тестовых условиях для домена example.tst, который является гипотетическим (не существующим) доменом. Таким образом, мы не вмешаемся случайным образом в работу каких-либо реальных доменов.

В этом домене есть три следующих сервера.

Сервер	IP адрес	Хостящиеся службы	FQDN
Сервер A	172.16.1.1	Mail	mail.example.tst
Сервер B	172.16.1.2	Web, FTP	www.example.tst ftp.example.tst
Сервер C	172.16.1.3	Primary DNS server	ns1.example.tst

Мы настроем первичный DNS сервер и добавим необходимый домен и DNS записи как показанов в таблице.

Настраиваем имена хостов

Все хосты должны быть корректно определены с точки зрения FQDN . Это может быть сделано с использованием следующего метода.

Те, кто любит графический интерфейс, могут воспользоваться инструментами NetworkManaget. Для этого наберите команду nmtui . Откроется такой псевдографический интерфейс:

Выбираете «Изменить имя узла» и вводите ns1.example.tst

Когда готово, нажимаете и ОК.

Ещё один способ, всего в одну команду:

Hostnamectl set-hostname ns1.example.tst

После установки, имя хоста может быть проверено следующей командой.

# hostname ns1.example.tst

Hostnamectl status

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

Установка пакетов

Мы будем использовать bind для DNS, который с лёгкостью может быть установлен командой yum.

Установка DNS без chroot:

# yum install bind

Установка DNS с chroot:

# yum install bind bind-chroot

Подготовка конфигурационных файлов

Как было упомянуто ранее, bind может быть настроен с или без chroot. Пути немного различаются, в зависимости от того, был ли установлен chroot.

	Путь до конфигурационного файла	Путь до файлов зоны
Без chroot	/etc/	/var/named/
С chroot	/var/named/chroot/etc/	/var/named/chroot/var/named/

Можно использовать конфигурационный файл named.conf, который поставляется по умолчанию. Тем не менее, мы будем использовать другой примерный конфигурационный файл для простоты использования.

Делаем резервную копию файла /etc/named.conf

Cp /etc/named.conf /etc/named.conf.bak

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf

Теперь, когда есть резервная копия конфигурационного файла, а сам оригинальнвй файл изменён, двигаемся дальше.

# vim /etc/named.conf

# vim /var/named/chroot/etc/named.conf

Следующие строки были добавлены/изменены.

Options { ## путь до файлов зон ## directory "/var/named"; ## пенераправляем запросы на публичный DNS сервер Google для нелокальных доменов ## forwarders { 8.8.8.8; }; }; ## объявление прямой зоны для example.tst ## zone "example.tst" IN { type master; file "example-fz"; ## файл для прямой зоны размещён в /var/named ## allow-update { none; }; }; ## объявление обратной зоны для сети 172.16.1.0 ## zone "1.16.172.in-addr.arpa" IN { type master; file "rz-172-16-1"; ## файл для обратной зоны размещён в /var/named ## allow-update { none; }; };

Подготовка файлов зон

Дефолтные файлы зон автоматически созданы в /var/named или /var/named/chroot/var/named (для chroot).

Подразумевая, что дефолтные файлы зон не представлены, мы можем скопировать файлы образцов из /usr.

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named

Отлично. Теперь дефолтные файлы зоны готовы, мы создаём наши собственные файлы зоны для example.tst и сети 172.16.1.0. Пока мы создаём файлы зоны, нужно помнить следующее.

Символ ‘@’ означает NULL в файлах зоны.
Каждая запись полного доменного имени (FQDN) заканчивается точкой ‘.’ например. mail.example.tst. Без точки, будут проблемы.

1. Прямая зона

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

# vim /var/named/example-fz

# vim /var/named/chroot/var/named/example-fz $TTL 1D @ IN SOA ns1.example.tst. mial.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. IN A 172.16.1.3 mail IN A 172.16.1.1 IN MX 10 mail.example.tst. www IN A 172.16.1.2 ns1 IN A 172.16.1.3 ftp IN CNAME www.example.tst.

Объяснение : Внутри файла зоны, SOA означает начало авторизации. Это полное доменное имя авторитетного сервера имен. После полного доменного имени, идёт контактный email адрес. Поскольку мы не можем использовать ‘@’ в [email protected], мы перезаписываем email адрес как mial.example.tst.

NS : Имя сервера
A : A запись или запись адреса — это IP адрес
MX : Mail Exchanger запись. Здесь мы используем только один MX с приоритетом 10. В случае множества MX, мы можем использовать различные цифровые приоритеты. Нижний номер выигрывает. Например, MX 0 лучше чем MX 1.
CNAME : имя в каноническом виде. Если на сервере размещено множество служб, весьма вероятно, что множество имён будут преобразовываться к одному серверу. CNAME сигнализирует, что другие имена сервер может иметь и отсылает к имени, которое содержится в A записи.

2. Обратная зона

Обратная зона содержит карту преобразований из IP адресов в имена. Здесь мы создаём обратную зону для сети 172.16.1.0. В реальном домене, DNS сервер владельца публичного IP блока содержится в файле обратной зоны.

# vim /var/named/rz-172-16-1

# vim /var/named/chroot/var/named/rz-172-16-1 $TTL 1D @ IN SOA ns1.example.tst. sarmed.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. 1 IN PTR mail.example.tst. 2 IN PTR www.example.tst. 3 IN PTR ns1.example.tst.

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

PTR : PTR или запись указателя, она указывает на полное доменное имя

Завершение

Теперь, когда файлы зон готовы, мы настроем разрешение файлов зоны.

# chgrp named /var/named/*

# chgrp named /var/named/chroot/var/named/*

Сейчас мы зададим IP адрес DNS сервера.

# vim /etc/resolv.conf nameserver 172.16.1.3

Наконец, мы можем запустить службу DNS и убедиться, что она добавлена в автозапуск.

# service named restart # chkconfig named on

Тестирование DNS

Мы можем использовать dig или nslookup для тестирования DNS. Вначале, мы установим необходимые пакеты.

# yum install bind-utils

1. Тестирование прямой зоны с использованием dig

# dig example.tst ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31184 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 172.16.1.3 ;; AUTHORITY SECTION: example.com. 86400 IN NS ns1.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 86400 IN A 172.16.1.3

2. Проверка PTR с помощью dig

Когда вы используете для тестирования dig, вам всегда следует искать статус "NOERROR". Любое другое состояние означает, что что-то не так.

# dig -x 172.16.1.1 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415 ;; QUESTION SECTION: ;1.1.17.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.1.16.172.in-addr.arpa. 86400 IN PTR mail.example.tst. ;; AUTHORITY SECTION: 1.16.172.in-addr.arpa. 86400 IN NS ns1.example.tst. ;; ADDITIONAL SECTION: ns1.example.tst. 86400 IN A 172.16.1.3

3. Проверка MX с помощью dig

# dig example.tst mx ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405 ;; QUESTION SECTION: ;example.tst. IN MX ;; ANSWER SECTION: example.tst. 14366 IN MX 10 mail.example.tst.

Подсказки при решении проблем

У меня отключён SELinux.
Убедитесь, что ваш файервол не блокирует UDP порт 53
/var/log/messages должен содержать полезную информацию в случае, если что-то не так
Убедитесь, что владельцев файлов зон является пользователь ‘named’
Убедитесь, что IP адрес DNS сервера стоит на первом месте в /etc/resolv.conf
Если вы используете example.tst в лабораторных условиях, убедитесь, что отсоединили сервер от Интернета, поскольку example.tst — это несуществующий домен.

Подытожим, этот урок фокусируется на хостинге домена example.tst в лабораторных условиях для демонстрационных целей. Пожалуйста, помните, что это не инструкция по созданию публичного DNS сервера, например DNS сервера, который отвечает на запросы от любых IP адресов. Если вы настраиваете рабочий DNS сервер, убедитесь, что проверили, какие политика относятся к публичным DNS. Другой урок освещает создание вторичного DNS, ограничение доступа к DNS серверу, и реализацию DNSSEC.

Гарант является доверенным посредником между Участниками при проведении сделки.

Простыми словами. Версии используемого ПО — CentOS 7, BINВ 9.

Подготовка сервера

Устанавливаем все обновления:

Устанавливаем утилиту для синхронизации времени:

# yum install ntpdate

Настраиваем временную зону:

# \cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в данном примере выбрано московское время.

И синхронизируем время с внешним сервером:

# ntpdate ru.pool.ntp.org

Открываем порт в firewall:

# firewall-cmd --permanent --add-port=53/udp

И перечитываем настройки сетевого экрана:

# firewall-cmd --reload

Установка и запуск BIND

Устанавливаем DNS-сервер следующей командой:

# yum install bind

Разрешаем автозапуск:

# systemctl enable named

Запускаем сервис имен:

# systemctl start named

И проверяем, что он работает корректно:

# systemctl status named

Базовая настройка DNS-сервера

Открываем на редактирование конфигурационный файл bind:

# vi /etc/named.conf

и редактируем следующее:

listen-on port 53 { 127.0.0.1; localhost; 192.168.166.155; };
...
allow-query { any; };

* где 192.168.166.155 — IP-адрес нашего NS-сервера, на котором он будет принимать запросы; allow-query разрешает выполнять запросы всем, но из соображений безопасности можно ограничить доступ для конкретной сети, например, вместо any написать 192.168.166.0/24 .

Для применения настроек выполните команду:

# systemctl restart named

Для проверки работоспособности сервера с другого компьютера сети (например, на Windows) выполняем команду:

> nslookup сайт 192.168.166.155

* данной командой мы пытаемся узнать IP-адреса сайта сайт через сервер 192.168.166.155 .

Должно получиться, примерно, следующее:

Описание глобальных опций

Перечисленные ниже параметры являются глобальными по отношению к DNS и всем настроенным зонам. Они задаются в конфигурационном файле named.conf, директиве options {}.

Опции	Описания
directory	Указывает рабочий каталог сервера bind. Если не указан, /var/named
forwarders	Перечисляет серверы, на которые будет переведен запрос, в случае, если наш сервер не сможет его обработать (нет соответствующей зоны.)
forward	Переопределяет способ обработки запроса. Принимает два значения — ONLY или FIRST. Первое указывает на то, что сервер не будет пытаться искать совпадения среди локальных зон. Второе — сервер сначала будет перенаправлять запрос и если он не будет успешно обработан, искать соответствия во внутренней базе.
listen-on	На каких интерфейсах будет слушать bind
allow-transfer	Указание на список серверов на которые будут разрешены зонные передачи (репликация на вторичные NS)
allow-query	Список узлов, с которых разрешено обращаться к серверу. Если не задана, разрешено всем.
allow-notify	Перечисленным серверам разрешает отправку уведомлений об изменениях в настройках зоны.
allow-recursion	Задает список хостов, для которых разрешены рекурсивные запросы, остальным — будут разрешены итеративные. Если не задана, для всех рекурсивно.

Пример глобальных настроек

options {
directory "/var/named";
forwarders { 192.168.0.10; 77.88.8.8; 8.8.8.8; };
listen-on { 127.0.0.1; localhost; 192.168.166.155; };
allow-transfer { 192.168.1.15; 192.168.0.0/24; };
allow-query { 192.168.1.0/24; 192.168.0.2; 192.168.0.3; };
allow-notify { 192.168.0.15; };
allow-recursion { any; };
}

Зоны bind

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

Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind .
Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind .
Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
Кэширующая или hint. Не хранит на сетбе никаких записей — только результаты уже обработанных запросов для ускорения ответов на повторные обращения.

Решение проблем с помощью log-файлов

По умолчанию, сервер Bind хранит логи в файле
/var/named/data/named.run .

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

tail /var/named/data/named.run

Степень детализации логов можно настроить в конфигурационном файле:

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

* где file — путь к log-файлу; severity — уровень чувствительности к возникающим событиям. Возможны следующие варианты для severity:

critical — критические ошибки.
error — ошибки и выше (critical).
warning — предупреждения и выше. Предупреждения не говорят о наличии проблем в работе сервиса, однако это такие событтия, которые могут привести с ошибкам, поэтому не стоит их игнорировать.
notice — уведомления и выше.
info — информация.
debug — отладка (подробный лог).
dynamic — тот же debug.

В данной статье мы рассмотрим простой пример установки BIND на CentOS 6-версии. BIND – одна из популярных реализаций DNS-сервера, с открытым исходным кодом. DNS – сервера выполняют преобразование DNS-имени в IP-адрес и наоборот.
Перед началом установки хотелось бы отметить, что рекомендуется иметь хотя бы два сервера в облаке, чтобы обеспечить лучшую работоспособность в случае отказа работы одного из серверов. В нашем примере мы предполагаем настройку как первичного, так и вторичного сервера DNS.

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

Первое что следует сделать, проверить актуальность системы, и обновить в случае необходимости. Проверить наличие обновлений вы можете посредством команды yum.

# yum update –y

После этого можно приступить в первичной установке BIND на сервер.

Первичная установка BIND на сервер

# yum install bind bind-utils –y

После установки сервера необходимо открыть конфигурационный файл для настройки конфигурации.

# vi -w /etc/named.conf

В конфигурации «options» вместо IP адреса 2.2.2.2 следует прописать адрес вашего второго сервера.

Options { #listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; allow-transfer { localhost; 2.2.2.2; }; recursion no; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; };

Из соображений безопасности мы закомментировали значение директивы «listen-on». Параметр обозначает, что сервер будет принимать обращения со всех доступных интерфейсов. Так же выставляем директиву в «recursion» в «no», так как это может послужить уязвимостью для DDOS-атак на сервер. В директиве «allow-transfer» указываем сервера, которым мы «доверяем», это наш второй сервер. Выставляем для директивы «allow-query» значение «any», это позволит получать надлежащий доступ к размещаемым доменным зонам.

Следующим шагом мы добавим запись для первого домена, в файле конфигурации named.conf

Zone "mydomain.com" IN { type master; file "mydomain.com.zone"; allow-update { none; }; };

После сохранения файла, мы можем приступить к созданию первого файла доменной зоны. Создаем файл, используя доменное имя использованное выше, т.е. mydomain.com.zone:

# vi /var/named/mydomain.com.zone

Файл мы создаем, поэтому нам в нем следует указать кое-какие параметры. Подобно примеру, показанному ниже, вы должны заменить адреса 1.1.1.1 – это адрес вашего первого сервера (NS1), 2.2.2.2 – это адрес вашего второго сервера (NS2), и 3.3.3.3 – адрес, на котором находится веб-сервер. Дополнительные записи доменных имен вы можете добавлять в том же формате.

$TTL 86400 @ IN SOA ns1.mydomain.com. root.mydomain.com. (2013042201 ;Serial 3600 ;Refresh 1800 ;Retry 604800 ;Expire 86400 ;Minimum TTL) ; указываем пару NS серверов IN NS ns1.mydomain.com. IN NS ns2.mydomain.com. ; замените адреса серверов на свои ns1 IN A 1.1.1.1 ns2 IN A 2.2.2.2 ; указываем имя хостов и IP серверов, которые будут отвечать @ IN A 3.3.3.3 www IN A 3.3.3.3

Теперь мы первично запускаем сервер named. Это может занять некоторое время, пока named сгенерирует файл rndc.key, создаваемый только при первом запуске.

# service named restart

# chkconfig named on

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

# dig @1.1.1.1 mydomain.com

Если вы увидите характерную запись, с обозначением полномочий, то ваш сервер имен настроен правильно.

Конфигурация вторичного DNS сервера
После того как первичный сервер был настроен, приступим к настройке вторичного сервера. Как уже мы делали ранее, обновляем систему, до актуальной версии.

# yum update –y

После этого устанавливаем BIND сервер, а так же его компоненты на вторичный сервер, аналогичным образом, как это делали ранее.

# vi /etc/named.conf options { #listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { any; }; recursion no; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /* путь до ISC DLV ключа */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; };

Добавляем запись зоны, аналогично первичному серверу, за исключением того, что в директиве type нужно указать slave, а так же поменять 1.1.1.1 на адрес первичного сервера.

Zone "mydomain.com" IN { type slave; masters { 1.1.1.1; }; file "mydomain.com.zone"; };

После конфигурирования вторичной зоны, следует перезапустить сервер named. Как и говорилось ранее, на этом сервере так же будет создан файл rndc.key, это займет немного времени.

Добавляем файл сервер в автозагрузку:

# chkconfig named on

Проверяем, что всё работает, заменяем 2.2.2.2 на адрес вашего вторичного сервера.

# dig @2.2.2.2 mydomain.com

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

DNS - система доменных имен - распределенная система, которая способна по запросу содержащему имя хоста сообщить его IP адрес. Структура DNS похожа на файловую систему Linux, вся база имеет древовидную структуру, вверху которого расположен корень (. ). Именно от точки начинается вся система доменных имен. За точкой может следовать ru, com, net, info и др. Домены берущие свое начало от корня т.е ru. , com. , net. называются доменами первого уровня , домены вида сайт. называются доменами второго уровня , а вида file.сайт. - домены третьего уровня и так далее. Обратите внимание на точку в конце примеров. Записывающиеся таким примером имена называются абсолютным (FQDN). Если точка не указана, то это имя рассматривается как относительное. Т.е..сайт.

Зачем использовать DNS?

1) Представьте, что вам необходимо обратиться к сетевому ресурсу под именем host (это файл сервер в котором хранятся все файлы сотрудников) имя host имеет IP адрес 192.168.200.20 и если у вас нет службы преобразующей IP адреса в имена, то вы должны набирать именно IP адрес 192.168.200.20, чтобы попасть на файл сервер. Что же легче запомнить имя host или набор цифр 192.168.200.20?

2) Второй вариант относится к выходу в интернет, вам например необходимо попасть на FTP серверв интернете с именем ftp.сайт , а IP адрес допустим 89.111.176.87.

Так вот, если в первом варианте вовсе не нужно устанавливать и настраивать DNS сервер, а можно просто быстро настроить, например службу WINS, то для выхода в интернет он вам просто необходим (не будем же мы постоянно запоминать цифры когда пытаемся обратиться к какому либо ресурсу в интернете). Другой вопрос нужно ли вам его настраивать, если провайдер предоставил вам свои DNS сервера?

DNS сервер может использоваться как: первичный и вторичный, рекурсивный и перенаправитель запросов.

Первичный (master) производит загрузку данных для зоны из файла на машине сервера, а вторичный(slave) получает данные от первичного DNS. DNS сервер может являться первичным для одной зоны и вторичным для другой.

Рекурсивный сервер создается в крупных организациях со скоростным подключением к сети. Он не привязан к серверам провайдера, гибок и безопасен.

Перенаправитель запросов отправляет запрос от клиента на сервер провайдера. Сервер провайдера обрабатывает множество запросов клиентов, имеет большой кэш и скоростное подключение.

Основные записи DNS.

А - соответствие между именем и IP адресом
АААА - соответствие между именем и IPv6 адресом
CNAME - каноническое имя (синоним)
MX - указывает на почтовый сервер для данного домена
NS - DNS сервер для домена
PTR - каноническое имя
SOA - начальная запись, указывающая где хранится информация о сервере.
SRV - серверы для сервисов.

Установка BIND.
Установку BIND будем производить на centOs5.
Имеет сервер под именем ns1..168.200.1

yum install bind

Настройка BIND
Cоздаем и наполняем конфигурационный файл

vi /var/named/chroot/etc/named.conf

options {
directory "/var/named/";
dump-file "/var/run/named_dump.bd";
statistics-file "/var/run/named.stats";
};
zone "сайт" in {
type master;
file "сайт.db";
};
zone "200.168.192.IN-ADDR.ARPA." IN {
type master;
file "192.168.200.db";
};

zone "0.0.127.IN-ADDR.ARPA." IN {
type master;
file "127.0.0.db";
};

zone "." {
type hint;
file "named.ca";
};

Создаем файлы зон для сайт.db, 192.168.0.db, 127.0.0.db, named.ca.

vi /var/named/chroot/var/named/сайт.db # прямая зона для отображения имен в адреса.

$TTL 1H ; 1 hour
сайт IN SOA ns1.сайт. root.сайт (22
3H
1H
1W
1H)

; Серверы имен
NS ns1.сайт

;Для каконических имен
ns1.сайт. IN 1H A 192.168.200.1
host1.сайт. IN 1H A 192.168.200.154
;Псевдонимы
gw1.сайт. IN 1H CNAME host1.сайт.
www.сайт. IN 1H CNAME host1.сайт.

vi /var/named/chroot/var/named/192.168.200.db # обратная зона для отображения адесов в имена.

$TTL 3600 ; 1 hour
200.168.192.in-addr.arpa IN SOA ns1.сайт. root.сайт (21
3H
1H
1W
1H)
; Серверы имен
200.168.192.in-addr.arpa IN NS ns1.сайт

; канонич имена
1.200.168.192.in-addr.arpa PTR ns1.сайт.
154.200.168.192.in-addr.arpa PTR host1.сайт.

vi /var/named/chroot/var/name/127.0.0.db # loopback адрес для направления пакетов себе.

$TTL 3600 ; 1 hour
0.0.127.in-addr.arpa IN SOA ns1.сайт. root.сайт (21
3H
1H
1W
1H)

0.0.127.in-addr.arpa IN NS ns1.сайт
0.0.127.in-addr.arpa. IN PTR localhost.

vi /var/named/chroot/var/named/named.ca #корневые сервера

A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
;
; operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; operated by ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

Запуск и остановка сервера /etc/init.d/named {start stop restart}
Утилиты для тестирования DNS : host, nslookup, dig.
Более подробные настройки DNS читайте man bind, книга DNS и BIND и др.