Настройка DNS-сервера: пошаговая инструкция

Настройка DNS-сервера нужна для внутренних имен и обнаружения служб. Разберем BIND на Linux и DNS Windows. Учебные имена и адреса замените своей схемой.

Что такое DNS и зачем в компании свой сервер

DNS сопоставляет имена и адреса. Учебная зона corp.example.com должна быть заменена поддоменом компании. .local предназначен для mDNS. При смене записи старый адрес сохраняется в кеше до TTL.

У внутреннего DNS в компании три практических применения.

1. Внутренние имена: server-1c.corp.example.com и mail.corp.example.com позволяют обращаться к сервисам по имени.
2. Кеш внешних запросов снижает число повторных обращений. Эффект зависит от TTL и разнообразия имен.
3. Active Directory использует SRV для LDAP и Kerberos. Их недоступность нарушает обнаружение служб и операции домена, а не обязательно загрузку DC.

Централизованная запись уменьшает правки hosts. Но кеш клиентов живет до TTL: проверьте используемый DNS.

Настройка Bind9 на Linux

Установка и базовая конфигурация

Учебный стенд Debian/Ubuntu: primary 10.0.1.1, secondary 10.0.1.2, LAN 10.0.1.0/24. Проверьте поддерживаемую версию BIND в репозитории. Команды требуют административных прав.

sudo apt update && sudo apt install bind9 bind9utils dnsutils

Сохраните конфигурацию. options задает параметры, named.conf.local зоны. Измените существующий options в named.conf.options, не создавайте второй блок.

Измените options, форвардеры замените разрешенными адресами:

options {

directory "/var/cache/bind";

listen-on { 127.0.0.1; 10.0.1.1; };

listen-on-v6 { none; };

allow-query { localhost; 10.0.1.0/24; };

allow-recursion { localhost; 10.0.1.0/24; };

allow-query-cache { localhost; 10.0.1.0/24; };

allow-transfer { none; };

forwarders { 8.8.8.8; 1.1.1.1; };

dnssec-validation auto;

};

ACL закрывают рекурсию от интернета. Разрешите клиентам UDP/TCP 53 и между DNS TCP 53. Проверьте путь до форвардеров или авторитетных серверов при прямой рекурсии.

Проверьте sudo named-checkconf, затем sudo systemctl restart bind9. Журнал: journalctl -u bind9. Имя службы зависит от пакета.

Создание прямой и обратной зон

Создайте каталог sudo install -d -o bind -g bind -m 0750 /var/lib/bind/zones. Добавьте в named.conf.local два блока:

zone "corp.example.com" {

type primary;

file "/var/lib/bind/zones/db.corp.example.com";

allow-transfer { 10.0.1.2; };

};

zone "1.0.10.in-addr.arpa" {

type primary;

file "/var/lib/bind/zones/db.10.0.1";

allow-transfer { 10.0.1.2; };

};

Обратная зона /24: 1.0.10.in-addr.arpa. Файл db.corp.example.com:

$TTL 300

@ IN SOA ns1.corp.example.com. hostmaster.corp.example.com. (

1 3600 600 86400 300 )

@ IN NS ns1.corp.example.com.

@ IN NS ns2.corp.example.com.

ns1 IN A 10.0.1.1

ns2 IN A 10.0.1.2

server-1c IN A 10.0.1.15

Файл db.10.0.1:

$TTL 300

@ IN SOA ns1.corp.example.com. hostmaster.corp.example.com. (

1 3600 600 86400 300 )

@ IN NS ns1.corp.example.com.

@ IN NS ns2.corp.example.com.

1 IN PTR ns1.corp.example.com.

2 IN PTR ns2.corp.example.com.

15 IN PTR server-1c.corp.example.com.

Serial 1 увеличивают при изменениях. Далее указаны refresh, retry, expire и отрицательный TTL в секундах. Точка завершает FQDN.

Проверка:

sudo named-checkzone corp.example.com /var/lib/bind/zones/db.corp.example.com

sudo named-checkzone 1.0.10.in-addr.arpa /var/lib/bind/zones/db.10.0.1

sudo named-checkconf

sudo rndc reload

bind должен читать файлы, а для inline-подписи писать в них и каталог, с учетом AppArmor.

sudo chown bind:bind /var/lib/bind/zones/db.*

dig @10.0.1.1 server-1c.corp.example.com A должен дать 10.0.1.15, dig @10.0.1.1 -x 10.0.1.15 имя сервера. Затем повторите на втором DNS.

Проверьте клиентов, внешние запросы и резерв.

Настройка DNS на Windows Server

Установите DNS из повышенной PowerShell. Выберите сценарий: контроллер AD или автономный сервер.

Install-WindowsFeature -Name DNS -IncludeManagementTools

Ролью управляют DNS Manager или модулем DnsServer.

Только на контроллере AD создайте интегрированные зоны:

Add-DnsServerPrimaryZone -Name "corp.example.com" -ReplicationScope "Domain" -DynamicUpdate "Secure"

Add-DnsServerPrimaryZone -NetworkId "10.0.1.0/24" -ReplicationScope "Domain" -DynamicUpdate "Secure"

На автономном сервере вместо команд AD создайте файловые зоны:

Add-DnsServerPrimaryZone -Name "corp.example.com" -ZoneFile "corp.example.com.dns" -DynamicUpdate "None"

Add-DnsServerPrimaryZone -NetworkId "10.0.1.0/24" -ZoneFile "1.0.10.in-addr.arpa.dns" -DynamicUpdate "None"

В обоих сценариях добавьте A/PTR:

Add-DnsServerResourceRecordA -Name "server-1c" -ZoneName "corp.example.com" -IPv4Address "10.0.1.15" -CreatePtr

Через DHCP/адаптер задайте DNS 10.0.1.1 и 10.0.1.2, суффикс corp.example.com. Клиентам AD не задают публичный резерв. Проверьте ipconfig /all или resolvectl status и разрешение без явного сервера.

Сети передачи данных и DNS планируют совместно. Проверьте оба узла из клиентских подсетей.

nslookup server-1c.corp.example.com проверяет клиентский DNS. Затем запросите оба узла явно. Журналы: Microsoft/Windows/DNS-Server.

Безопасность DNS и DNSSEC

Что защитить и как включить DNSSEC

Защита DNS включает четыре меры:

• Закройте рекурсию от недоверенных клиентов;
• Разрешите UDP/TCP 53 только нужным сетям и узлам;
• Обновляйте поддерживаемую ветку, отслеживая security advisory;
• Ограничьте allow-transfer резервным DNS, предпочтительно с TSIG.

dnssec-validation auto валидирует чужие ответы, не подписывая свои. Для BIND с KASP добавьте в primary прямой зоны dnssec-policy default; и inline-signing yes;. bind нужен доступ записи в файлы и каталог. Автоматическая подпись требует отдельного доверия валидатора.

Проверьте и примените:

sudo named-checkconf

sudo rndc reconfig

dig @10.0.1.1 corp.example.com DNSKEY +dnssec

dig @10.0.1.1 server-1c.corp.example.com A +dnssec

Для внутренней зоны безопасно перенесите проверенный публичный KSK/CSK в trust-anchors рекурсора: flags, protocol, algorithm, public key из DNSKEY. Закрытый ключ не передают. Для публичной делегации нужен DS у родителя. Затем проверьте delv и AD через валидирующий рекурсор. RRSIG без доверия не доказывает цепочку.

В Windows используйте DNSSEC → Sign the Zone, затем DS у родителя или trust anchor доверенного валидатора. Генерация ключа сама по себе не подписывает зону и не создает доверие.

DNSSEC защищает подлинность, резерв доступность. На втором BIND задайте его listen-on и клиентские ACL. Каталог /var/cache/bind должен быть записываемым. Две secondary-зоны:

zone "corp.example.com" {

type secondary;

primaries { 10.0.1.1; };

file "/var/cache/bind/db.corp.example.com";

};

zone "1.0.10.in-addr.arpa" {

type secondary;

primaries { 10.0.1.1; };

file "/var/cache/bind/db.10.0.1";

};

Сверьте TCP 53, журнал и SOA serial обоих узлов. Для защиты передачи используйте TSIG с одинаковым ключом в allow-transfer и primaries. Primary/secondary отвечают одновременно. Клиенты должны знать оба DNS. Время переключения измеряют тестом.

Типичные ошибки настройки

Проверьте клиентские DNS, мониторинг ошибок, ответы каждой view. Политика обхода через внешний DNS должна учитывать DoT/DoH. Доверенный рекурсор может валидировать DNSSEC за stub-клиентов.

1. Проверьте listen-on и сокеты. Явный loopback блокирует LAN, отсутствие listen-on не означает localhost-only.
2. Рекурсия открыта для интернета: сервер рискует стать инструментом DNS-amplification атаки.
3. DNS-сервер один, без резервной пары: откажет, и резолвинг встает во всей сети.
4. Перед переездом заранее снизьте TTL. Старый кеш живет до прежнего TTL. Затем проверьте оба DNS и клиент.
5. Нет нужного PTR: приложение может отказать по политике. Отсутствие записи не равнозначно сетевому таймауту.
6. После переезда сервисов в зоне остаются устаревшие A-записи: они ведут в никуда.

Заключение

Проверьте A/PTR, внешние имена, клиентские DNS и отказ узла. AD и автономный Windows требуют разных зон. Для DNSSEC нужны подпись и доверие.

Грамотный DNS — часть сетевой инфраструктуры: либо выдерживает отказ узла, либо останавливает работу. Serverzilla помогает спроектировать отказоустойчивую сеть, где резервирование DNS заложено в топологию под масштаб компании.