BIND построения DNS-сервера

BIND – это пакет содержащий программное обеспечение для построения DNS-сервера. DNS-сервер позволяет преобразовывать доменные имена к IP-адресам и наоборот. Работа в компьютерных сетях происходит с IP-адресами (уникальный идентификатор) но запомнить все нужные IP-адреса не представляется возможным и здесь на помощь приходит DNS-сервер, который позволяет обращаться к хосту по имени.

 

Установка BIND 

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

 

Ставим нужные пакеты

# yum -y install bind-chroot caching-nameserver

 

Добавляем автозагрузку при старте сервера

# chkconfig named on

 

Инструменты

 

nslookup

Позволяет производить запросы к DNS-серверу и запрашивать любые записи. По умолчанию запрашивается только запись A, чтобы запросить все записи для ya.ru наберите:

# nslookup -type=any ya.ru

 

dig

Схожая по работе с nslookup утилита. Что бы запросить все записи для ya.ru у DNS-сервера ns1.yandex.ru наберите:

# dig ya.ru @ns1.yandex.ru any

 

Базовые понятия

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

Домен – это название зоны в системе доменных имен. Название домена читается слева направо, от младших доменов к старшим.

Поддомен – это имя подчиненной зоны. Например mail.example545.com является поддоменом example545.com. example545.com – это домен второго уровня, mail.example545.com – домен третьего уровня.

Относительное имя домена – к имени этой записи будет добавлен основной домен в которой она находится.

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

resolver – программа-клиент. Она вступает в работу когда пользователь пытается получить информацию от DNS-сервера. Файл конфигурации резолвера — /etc/resolv.conf

DNS-запрос (query) – запрос от клиента к серверу. Существует два типа запросов.

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

Итеративный – в случае получения такого запроса, DNS-сервер  2. просматривает свой кэш и выдает наилучший ответ из имеющихся у него. Это может быть ссылка на другой DNS-сервер. Далее клиент сам продолжает резолвинг нужного доменного имени. Не знаю точно как сейчас, но раньше не все веб-браузеры умели обрабатывать итеративные запросы.

 

Правила построения DNS-системы

 

При построение своей DNS-системы вам будет необходимо придерживаться некоторого набора правил:

• для каждой зоны должны быть не менее двух DNS-серверов, один master-сервер и один slave-сервер;
• DNS-сервера должны быть в разных сетях класса C, что должно гарантировать работоспособность сервиса в случае потери связи одного из сегментов сети в котором находится DNS-сервер.

 

Режимы работы ДНС-серверов

 

Существует несколько режимов в которых может работать DNS-сервер.

Конечно самая распространенная связка – это Master/Slave.

Master DNS-сервер – главный DNS-сервер для зоны, только он имеет право вносить в нее изменения, другие могут получать и хранить у себя, отдавая на запросы клиентов. Здесь ключевое отличие в возможности редактировать файл зоны, изменять список NS-серверов для нее и прочие записи.

Slave DNS-сервер – вторичный DNS-сервер для зоны, их может быть несколько. Основное предназначение вторичного сервера – подстраховывать первичный (Master server) сервер (в случае, если он станет временно недоступен) и снижать нагрузку обрабатывая часть запросов. Он обслуживает запросы наравне с первичным сервером, также являясь авторитативным для зоны и пользователю должно быть все равно с какого DNS-сервера получать информацию. Slave-сервер не может вносить изменения в конфигурацию зоны.

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

# nslookup www.ru

Server: 192.168.146.2

Address: 192.168.146.2#53

Non-authoritative answer:

Name: www.ru

Address: 194.87.0.50

Строка “Non-authoritative answer” говорит о том, что ответ мы получили из кэша неавторитативного сервера.

 

I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17

J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30

J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30

;; Query time: 233 msec

;; SERVER: 198.41.0.4#53(198.41.0.4)

;; WHEN: Wed Apr 8 10:51:26 2009

;; MSG SIZE rcvd: 500

Stealth DNS-сервер (невидимый DNS-сервер) – такой DNS-сервер не упоминается в описание зоны. Информацию о нем нельзя получить прямыми запросами или копированием описания зоны. Данный тип сервера может быть полезен для внесения изменений в зону находясь за файрволом. В этом случае primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны.

Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с “невидимого” primary master.

 

Типы ответов DNS-серверов

 

Авторитативный ответ (authoritative response) — такой ответ возвращают сервера которые являются ответственными за зону.

Неавторитативный ответ (non authoritative response) — возвращают серверы, которые не отвечают за зону. Необходимую информацию они получают из своего кэша или после нерекурсивного запроса к авторитативному DNS-серверу.

 

Виды запросов к DNS-серверу

 

Прямой запрос (forward) – это запрос на преобразование имени хоста в IP-адрес. Думаю это самый распространенный запрос.

Обратный запрос (reverse) – это запрос на преобразование IP-адреса хоста в доменное имя. Почтовые сервера любят проверять наличие этой записи, что в свою очередь помогает бороться со спамом.

Способы копирования зоны с master-сервера Slave-сервер сам по себе не вносит какие либо изменения в файл-зоны, он просто копирует ее с master-сервера по истечению интервала жизни зоны (значение TTL) или когда получает уведомление о том, что были внесены изменения на master-сервере и нужно обновить ее у себя, чтобы оперировать с актуальной копией. Так вот существует два механизма получения обновлений с master-сервера.

AXFR — полное копирование зоны.

IXFR – инкрементальное копирование зоны, когда копируются только измененные данные а не весь файл целиком.

Перед продолжение хочу обратить внимание на некоторые моменты. Как уже говорилось slave-сервер копирует зону с master-сервера, То есть с сервера который является авторитативным для зоны. Но slave-сервер и сам может являться авторитативным и в этом случае он будет выступать master-сервером для того кто с него копирует зону. Для того чтобы точно описать сервер, который является авторитативным для зоны и который больше не получает обновлений для нее, был введен термин primary master. Primary master находится в корне всех процедур копирования и именно на нем происходит ручное изменение зоны. Такой сервер может быть только один для зоны.

За своевременное информирование slave-серверов о необходимости обновить свои данные отвечает механизм DNS NOTIFY. Принцип его работы не сложный.

1. Мы вносим изменения в зону на primary master увеличив значение поля serial на единицу;
2. После перезагрузки конфигурации primary master-сервера, он оповещает все свои slave-сервера об изменениях;
3. Slave-сервер запрашивает описание зоны с primary master-сервера и смотрит версию описания зоны, если версия отличается от его (больше) то он инициирует процесс обновления зоны;
4. После завершения обновления, slave-сервер посылает оповещение на все ему известные авторитативные сервера для этой зоны.
5. оперировать с актуальной копией. Так вот существует два механизма получения обновлений с master-сервера.