DNS-сервер преобразует доменные имена в IP-адреса. Без него сеть работает по IP, что неудобно и замедляет работу. Эта инструкция дает готовую последовательность действий для развертывания DNS на Windows Server и Linux (Ubuntu/Debian) с нуля до работающей системы разрешения имен.
Вы настроите прямые и обратные зоны, добавите записи A, CNAME, MX и подключите forwarders для выхода в интернет. Все команды и конфигурации проверены на практике. Если нужна интеграция DNS в смешанной среде Linux и Windows, обратитесь к руководству по DNS в смешанной среде Linux и Windows.
Что будет настроено
- DNS для локальной сети. Сервер будет разрешать имена внутренних узлов, например www.example.com, в адреса сети 192.168.1.0/24 и обслуживать обратные PTR-записи.
- DNS для публичного домена. Будут показаны структура зоны example.com, записи A, CNAME, MX и требования к делегированию. Для публичной зоны нужны доступный из интернета authoritative DNS-сервер и делегирование NS у владельца адресного диапазона или регистратора.
Все примеры используют домен example.com и приватную сеть 192.168.1.0/24. Адреса 192.168.1.5, 192.168.1.10 и 192.168.1.20 подходят для локальной инфраструктуры, но не должны публиковаться как адреса публичного домена без замены на реальные публичные IP.
Совместимость и ограничения. Команды ориентированы на Ubuntu 22.04/24.04, Debian 12 и Windows Server 2022/2025. На Ubuntu/Debian служба BIND9 обычно называется bind9, а в RHEL и производных - named. Перед применением в production проверьте имя службы, сетевые интерфейсы и правила firewall в своей системе.
Подготовка к развертыванию DNS-сервера
DNS работает по клиент-серверной модели. Сервер хранит базу соответствий «имя - IP» и отвечает на запросы клиентов. Перед установкой убедитесь, что выполнены три условия.
Права администратора. Настройка DNS требует root на Linux или членства в группе Administrators на Windows Server. Без этого вы не установите пакеты и не измените конфигурацию.
Статический IP-адрес. Сервер DNS должен иметь фиксированный IP. Если адрес изменится, клиенты потеряют связь с DNS. Настройте статический IP через параметры сетевого интерфейса до начала работы.
Планирование структуры. Составьте таблицу соответствия имен и адресов. Пример для сети 192.168.1.0/24:
- ns1.example.com - 192.168.1.5 (сам DNS-сервер)
- www.example.com - 192.168.1.10 (веб-сервер)
- mail.example.com - 192.168.1.20 (почтовый сервер)
Обратные зоны требуют делегирования от владельца публичного диапазона IP-адресов или провайдера. Если вы используете публичные адреса, провайдер должен делегировать вам зону in-addr.arpa. Для частных сетей (RFC 1918) обратная зона настраивается локально без внешнего делегирования и действует только внутри вашей DNS-инфраструктуры.
Установка и базовая настройка DNS Server в Windows Server
Windows Server использует роль DNS как встроенный компонент. Установка выполняется через Server Manager.
Откройте Server Manager, выберите «Add roles and features». Пройдите мастер до шага «Server Roles», отметьте «DNS Server». Подтвердите добавление компонентов и завершите установку. После этого в меню «Tools» появится консоль DNS Manager.
Сразу после установки сервер работает как кэширующий. Он принимает запросы от клиентов, перенаправляет их в интернет и кэширует ответы. Для обслуживания собственной зоны нужно создать зону и наполнить её записями.
Создание прямой DNS-зоны и настройка записей A, CNAME, MX
Прямая зона отвечает за преобразование имени в IP-адрес. В DNS Manager кликните правой кнопкой по «Forward Lookup Zones» и выберите «New Zone».
Мастер предложит выбрать тип зоны. «Standard Primary» хранит файл зоны на конкретном DNS-сервере и подходит для автономной сети, рабочей группы или лабораторного стенда. «Active Directory-Integrated Zone» хранится в Active Directory и реплицируется между контроллерами домена, поэтому подходит для доменной инфраструктуры.
Для автономного DNS выберите «Primary zone» и оставьте хранение зоны в стандартном файле. Если DNS-сервер является контроллером домена, выберите интеграцию с Active Directory. Безопасные динамические обновления доступны в доменной инфраструктуре AD; для них используйте режим secure only. В рабочей группе динамические обновления лучше отключить.
Имя зоны - ваш домен, например example.com. Файл зоны оставьте по умолчанию.
Теперь добавьте записи. Правая кнопка по зоне example.com → «New Host (A or AAAA)»:
- Имя:
www, IP:192.168.1.10- запись A для веб-сервера - Имя:
mail, IP:192.168.1.20- запись A для почтового сервера - Имя: оставьте пустым, IP:
192.168.1.5- запись A для самого домена example.com
Запись CNAME создает псевдоним. Правая кнопка по зоне → «New Alias (CNAME)». Укажите alias ftp и целевое имя www.example.com. Теперь ftp.example.com указывает туда же, куда и www.
Запись MX направляет почту. Правая кнопка по зоне → «New Mail Exchanger (MX)». Оставьте поле «Host or child domain» пустым, укажите FQDN почтового сервера mail.example.com и приоритет 10. Приоритет определяет порядок доставки: чем ниже число, тем выше приоритет.
Создание обратной зоны и PTR-записей
Обратная зона преобразует IP-адрес в имя. Она полезна для журналирования, диагностики и работы некоторых сервисов, включая почтовые системы.
В DNS Manager правая кнопка по «Reverse Lookup Zones» → «New Zone». Тип - «Primary zone». На шаге «Reverse Lookup Zone Name» выберите «IPv4 Reverse Lookup Zone» и укажите сетевой ID: 192.168.1. Файл зоны создастся автоматически.
Самый простой способ создать PTR-запись - флажок «Create associated pointer (PTR) record» при добавлении A-записи. Если A-запись уже существует, откройте её свойства и установите флажок вручную. Для ручного добавления: правая кнопка по обратной зоне → «New Pointer (PTR)», укажите IP и соответствующее имя хоста.
Настройка forwarders для внешних запросов
Forwarders перенаправляют запросы к внешним DNS-серверам, если локальный сервер не может разрешить имя самостоятельно. Это снижает нагрузку на корневые серверы и ускоряет разрешение за счет кэша провайдера.
В DNS Manager кликните правой кнопкой по имени сервера → «Properties» → вкладка «Forwarders». Нажмите «Edit», добавьте адреса:
8.8.8.8- Google Public DNS1.1.1.1- Cloudflare DNS
Подтвердите изменения. Сервер будет пытаться разрешить внешние имена через эти адреса. Если оба недоступны, используется стандартная рекурсия через корневые серверы.
Разрешите входящие DNS-запросы в Windows firewall только для нужных сетевых профилей. Для проверки правил можно использовать PowerShell от имени администратора:
New-NetFirewallRule -DisplayName "DNS TCP 53" -Direction Inbound -Protocol TCP -LocalPort 53 -Action Allow New-NetFirewallRule -DisplayName "DNS UDP 53" -Direction Inbound -Protocol UDP -LocalPort 53 -Action Allow
Результат сценария Windows Server: роль DNS Server установлена, прямая и обратная зоны созданы, а записи A, CNAME, MX и PTR доступны клиентам. Критерий успеха - ответы nslookup с другой машины и отсутствие ошибок в Event Viewer → Applications and Services Logs → DNS Server.
Установка и настройка BIND9 на Linux (Ubuntu/Debian)
BIND9 - стандартный DNS-сервер для Linux. Для установки самого сервера и утилит проверки выполните:
sudo apt update && sudo apt install bind9 bind9-utils dnsutils
После установки запустите службу и добавьте её в автозагрузку:
sudo systemctl enable --now bind9
Важно. На Ubuntu/Debian имя службы - bind9. В RHEL и производных обычно используется имя named, поэтому команда будет sudo systemctl enable --now named. То же различие нужно учитывать при перезапуске и просмотре логов.
Конфигурация BIND9 распределена по нескольким файлам. Основные:
/etc/bind/named.conf- главный конфигурационный файл, подключает остальные/etc/bind/named.conf.local- описание локальных зон/etc/bind/named.conf.options- глобальные параметры, включая forwarders/etc/bind/db.*- файлы зон с записями
Для более глубокого погружения в настройку DNS на Linux, включая альтернативные решения dnsmasq и systemd-resolved, используйте руководство по установке BIND9, dnsmasq и systemd-resolved на Linux.
Важно. Перед конфигурацией зон запомните правило SOA Serial: после каждого изменения файла зоны увеличивайте Serial. Перед перезапуском службы обязательно выполните named-checkconf и named-checkzone. Это позволяет обнаружить синтаксические ошибки до остановки работающего DNS.
Конфигурация прямой зоны в BIND9
Откройте /etc/bind/named.conf.local и добавьте описание зоны:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};Параметр type master указывает, что этот сервер - основной для зоны. file задает путь к файлу с записями.
Создайте файл зоны на основе шаблона:
sudo cp /etc/bind/db.local /etc/bind/db.example.com
Отредактируйте /etc/bind/db.example.com:
$TTL 604800
@ IN SOA ns1.example.com. admin.example.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.example.com.
@ IN A 192.168.1.5
ns1 IN A 192.168.1.5
www IN A 192.168.1.10
mail IN A 192.168.1.20
ftp IN CNAME www.example.com.
@ IN MX 10 mail.example.com.Важные правила синтаксиса:
- FQDN в файле зоны всегда заканчиваются точкой:
ns1.example.com. - Имена без точки на конце дополняются именем зоны:
wwwстановитсяwww.example.com. - Символ
@заменяется именем зоны из конфигурации - Serial нужно увеличивать при каждом изменении зоны - стандартный формат ГГГГММДДNN
Запись MX имеет приоритет 10. Можно добавить резервный почтовый сервер с приоритетом 20.
Проверьте прямую зону до перезапуска службы:
sudo named-checkzone example.com /etc/bind/db.example.com
Конфигурация обратной зоны в BIND9
Добавьте в /etc/bind/named.conf.local блок обратной зоны:
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1";
};Имя обратной зоны формируется из адреса сети в обратном порядке с суффиксом .in-addr.arpa. Создайте файл зоны:
$TTL 604800
@ IN SOA ns1.example.com. admin.example.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.example.com.
5 IN PTR ns1.example.com.
10 IN PTR www.example.com.
20 IN PTR mail.example.com.PTR-записи содержат только последний октет IP-адреса. Остальная часть берется из имени зоны. Для публичных IP делегирование обратной зоны выполняет владелец адресного диапазона или провайдер. Для частных адресов PTR действует только внутри локальной DNS-инфраструктуры. Проверьте синтаксис перед применением:
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192.168.1
Настройка forwarders в BIND9
Откройте /etc/bind/named.conf.options и добавьте секцию forwarders внутри блока options. Для локальной сети используйте ACL:
acl "trusted" {
127.0.0.1;
192.168.1.0/24;
};
options {
directory "/var/cache/bind";
forwarders {
8.8.8.8;
1.1.1.1;
};
forward only;
dnssec-validation auto;
listen-on { 127.0.0.1; 192.168.1.5; };
allow-query { trusted; };
allow-recursion { trusted; };
};ACL trusted разрешает запросы только localhost и сети 192.168.1.0/24. Если к DNS подключаются другие подсети или VPN, добавьте их CIDR в ACL явно. Не оставляйте allow-query { any; }; вместе с рекурсией без отдельной защиты: такой сервер может стать открытым recursive DNS-сервером и использоваться для злоупотреблений и DDoS-атак.
Директива listen-on { any; }; допустима только при контролируемом firewall и изолированной сети. В рабочей конфигурации безопаснее привязать BIND9 к конкретному адресу сервера, как в примере. Для публичной authoritative зоны рекурсию не следует открывать в интернет; обычно используют recursion no; и отдельно проектируют доступ к авторитетным ответам.
Директива forward only заставляет сервер использовать только forwarders. Если они недоступны, запросы не уходят на корневые серверы. Для отказоустойчивости можно заменить на forward first - тогда при недоступности forwarders BIND9 выполнит рекурсивный запрос самостоятельно.
После всех изменений сначала проверьте конфигурацию и обе зоны:
sudo named-checkconf sudo named-checkzone example.com /etc/bind/db.example.com sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192.168.1
Если команды завершились без ошибок, перезапустите BIND9 и проверьте статус:
sudo systemctl restart bind9 sudo systemctl is-active bind9
Для RHEL и производных используйте имя службы named: sudo systemctl restart named.
Результат сценария BIND9. Статус службы должен быть active, а named-checkconf и named-checkzone должны завершаться без ошибок. Критерий успеха - успешные ответы A, PTR и MX с клиента и отсутствие ошибок запуска в журнале службы.
Проверка и диагностика работы DNS-сервера на Windows и Linux
Проверка выполняется утилитами nslookup, dig и ping. На Windows используйте nslookup из командной строки, на Linux - dig. Команды ниже явно указывают адрес DNS-сервера, поэтому не зависят от настроек локального resolver.
Проверка прямой зоны:
nslookup www.example.com 192.168.1.5 dig @192.168.1.5 www.example.com
Ожидаемый ответ: IP-адрес 192.168.1.10.
Проверка обратной зоны:
nslookup 192.168.1.10 192.168.1.5 dig @192.168.1.5 -x 192.168.1.10
Ожидаемый ответ: имя www.example.com.
Проверка MX-записи:
nslookup -type=MX example.com 192.168.1.5 dig @192.168.1.5 example.com MX
Ожидаемый ответ: mail.example.com с приоритетом 10.
Проверка синтаксиса BIND9:
sudo named-checkconf sudo named-checkzone example.com /etc/bind/db.example.com
При успешной проверке команды выводят OK и информацию о зоне.
Просмотр логов:
- Windows: Event Viewer → Applications and Services Logs → DNS Server
- Ubuntu/Debian:
sudo journalctl -u bind9 -f - RHEL и производные:
sudo journalctl -u named -f
Настройка DNS-клиента и проверка с другой машины
Проверяйте DNS не только на самом сервере. Локальный запрос может использовать кэш или локальный resolver и скрыть ошибку сетевого доступа.
Windows. Откройте свойства сетевого адаптера, выберите IPv4 и укажите в поле DNS-сервера адрес 192.168.1.5. После изменения очистите кэш:
ipconfig /flushdns
Затем с клиентского компьютера выполните:
nslookup www.example.com 192.168.1.5 nslookup 192.168.1.10 192.168.1.5
Linux. Укажите адрес 192.168.1.5 в настройках NetworkManager, systemd-networkd или другого менеджера сети. Для временной проверки с systemd-resolved можно выполнить команду, заменив eth0 на имя своего интерфейса:
sudo resolvectl dns eth0 192.168.1.5
Независимая проверка через указанный DNS-сервер выполняется так:
dig @192.168.1.5 www.example.com dig @192.168.1.5 -x 192.168.1.10
Не делайте вывод о работе сервера только по команде nslookup www.example.com без адреса DNS: в этом случае запрос может уйти на DNS-сервер, полученный через DHCP, VPN или локальный resolver.
Результат проверки с клиента: с другой машины возвращаются ожидаемые A и PTR-записи, MX содержит mail.example.com, а в логах сервера нет ошибок timeout, REFUSED или SERVFAIL.
Типичные ошибки и их решение
Опечатки в именах зон и записях. Симптом: запросы возвращают NXDOMAIN или SERVFAIL. Проверьте написание имен в конфигурации и файлах зон. В BIND9 запустите named-checkzone.
Забытая точка в конце FQDN. Симптом: BIND9 добавляет имя зоны повторно, создавая записи вида www.example.com.example.com. Решение: всегда завершайте FQDN точкой в файлах зон.
Неверные права доступа к файлам зон. Симптом: BIND9 не может прочитать файл зоны, в логах ошибка permission denied. Решение: владелец файлов - root:bind, права 644.
sudo chown root:bind /etc/bind/db.example.com sudo chmod 644 /etc/bind/db.example.com
Брандмауэр блокирует порт 53. Симптом: сервер не отвечает на запросы с других машин, но локально работает. Откройте порт 53 TCP и UDP:
sudo ufw allow 53/tcp sudo ufw allow 53/udp
Неверный Serial в SOA-записи. Симптом: вторичные серверы не получают обновления зоны. Решение: увеличивайте serial при каждом изменении. Формат ГГГГММДДNN удобен для отслеживания даты правки.
BIND9 не запускается после изменения конфигурации. Сначала выполните sudo named-checkconf и проверку каждой зоны через named-checkzone. Затем проверьте журнал командой sudo journalctl -u bind9 -b. На RHEL и производных замените bind9 на named. Частые причины - ошибка в скобках или точке, неверный путь к файлу зоны, права доступа или занятый порт 53.
Итоговый чек-лист перед запуском
- На DNS-сервере настроен статический IP.
- В firewall разрешены TCP 53 и UDP 53 только из необходимых сетей.
- Созданы и проверены прямая и обратная DNS-зоны.
- В зонах корректно указаны NS и SOA, а Serial увеличивается после изменений.
- Настроены forwarders и ограничен доступ к рекурсивным запросам.
- Проверены права доступа к файлам зон и каталогу конфигурации.
- Выполнен тест A, PTR и MX с другой машины, а не только локально.
- Сделана резервная копия файлов зон и конфигурации BIND9 или Windows DNS.
Заключение: ваш DNS-сервер готов к работе
Вы установили DNS-сервер на Windows Server или Linux, создали прямую и обратную зоны, добавили записи A, CNAME, MX и настроили forwarders. Сервер разрешает имена локальной сети и перенаправляет внешние запросы.
Для продолжения настройки изучите защиту DNS через DoT, DoH и DNSSEC. Если нужно анализировать работу сервера, воспользуйтесь руководством по мониторингу и анализу кэша DNS.
Резервное копирование конфигураций - обязательная практика. Сохраните файлы зон и named.conf.local в систему контроля версий или отдельную директорию. При сбое это позволит восстановить работу DNS за минуты, а не часы.