Настройка DNS-сервера BIND

Инструкция обновлена 27 октября 2025 г.

Запуск собственного DNS-сервера — это стратегический шаг к полной автономии в управлении сетью. Такой подход позволяет самостоятельно управлять процессом преобразования доменных имен в IP-адреса, освобождаясь от ограничений сторонних провайдеров. Этот навык критически важен не только для корпоративных инфраструктур, но и для системных администраторов, стремящихся повысить производительность сети за счет ускоренного разрешения DNS-запросов, организации изолированных доменных зон и укрепления независимости IT-ландшафта.

В качестве основного инструмента мы рассмотрим BIND (Berkeley Internet Name Domain) — программное обеспечение, которое получило признание за свою стабильность, богатую функциональность и экосистему. Именно эти качества делают его доминирующим решением в большинстве корпоративных и проектных сред. 

Данное руководство детально описывает процесс инсталляции и конфигурирования BIND на операционной системе Ubuntu 22.04 LTS (актуально и для 24.04).

vps

Предварительные требования

Для работы нам понадобятся:

• Два облачных (виртуальных) сервера с предустановленным дистрибутивом Linux Ubuntu 22.04 или 24.04. Первый будет играть роль сервера, на который мы установим BIND. Второй будет выступать в роли клиента.

Для серверов выберите конфигурацию с одноядерным процессором, 2 ГБ оперативной памяти и публичным IPv4-адресом, который можно заказать при создании сервера или в разделе «Сеть». 

Дополнительно для каждого сервера необходимо:

• создать приватную сеть (можно сделать на этапе создания сервера или во вкладке «Сеть» в панели управления);

• настроить приватный IP-адрес по инструкции.

Сервер будет установлен в течение пары минут. Публичный и приватный IPv4-адреса, логин и пароль для подключения по протоколу SSH будут доступны в разделе «Дашборд».

Для чего может потребоваться свой DNS-сервер?

Система доменных имен (DNS) выполняет роль фундаментального навигатора во всемирной паутине, преобразуя удобные для человека адреса (например, google.com) в IP-адреса, подобно тому, как контакты в телефоне связывают имена с номерами. Хотя сегодня пользователям доступно множество популярных публичных DNS-сервисов от таких гигантов, как Google или Яндекс, развертывание собственного DNS-сервера открывает ряд стратегических преимуществ. Собственный DNS-сервер можно использовать для:

• Локальной сети: быстрое разрешение имен компьютеров в домашней или офисной сети.

• Кэширования: сохранение запросов для ускорения загрузки сайтов.

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

• Тестирования: для разработчиков — проверка доменов без влияния на глобальный DNS..

Установка BIND

Команды ниже, необходимо выполнять от имени пользователя root или пользователя с правами sudo.

1) Обновляем индекс репозиториев и устанавливаем необходимые пакеты:

apt update && apt -y install bind9 bind9utils

2) Проверим статус демона bind:

systemctl status bind9

Если в статусе отображается active (running), то сервис успешно запущен.

Настройка BIND

BIND хранит свои конфигурационные файлы в директории /etc/bind/. Основной файл называется /etc/bind/named.conf.options. Он указывает, где искать зоны (области DNS, например, ваш домен), указывает путь до логов и т.д.

Мы будем использовать следующие приватные IP-адреса:

• 192.168.0.4 — адрес сервера DNS
• 192.168.0.5. — адрес клиентского сервера.

Замените адреса выше на свои. IP-адреса должны находиться в одной подсети.

1) Прежде чем приступать к редактированию файла, сделаем его резервную копию:

cp /etc/bind/named.conf.options /etc/bind/named.conf.options.backup

2) Откроем файл на редактирование:

nano /etc/bind/named.conf.options

Приводим конфигурацию к следующему виду:

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

    recursion yes;
    allow-recursion { 192.168.0.0/24; 127.0.0.1; ::1; };
    allow-query { 192.168.0.0/24; 127.0.0.1; ::1; localhost; };

    listen-on port 53 { 127.0.0.1; 192.168.0.4; };
    listen-on-v6 port 53 { ::1; };

    dnssec-validation auto;
    version "not revealed";
    empty-zones-enable yes;

    forwarders {
        8.8.8.8;
        8.8.4.4;
    };
};

Описание параметров:

• directory "/var/cache/bind";
  Задает рабочий каталог сервера, где хранятся временные файлы, кэш DNS-записей и файлы зон.
• recursion yes;
  Разрешает серверу выполнять рекурсивные запросы. Когда клиент запрашивает доменное имя, сервер сам обращается к другим DNS-серверам для поиска ответа, если не имеет информации в кэше.
• allow-recursion { 192.168.0.0/24; 127.0.0.1; ::1; };
  Определяется список IP-адресов и сетей, которым разрешено выполнять рекурсивные запросы. В данном случае разрешено только локальным хостам и подсети с адресом 192.168.0.0/24. Не забудьте поменять на свою подсеть.
• allow-query { 192.168.0.0/24; 127.0.0.1; ::1; localhost; };
  Ограничивает круг клиентов, которые могут отправлять любые DNS-запросы к серверу. Доступ разрешен только доверенным сетям и локальным адресам. Не забудьте поменять на свою подсеть.
• listen-on port 53 { 127.0.0.1; 192.168.0.4; };
  Определяет IPv4-интерфейсы и порт, на котором сервер будет принимать соединения. Сервер слушает локальный интерфейс и конкретный IP-адрес  192.168.0.4 на стандартном порту 53.
• listen-on-v6 port 53 { ::1; };
  Аналогично предыдущему параметру, но только для соединений по протоколу IPv6. Сервер настроен принимать запросы только на локальном IPv6-адресе ::1.
• dnssec-validation auto;
  Включает автоматическую проверку подлинности DNS-данных с использованием технологии DNSSEC. Защищает от поддельных DNS-ответов и спуфинга.
• version "not revealed";
  Скрывает версию BIND в ответа от сервера. Это мера безопасности, затрудняет злоумышленникам поиск уязвимостей в конкретной версии программного обеспечения.
• empty-zones-enable yes;
  Разрешает обслуживание пустых зон, которые возвращают отрицательные ответы для запросов в несуществующих доменах. Уменьшает бесполезный интернет-трафик.
• forwarders { 8.8.8.8; 8.8.4.4; };
  Задает список внешних DNS-серверов, на которые перенаправляются запросы, когда данный сервер не является авторитативным для запрашиваемой зоны. В данном случае используются публичные DNS от компании Google.

Настройка локальной DNS зоны

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

Зоны DNS настраиваются в файле /etc/bind/named.conf.local.

Мы добавим локальную зону с именем local, но также можно использовать другое имя, например, home.lan.

1) Открываем файл на редактирование при помощи текстового редактора nano:

nano /etc/bind/named.conf.local

Используем следующую конфигурацию:

zone "local" {
    type master;
    file "/etc/bind/db.local";
};

zone "0.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192";
};

Описание параметров:

• zone "local"
  Объявляет прямую зону DNS для домена local. Ее задача — преобразовывать имена (например, server.local) в IP-адреса. Сервер ищет ответ на запрос в записях этой зоны.
• type master
  Указывает, что данный сервер BIND является основным (первичным) для зоны. Он хранит главную копию данных и именно на нем вносятся все изменения.
• file "/etc/bind/db.local"
  Определяет путь к файлу с DNS-записями для прямой зоны. Внутри этого файла прописываются все соответствия имен и адресов (записи A, AAAA, CNAME и т.д.).
• zone "0.168.192.in-addr.arpa"
  Создает обратную зону для подсети 192.168.0.0. Имя зоны записывается в обратном порядке, как этого требует стандарт. Эта зона отвечает за преобразование IP-адресов в доменные имена.
• file "/etc/bind/db.192"
  Задает файл с PTR-записями для обратной зоны. Эти записи связывают IP-адреса (вроде 192.168.0.10) с доменными именами, позволяя выполнять обратные DNS-запросы.

Настройка прямой DNS зоны

На следующем этапе нам необходимо создать и настроить прямую DNS-зону, которая содержит все записи о соответствии доменных имен IP-адресам в нашей локальной сети. Настройка прямой зоны осуществляется в файле /etc/bind/db.local.

1) Делаем резервную копию перед редактированием основного файла:

cp /etc/bind/db.local /etc/bind/db.local.backup

2) Открываем файл db.local:

nano /etc/bind/db.local

Приводим файл к следующему виду:

$TTL    604800
@       IN      SOA     ns.local. root.local. (
                              2         ; Serial
                         604800   ; Refresh
                          86400     ; Retry
                        2419200    ; Expire
                         604800 )  ; Minimum

@       IN      NS      ns.local.
ns      IN      A       192.168.0.4
dns     IN      A       192.168.0.4
client  IN      A       192.168.0.5
server  IN      A       192.168.0.4

Описание параметров:

• $TTL 604800
  Устанавливает время жизни DNS-записей. Значение 604800 указано в секундах и равно 7 дням. Это период, в течение которого кэширующие DNS-серверы могут хранить полученные записи перед повторным запросом.
• Запись SOA
  Основная административная запись зоны. Содержит в себе следующие записи:
  • ns.local. — основной DNS-сервер для зоны.
  • root.local. — email администратора (root@local).
  • Serial — версия зоны.
  • Refresh — как часто вторичные серверы проверяют обновления.
  • Retry — интервал повтора при неудачном обновлении.
  • Expire — время, после которого данные считаются устаревшими.
  • Minimum — определяет, как долго DNS-сервер будет хранить информацию о записи в своем кеше, прежде чем запросить ее снова у авторитативного сервера.
• Запись NS
  @ IN NS ns.local. — Указывает, что сервер ns.local является авторитативным для этой зоны.
• Записи A
  Сопоставляют доменные имена с IP-адресами:
  • ns.local → 192.168.0.4 (основной DNS-сервер)
  • dns.local → 192.168.0.4 (альтернативное имя для DNS-сервера)
  • client.local → 192.168.0.5 (клиентский компьютер)
  • server.local → 192.168.0.4 (серверный хост)

Значения 192.168.0.4 (адрес сервера bind) и 192.168.0.5 (адрес клиентского сервера) необходимо поменять на свои IP адреса.

Настройка обратной DNS-зоны

На финальном этапе настроим файл обратной DNS-зоны, которая отвечает за преобразование IP-адресов в доменные имена. В файле /etc/bind/db.127 содержится шаблон обратной DNS-зоны, который уже содержит правильную структуру и все необходимые базовые записи. Копируем его в новый файл, который мы назовем db.192:

cp /etc/bind/db.127 /etc/bind/db.192

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

nano /etc/bind/db.192

Используем следующую конфигурацию:

$TTL    604800
@       IN      SOA     ns.local. root.local. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Minimum

@       IN      NS      ns.local.
4       IN      PTR     ns.local.
5       IN      PTR     client.local.

Описание параметров:

• $TTL 604800
  Данная директива устанавливает стандартное значение Time To Live (время жизни) для всех записей в зоне, указанное в секундах. Период в 604800 секунд, что эквивалентно одной неделе, определяет срок хранения информации о записях на кэширующих резолверах до момента обязательного обращения к авторитативному серверу для верификации данных. Это ключевой механизм для оптимизации нагрузки и повышения отзывчивости DNS-инфраструктуры.
• @ IN SOA ns.local. root.local.
  Запись SOA является заголовочной для любой DNS-зоны и содержит критически важные метаданные:
  • ns.local.: Определяет каноническое имя первичного (мастер) DNS-сервера, управляющего этой зоной.
  • root.local.: Адрес электронной почты администратора зоны (символ @ заменяется на точку).
• Serial 1
  Уникальный идентификатор версии зоны. При внесении любых правок этот номер должен быть вручную увеличен. Вторичные серверы используют его для определения необходимости запроса обновленной копии зоны (процесс AXFR/IXFR).
• Refresh 604800
  Период (в секундах), с которым вторичные (слейв) серверы будут опрашивать первичный на предмет наличия новой версии зоны (сравнивая Serial).
• Retry 86400
  Интервал ожидания (в секундах) перед следующей попыткой соединения, если вторичному серверу не удалось связаться с первичным по истечении времени Refresh.
• Expire 2419200
  Максимальный срок (в секундах), в течение которого вторичный сервер может продолжать отвечать на запросы данными из своей устаревшей копии, если соединение с мастер-сервером не восстановлено. По его истечении данные признаются недействительными.
• Minimum 604800
  Значение TTL по умолчанию для отрицательных ответов (NXDOMAIN), которое указывает кэширующим серверам, как долго сохранять информацию об отсутствии запрашиваемой записи.
• @ IN NS ns.local.
  Запись типа NS (Name Server) декларирует авторитативный сервер имен для данной доменной зоны. Символ @ является сокращением для текущего origin-домена.
• 4 IN PTR ns.local.
  PTR-запись используется для обратного DNS-поиска, устанавливая соответствие IP-адреса доменному имени. В контексте зоны обратного просмотра 0.168.192.in-addr.arpa запись связывает октет 4 (формируя полный адрес 192.168.0.4) с именем ns.local..

Валидация конфигурации и запуск службы

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

Проверка общего синтаксиса главного файла конфигурации:

named-checkconf /etc/bind/named.conf

Валидация файла прямой зоны local:

named-checkzone local /etc/bind/db.local

Валидация файла обратной зоны для сети 192.168.0.0/24:

named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192

Успешное выполнение этих команд должно завершиться без выводов ошибок (или с сообщением "OK" для named-checkzone).

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

systemctl restart bind9

Убедиться в корректности запуска службы можно командой:

systemctl status bind9

Ожидаемый статус — active (running).

Далее мы проверим работоспособность нашего DNS сервера.

Проверка работоспособности BIND

После успешного перезапуска BIND рекомендуется провести серию диагностических запросов.

1) Выполним запрос к локальному серверу для разрешения имени ns.local:

dig @localhost ns.local

Ожидаемый результат: В секции ANSWER будет возвращен IP-адрес 192.168.0.4.

2) Проверим работоспособность обратного DNS-поиска.

Запрос на преобразование IP-адреса 192.168.0.4 в доменное имя:

dig @localhost -x 192.168.0.4

Ожидаемый результат: В ответе будет указано доменное имя ns.local..

3) Проверим разрешения имени для второго хоста.

Используем утилиту nslookup для проверки записи клиентского хоста, зарегистрированного в зоне:

nslookup client.local 127.0.0.1

Ожидаемый результат: Утилита вернет IP-адрес, ассоциированный с именем client.local, подтверждая корректную работу как прямой, так и обратной зон.

Настройка клиентов для работы с DNS-сервером

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

1) Открываем на редактирование файл resolved.conf:

nano /etc/systemd/resolved.conf

Приводим файл к следующему виду:

[Resolve]
DNS=192.168.0.4 8.8.8.8
Domains=local

В конфигурации указаны два сервера доменных имен (DNS):

• Предпочитаемый DNS: 192.168.0.4
• Альтернативный DNS: 8.8.8.8

Сервер с адресом 192.168.168.0.4 является локальным, на котором функционирует служба BIND. Он обрабатывает все DNS-запросы в первую очередь, что позволяет эффективно разрешать внутренние имена и кэшировать внешние запросы для ускорения доступа.

Публичный DNS-сервер Google 8.8.8.8 выступает в роли резервного (fallback). Его использование активируется в двух основных сценариях: если основной сервер 192.168.0.4 не отвечает, или когда он не может найти запись (например, для доменов в глобальной сети Интернет). Это обеспечивает отказоустойчивость и гарантирует, что доступ к внешним ресурсам будет сохранен даже при проблемах с локальной инфраструктурой.

Директива search указывает систему доменных суффиксов для автоматического дополнения имен хостов. Когда вы вводите короткое имя (например, client), система автоматически попробует разрешить его как client.local. Это упрощает работу в локальной сети — вместо полного имени client.local можно использовать просто client.

Сохраняем изменения и выходим из файла.

2) Проверим, что символьная ссылка /etc/resolv.conf указывает на ../run/systemd/resolve/stub-resolv.conf:

ls -la /etc/resolv.conf

3) Перезапускаем службу systemd-resolved:

systemctl restart systemd-resolved

И проверяем статус:

resolvectl status

В выводе должны отображаться ранее добавленные DNS-серверы.

4) Выполним команду ping на доменное имя нашего DNS-сервера:

ping ns.local

Пинг успешно проходит. На этом полная настройка собственного DNS-сервера успешно завершена.

Заключение

В рамках данной статьи была реализована задача по развертыванию и конфигурированию полнофункционального DNS-сервера, использующего программное обеспечение BIND, в среде операционной системы Ubuntu. Описанный процесс охватывает полный цикл работ: от инсталляции требуемых пакетов до детальной настройки основных конфигурационных файлов, с последующей процедурой верификации корректности функционирования развернутого сервера.

В результате у нас есть собственный DNS-сервер, который:

• Повышает эффективность: Локальное разрешение имен происходит мгновенно, что ускоряет взаимодействие между серверами и устройствами в вашей сети.
• Предоставляет полный контроль: Вы можете самостоятельно создавать, изменять и управлять доменными именами и записями, адаптируя сеть под свои конкретные задачи.
• Служит основой для расширения: Настроенный сервер можно развивать — добавлять новые зоны, реализовывать политики безопасности, настраивать репликацию для отказоустойчивости или интегрировать с другими сетевыми службами.