: | : |
‹ | › | |||||
Пн | Вт | Ср | Чт | Пт | Сб | Вс |
2018-08-23 11:36:55 8354 0
Установка и настройка DNS-сервера Bind
DNS - компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.
Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
DNS важна для работы Интернета, так как для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла hosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.
Одной из реализаций DNS-сервера является Bind, его мы и будем рассматривать в этой статье.
Установку и настройку будем производить на сервере с операционной системой CentOS7.
Установка необходимых пакетов:
sudo yum install bind bind-utils
После установки переходим в главный конфигурационный файл bind - /etc/named.conf. рассмотрим основные настройки
В начале файла мы можем задать acl (access control list), позволяет сгруппировать сети или хосты, для дальнейшей упрощенной настройки, например задать локальные сети офиса
acl office { 192.168.1.0/24; 10.10.10.0/24; 10.10.20.1; };
Далее идет раздел options, в котором будет осуществляться настройка сервера
# Указание какие ip-адреса прослушивает демон listen-on port 53 { localhost; 192.168.1.100; }; # Указываем рабочюю директорию bindа directory "/var/named"; # по-умолчанию # Указываем кому разверешено делать запросы с серверу, здесь пригодится наш acl # Эту опцию можно указывать при настройки конкретной зоны. allow-query { localhost; office; }; # Указываем кому разрешено делать рекурсивные запросы # Эту опцию можно указывать при настройки конкретной зоны. allow-recursion { localhost; office;}; # Указываем сервера на которые будут перенаправлены запросы для зон, которые не обслуживаются # нашим сервером forwarders { 8.8.8.8; 8.8.4.4; }; # Указываем на какие вторичные сервера можно передавать зоны # Эту опцию можно указывать при настройки конкретной зоны. allow-transfer { none; }; # Запрет на автоматическое обновление зоны # Эту опцию можно указывать при настройки конкретной зоны. allow-update { none; };
Далее идут настройки зон
zone "test.un" { type master; file "test.un"; allow-query { any; }; }; zone "test.local" { type stub; file "slaves/test.local"; masters { 10.25.25.100; }; }; zone "0.100.10.in-addr.arpa" { type master; file "0.1.168.192.in-addr.arpa"; };
Указывается ключевое слово "zone" потом имя зоны
Далее идут параметры зоны
- type - тип зоны
- master - основная зона;
- slave - вторичная зона (хранится полная копия файла зоны с мастера);
- stub - зона заглушка (хранится только адреса DNS серверов ответственных за зону);
- hint - используется как кэш;
- file - место хранения файла;
- masters (используется для типов slave и stub) - указание какие сервера отвечают за эту зону;
Далее переходим непосредственно к файлам самих зон. Они будут хранится как указано в секции file настройках зон относительно директории /var/named/ как описано в настройка сервера "directory".
Рассмотрим настройку зоны test.un, за которую отвечает наш сервер (коментирии помечаются символов - ;)
;Указываем время кэширования положительных ответов (в секундах) ;Возможно использование значений -m -минуты, h-часы, d - дни, w - недели $TTL 86400 ;Далее идет запись SOA, тот кто является ответственным за зону. Имя сервера и ;e-mail администратора (обязательно окончание на "." ). Далее в скобках ;указывают параметры записи @ IN SOA ns1.test.un. admin.test.un. ( 2018061901 ; Serial 3h ; Refresh 1h ; Retry 3d ; Expiry 5h ; TTL-non ) ; Далее идут сами записи зон ; Имя тип адрес @ IN NS ns1.test.un. ns1 IN A 192.168.1.100 web IN A 192.168.1.80 @ IN MX 10 mx.test.un www IN CNAME web mx IN A 192.168.1.20
Параметы записи SOA:
- Serial - серийный номер. Каждый раз при изменении каких-либо данных его нужно обязательно менять, что бы обновлять зону на slave серверах. Обычно используют формать ГГГГММДДнн - год,месяц,день,порядковый номер;
- Refresh - интервал, через который slave сервера должны обращаться к primary серверу и проверять обновление зоны;
- Retry - если slave серверу не удалось обратится к primary серверу, через это время он должен повторить свой запрос;
- Expiry - если в течении этого времени slave сервер так и не смог обновить зону с primary сервера, то slave должен прекратить обслуживать эту зону;
- TTL-non - время кэширования отрицательных ответов.
Типы записей:
- NS - сервера имен, которые обслуживают домен;
- MX - почтовые шлюзы, на них будет перенаправляться вся почта для домена, указываются с приоритетом;
- A - запись хоста (ip-адреса);
- AAAA - запись хоста ipv6;
- CNAME - алиас для записи хоста;
- PTR - обратная запись хоста;
- SRV - запись сервиса.
Рассмотрим создание обратной зоны 0.1.168.192.in-addr.arpa
$TTL 1d @ IN SOA nc1.test.un. admin.test.un. ( 2018061901 3h 1h 3d 5h ) @ IN NS ns1.test.un. 20 IN PTR mx.test.un.
Обратные записи необходимы для почтовых серверов. Так как при пересылке почты проверяется преобразование имени в ip-адрес.
Управление демоном named
После создания конфигурационных файлов и файлов зон, неплохо было бы проверить их на ошибки, перед тем как запускать демона
Проверка конфигурационных файлов:
sudo named-checkconf
Проверка файла зоны (указываем имя зоны и файл зоны):
sudo named-checkzone test.un /var/named/test.un
Проверка всех главных зон найденных в файле named.conf:
sudo named-checkconf -z
Теперь можем запускать демона и наслаждаться работой DNS-сервера
sudo systemctl start named
Управление демоном осуществляется с помощью утилиты rndc
sudo rndc reload
Перезагрузка всех конфигурационных файлов и зон, без перезагрузки демона
sudo rndc reload [zone]
Перезагрузка конкретной зоны
sudo rndc reconfig
Презагрузка конф файлов и загрузка новых зон
sudo rndc flush
Очистка кэша сервера
sudo rndc status
Статус DNS-сервера
sudo rndc restart
Перезапуск демона named
Различных команд очень много, для полного перечня обращайтесь к документации или странице man
Введите ответ:
+
=