Установка и настройка DNS-сервера BIND в Linux
BIND – наиболее распространенное open-source приложение, в котором реализованы протоколы DNS, предоставляющие возможность преобразования доменных имен в IP-адреса и наоборот.
Данная статья представляет собой руководство по быстрой настройке DNS-сервера в Linux при помощи BIND. Мы не будем подробно разбирать, что такое система DNS и как она работает, а сосредоточимся на примере настройки своей зоны и файла конфигурации для домена/узла с поддержкой сервисов www и электронной почты.
В нашем примере мы будем использовать следующие параметры:
IP-адрес, на котором будет установлен сервер имен: 172.31.0.122
имя домена/узла: itproffi.ru
авторитативные сервера имен для зоны itproffi.ru: ns1.itproffi.ru (172.31.1.10) и ns2. itproffi.ru (172.31.1.11)
службы www и электронной почты для itproffi.ru будут использовать адрес 172.31.1.10
Установка сервера bind
Установка bind очень проста – нужно воспользоваться менеджером пакетов. В Debian и Ubuntu выполните следующую команду:
В CentOS или Fedora:
Пакет dnsutils необязателен для запуска сервера bind, но для тестирования конфигурации мы будем пользоваться командой dig из этого пакета.
Создание файла зоны DNS
Директория /etc/bind/zones/master будет содержать файл зоны для домена itproffi.ru. При желании можно использовать другую директорию. Файл зоны db.itproffi.ru будет содержать запись DNS, которая поможет серверу имен установить соответствие полного доменного имени IP-адресу. Создайте этот файл со следующим содержимым:
Рассмотрим ключевые строки этого файла:
Настройка обратной зоны
На данном этапе DNS-сервер bind может выдать IP-адрес, связанный с узлом itproffi.ru. Теперь нам нужно научить наш сервер имен обратному процессу, то есть устанавливать соответствие имени IP-адресу. Для этого создадим еще один файл db.172.31.1 со следующим содержимым:
Запись PTR: DNS-запись, используемая для определения соответствия IP-адреса имени узла.
Настройка файла конфигурации bind
На данный момент у нас должно быть два файла:
Последний момент перед проверкой конфигурации – внести в файл named.conf.options IP-адрес стабильного DNS-сервера. Он будет использоваться, если локальный DNS-сервер не будет знать ответ на запрос разрешения имени. Часто этот адрес предоставляется интернет-провайдером, но если вы поклонник Google, можно указать адрес 8.8.8.8 или 8.8.4.4.
Замените следующий блок текста в файле named.conf.options:
на блок текста с адресом стабильного DNS-сервера
Если вы планируйте что к вашему серверу будут подключаться другие компьютеры, то нужно разрешить в опциях внешние подключения. Для этого в основном файле конфигурации, в секции options добавьте или замените следующие правила
А лучше, для безопасности вместо any пропишите ваши сети с которых разрешено подключение
Если этого не сделать, то при попытке обращения к серверу с другого компьютера вы получите ошибку
Проверка файлов зоны и конфигурации
Прежде чем попытаться запустить сервер имен с новой зоной и конфигурацией, можно воспользоваться некоторыми инструментами, чтобы проверить, что конфигурация корректна и не содержит ошибок.
Для проверки файлов конфигурации выполните следующую команду:
С этой командой работает простое правило: отсутствие результата – это хороший результат. Если команда ничего не возвращает, значит ошибок в ваших файлах конфигурации не обнаружено.
Для проверки файлов зоны DNS можно воспользоваться командой named-checkzone:
Проверка обратной зоны
Запуск и перезапуск сервера bind
Теперь мы можем запускать сервер bind:
Если сервер уже был запущен, его можно перезапустить командой restart:
Для того что бы перечитать конфигурацию не перезапуская сервер, используйте команду
Тестирование сервера bind
Для тестирования новой конфигурации сервера имен bind нам пригодится команда dig из пакета dnsutils. Эту команду можно запустить на любом компьютере с сетевым доступом к вашему DNS-серверу, но лучше всего начать тестирование с локального узла. В рассматриваемом нами примере IP-адрес сервера имен 172.31.0.122. Сначала проверим прямое разрешение имени (получение IP-адреса по доменному имени):
dig @172.31.0.122 www.itproffi.ru
Теперь проверим обратную зону:
Если вы получили аналогичные результаты, то зона DNS настроена правильно. Вместо команды dig для тестирования можно также использовать команду nslookup.
nslookup 172.31.1.10 172.31.0.122
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
Как создать и настроить вторичную (slave) зону в BIND сервере
* Инструкция написана на примере операционных систем CentOS 7 и Ubuntu. Но она подходит к любому дистрибутиву Linux.
На сервере Master
Чтобы разрешить передачу зоны на вторичный сервер с первичного, необходимо на последнем (master) настроить соответствующее разрешение.
Для этого открываем конфигурационный файл с настройкой зоны.
И добавляем allow-transfer. Получится, примерно, следующее:
zone «dmosk.ru» <
type master;
file «master/dmosk.ru»;
allow-transfer < 192.168.0.15; >;
>;
* где dmosk.ru — домен, для которого настраивается зона; 192.168.0.15 — IP-адрес вторичного сервера, на который будет разрешена зонная передача.
Применяем настройки одной из команд:
systemctl reload named
systemctl reload bind
service bind9 reload
Если используется брандмауэр iptables, создаем разрешающее правило для зонной передачи:
На сервере Slave
Открываем на редактирование конфигурационный файл bind.
И дописываем туда следующее:
zone «dmosk.ru» <
type slave;
file «slaves/dmosk.ru»;
masters < 192.168.0.10; >;
>;
* где dmosk.ru — зона (домен); slave — указание, что эта зона вторичная; slave/dmosk.ru — файл с записями зоны. Стоит обратить внимание, что используется относительный путь до файла — это значит, что каталог slave должен находиться в рабочей папке bind (ее путь определяется опцией directory). Можно также прописать абсолютный путь, например, /etc/bind/slave/dmosk.ru; 192.168.0.10 — IP-адрес первичного сервера, с которого будут вытянуты записи для созданной зоны.
Создаем каталог для хранения вторичных зон.
* используемые в нашем примере каталоги применяются по умолчанию, но в Вашем случае они могут быть другими. Сверяйте данные по опции directory.
Чтобы настройки применились, необходимо перезапустить вторичный bind-сервер одной из команд:
systemctl reload named
systemctl reload bind
service bind9 reload
и перечитать информацию о настроенных DNS-зонах:
Проверяем, что файл с записями появился в базе bind:
* команда выведет список файлов, среди которых должен быть наш (в конкретном примере, dmosk.ru).
Чтобы проверить работоспособность вторичного сервера BIND, запускаем консоль на любом компьютере в сети и вводим команду:
Источник
Делегирование обратной зоны подсети менее /24 в BIND. Как это работает
Встала однажды передо мной задача, отдать одному из клиентов право на редактирование PTR-записей отданной ему подсети /28. Автоматизации для редактирования настроек BIND извне у меня нет. Поэтому я решил пойти другим путем — делегировать клиенту кусок PTR-зоны подсети /24.
Казалось бы — что может быть проще? Просто нужным образом прописываем подсеть и направляем на нужный NS как это делается с поддоменом. Но нет. Не так все просто (хотя на деле вообще примитивно, но интуиция не поможет ), поэтому я и пишу эту статью.
Кто захочет сам разобраться, тот может почитать RFC
Кто хочет готового решения, добро пожаловать под кат.
Чтобы не задерживать тех, кто любит метод копипасты, сначала я размещу практическую часть, а после нее теоретическую.
1. Практика. Делегируем зону /28
Допустим у нас есть подсеть 7.8.9.0/24. Нам надо делегировать подсеть 7.8.9.240/28 на днс-клиента 7.8.7.8 (ns1.client.domain).
На провайдерском днс надо найти файл, описывающий обратную зону этой подсети. Пусть будет 9.8.7.in-addr.arpa.
Записи от 240 до 255 комментируем, если есть. И в конец файла пишем следующее:
не забываем увеличить serial зоны и делаем
На этом провайдерская часть закончена. Переходим к клиентскому днс.
Для начала создадим файл /etc/bind/master/255-240.9.8.7.in-addr.arpa следующего содержания:
И в named.conf дописываем описание нашего нового файла:
B перезапускаем процесс bind.
Все. Теперь можно проверять.
Обратите внимание, что отдается не только PTR-запись и но и CNAME. Так и должно быть. Если интересно почему, то добро пожаловать в следующую главу.
2. Теория. Как это работает.
Сложно настраивать и отлаживать черный ящик. Гораздо проще, если понимаешь что происходит внутри.
Когда мы делегируем поддомен в домене domain, то пишем что-то вроде этого:
Мы говорим всем спрашивающим, что за этот участок не отвечаем и говорим кто отвечает. И все запросы на client.domain редиректятся на 7.8.7.8. При проверке мы видим следующую картину (опустим что там у клиента. это неважно):
Т.е. нам сообщили, что есть такая А запись и ее ip 7.8.9.241. Никакой лишней информации.
А как то же самое можно сделать с подсетью?
Т.к. наш DNS-сервер прописан в RIPE, то при запросе PTR ip-адреса из нашей сети, все равно первый запрос будет к нам. Логика та же что и с доменами. Вот только как вписать подсеть в файл зоны?
Пробуем вписать вот так:
И… чуда не произошло. Мы не получаем никакого перенаправления запроса. Все дело в том, что bind вообще не в курсе что вот эти записи в файле обратной зоны это ip-адреса и уж тем более не понимает запись диапазона. Для него это просто некий символьный поддомен. Т.е. для bind не будет разницы между «255-240» и «oursuperclient«. И запрос чтобы запрос ушел куда надо, адрес в запросе должен выглядеть вот так: 241.255-240.9.8.7.in-addr.arpa. Или вот так, если мы используем символьный поддомен: 241.oursuperclient.9.8.7.in-addr.arpa. Это отличается от обычного: 241.9.8.7.in-addr.arpa.
Руками такой запрос будет сделать проблематично. А если и получится, то все равно непонятно как это применить в реальной жизни. Ведь по запросу 7.8.9.241 нам по прежнему отвечает провайдерский DNS, а не клиентский.
А вот тут в игру вступают CNAME.
На стороне провайдера нужно сделать для всех ip-адресов подсети алиас в формат, который переправит запрос клиентскому DNS.
Это для трудолюбивых =).
А для ленивых больше подойдет конструкция ниже:
Теперь запрос информации по адресу 7.8.9.241 из 241.9.8.7.in-addr.arpa на днс-сервере провайдера будет преобразован в 241.255-240.9.8.7.in-addr.arpa и уйдет на днс-клиента.
Со стороны клиента нужно будет обрабатывать такие запросы. Соответственно мы создаем зону 255-240.9.8.7.in-addr.arpa. В ней мы в принципе можем размещать обратные записи для любых ip всей подсети /24, но спрашивать у нас будут только про те, которые провайдер к нам переадресует, так что побаловаться не получится =).
Для иллюстрации еще раз приведу пример содержания файла обратной зоны со стороны клиента:
Вот из-за того, что мы со стороны провайдера используем CNAME, то и получаем в ответ на запрос данных по ip-адресу две записи, а не одну.
И не забывайте корректно настраивать ACL. Потому что бессмысленно забирать себе PTR-зону и не отвечать никому из внешки =).
Источник