Как установить и настроить Bind в качестве DNS-сервера частной сети

Введение

Связать (Berkeley Internet Name Domain) — программное обеспечение с открытым исходным кодом, реализующее протоколы системы доменных имен (DNS) для Интернета. Это наиболее широко используемое программное обеспечение DNS в Интернете.

Настройка Bind в качестве DNS-сервера частной сети обеспечивает ряд преимуществ:

  • Позволяет преобразовывать имена хостов в IP-адреса для машин в частной сети, не прибегая к помощи внешнего DNS-сервера
  • Обеспечивает больший контроль и настройку частного пространства имен DNS
  • Повышает безопасность и конфиденциальность благодаря отсутствию DNS-запросов к внешним серверам
  • Повышение надежности за счет снижения зависимости от внешних DNS-серверов

В этом руководстве мы рассмотрим шаги, необходимые для установки, конфигурирования и настройки Bind в качестве кэширующего и авторитетного DNS-сервера в частной сети.

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

Прежде чем приступить к настройке Bind, необходимо убедиться, что у нас есть все необходимое:

  • Сервер Linux со свежей установкой дистрибутива Linux, например Ubuntu 20.04/22.04, Debian 11/12, CentOS 7/8 и т.д.
  • Linux-машина должна иметь статический IP-адрес и сетевое подключение в частной сети.
  • Доменное имя, которое вы хотите использовать для частной сети. Оно будет выступать в качестве корневого домена в конфигурации Bind. Например, если вы выберете home.net в качестве домена, ваш DNS-сервер будет отвечать за home.net и все поддомены под ним, например server1.home.net, printers.home.net и т.д.

Установка Bind

Bind доступен в репозиториях по умолчанию для большинства дистрибутивов Linux.

Ubuntu/Debian

На Ubuntu или Debian установите Bind с помощью apt:

$ sudo apt update
$ sudo apt install bind9 bind9utils

Это позволит установить Bind 9 и некоторые утилиты, такие как dig, nslookup и т.д.

CentOS/RHEL

На CentOS или RHEL установите Bind с помощью yum:

$ sudo yum update
$ sudo yum install bind bind-utils

Это снова установит пакеты и утилиты bind9.

Проверка установки

Чтобы проверить, установлен ли Bind:

$ dig -v

Это должно отобразить версию Bind, которая сейчас установлена:

;; BIND version: 9.11.3-1ubuntu1.2-Ubuntu

Это подтверждает, что Bind установлен и готов к настройке.

После этого в остальной части руководства можно приступить к настройке. Дайте мне знать, если вы хотите добавить какие-либо другие детали в раздел установки!

Базовая конфигурация Bind

Основными файлами конфигурации Bind являются:

  • /etc/bind/named.conf — Основной файл конфигурации Bind, который включает в себя все остальные файлы конфигурации
  • /etc/bind/named.conf.options — Глобальные опции для Bind
  • /etc/bind/named.conf.local — Конфигурация для самого локального DNS-сервера
  • /etc/bind/db.root — Файл корневых подсказок, указывающий на корневые серверы DNS
  • /var/cache/bind — Рабочий каталог для Bind с кэшем и другими данными

Давайте рассмотрим некоторые ключевые параметры, которые нам нужно настроить в этих файлах.

В named.conf.options:

options {
        directory "/var/cache/bind";
        
        forwarders {
                8.8.8.8; 
                8.8.4.4;
        };
        allow-query { any; };
        
        dnssec-validation auto;
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Здесь задается рабочий каталог Bind, публичные DNS-серверы Google настраиваются как переадресаторы для разрешения внешних доменов, разрешаются запросы с любого IP-адреса, включается проверка DNSSEC и прослушивание адресов IPv4 и IPv6.

В named.conf.local, настройте частную корневую зону и данные локального DNS-сервера:

// Define root zone 
zone "home.net" IN {
        type master;
        file "/etc/bind/db.home.net";
};
// Declare local DNS server itself
zone "dns1.home.net" {
        type master;
        file "/etc/bind/db.dns1.home.net";
};

Это определяет home.net как корневая зона, настроенная как мастер-зона, что означает, что наш DNS-сервер будет являться авторитетным сервером для этого домена. Информация о зоне будет загружена из файла db.home.net.

Мы также добавляем объявление зоны для имени нашего локального DNS-сервера dns1.home.net с деталями в db.dns1.home.net файл.

Настройка корневой зоны

Далее нам нужно определить корневую зону home.net подробности в db.home.net файле:

$TTL    604800
@       IN      SOA     dns1.home.net. admin.home.net. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      dns1.home.net.
@       IN      A       192.168.1.100

Это устанавливает TTL по умолчанию, свойства определения записи SOA для зоны, наш DNS-сервер в качестве сервера имен для home.net и его IP-адрес.

Для локального DNS-сервера указывается db.dns1.home.net файл:

$TTL    604800
@       IN      SOA     dns1.home.net. admin.home.net. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      dns1
@       IN      A       192.168.1.100

Здесь настраивается SOA и A-запись для нашего локального DNS-сервера.

Настройка рекурсивной переадресации

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

Это определено в named.conf.options ранее с использованием forwarders . Здесь мы настраиваем публичные DNS-серверы Google 8.8.8.8 и 8.8.4.4 для обработки внешних запросов.

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

Защита DNS-сервера

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

  • Используйте выделенную учетную запись пользователя, не являющегося пользователем root, для процесса Bind
  • Ограничьте доступ к файлам и папкам конфигурации Bind
  • Настройте правила брандмауэра, чтобы разрешить только DNS-трафик на порту 53 для UDP и TCP
  • Включите SElinux или AppArmor для дополнительной безопасности
  • При необходимости используйте TLS для шифрования DNS-трафика
  • Настройте безопасные динамические обновления с помощью TSIG, если клиентам необходимо динамически обновлять записи DNS
  • Включите проверку DNSSEC для повышения безопасности данных DNS
  • Настройте ограничение скорости в named.conf.options для предотвращения атак с усилением DNS

Вот несколько правил брандмауэра, разрешающих только DNS-трафик:

# Allow DNS queries 
$ iptables -A INPUT -p udp --dport 53 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 53 -j ACCEPT
# Allow zone transfers
$ iptables -A INPUT -p tcp --dport 53 -m state --state ESTABLISHED -j ACCEPT
# Allow responses 
$ iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
$ iptables -A OUTPUT -p tcp --sport 53 -j ACCEPT 

Тестирование установки

После установки Bind и базовой настройки мы можем запустить службу и проверить ее работоспособность.

В системах с Systemd выполните команду:

# systemctl start bind9
# systemctl enable bind9

В системах init.d выполните:

# service bind9 start
# chkconfig bind9 on

Проверьте состояние с помощью:

# systemctl status bind9 
# service bind9 status

Служба Bind должна быть активна и запущена.

Теперь мы можем протестировать поиск с помощью dig, nslookup или host команды:

# dig @192.168.1.100 home.net
# nslookup dns1.home.net 192.168.1.100
# host google.com 192.168.1.100

Первый запрос должен вернуть записи SOA и NS для home.net. Второй запрос должен показать запись A для dns1.home.net. Последний — рекурсивный запрос для google.com , который должен вернуть внешний IP-адрес после переадресации на Google DNS.

Если все это работает нормально, значит, ваш сервер Bind DNS правильно настроен для базового разрешения и переадресации DNS!

Настройка зон для локальных сетей

На данный момент наш DNS-сервер знает только о корневом home.net зоне с данными локального DNS-сервера. Нам нужно добавить больше зон, чтобы обеспечить разрешение имен для нашей частной сети.

Предположим, что у нас есть сеть 192.168.1.0/24 с определенными хостами:

  • 192.168.1.100 — Сам наш DNS-сервер dns1.home.net
  • 192.168.1.101 — Веб-сервер с именем web1.home.net
  • 192.168.1.102 — Сервер базы данных db1.home.net
  • 192.168.1.103 — Файловый сервер files.home.net

Мы можем добавить каждый из этих серверов в качестве записи A внутри home.net в самой зоне db.home.net:

web1     IN  A 192.168.1.101
db1      IN  A 192.168.1.102 
files    IN  A 192.168.1.103

Перезагрузив службу Bind, мы теперь можем искать эти хосты и получать IP-адреса:

# dig @192.168.1.100 web1.home.net
# nslookup db1.home.net 192.168.1.100
# host files.home.net 192.168.1.100

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

Добавьте это определение зоны в named.conf.local:

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

Здесь мы определяем зону обратного поиска для IP-адресов 192.168.1.0/24, сопоставленных с зоной .arpa домену.

Файл зоны /etc/bind/db.192:

$TTL    604800
@       IN      SOA     home.net. admin.home.net. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
;
@       IN      NS      dns1.
100     IN      PTR     dns1.home.net.  
101     IN      PTR     web1.home.net.
102     IN      PTR     db1.home.net.
103     IN      PTR     files.home.net.

Определяет обратное сопоставление IP-адресов с именами для хостов в сети 192.168.1.0/24.

После перезагрузки Bind обратный поиск будет работать:

# dig -x 192.168.1.101 @192.168.1.100
# nslookup -query=PTR 192.168.1.102 192.168.1.100
# host 192.168.1.103 192.168.1.100

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

Это обеспечивает авторитетную локальную службу DNS, не полагаясь на внешние DNS-серверы.

Динамическое обновление зон

В больших средах поддержание записей DNS для меняющейся инфраструктуры может быть сложной задачей. Bind предоставляет два способа динамического обновления зон DNS — динамическое обновление DNS (DDNS) и обновления с подписью DNSSEC.

При использовании DDNS клиенты могут напрямую обновлять свои DNS-записи в зоне, отправляя специальные запросы UPDATE на DNS-сервер. Это проще в настройке, но небезопасно.

Обновления с подписью DNSSEC используют подписи транзакций (TSIG) для криптографической подписи запросов на обновление. DNS-сервер принимает только обновления с действительной подписью.

Вот пример включения обновлений DDNS для клиентов в подсети 192.168.1.0/24:

В named.conf.local:

zone "home.net" {
     type master;
     allow-update { 192.168.1/24; };
     file "/etc/bind/db.home.net";
}; 

The allow-update позволяет обновлять информацию из подсети.

Клиентские машины могут использовать nsupdate команду для добавления/изменения/удаления записей. Например:

# nsupdate
> update add web2.home.net 3600 A 192.168.1.105
> send

Это добавит запись A для web2.home.net. Записи можно удалить, указав их имя и ttl только значение.

Для обновлений с подписью TSIG сервер и клиенты используют общий ключ TSIG. Ключ может быть сгенерирован с помощью dnssec-keygen. Клиенты подписывают пакет UPDATE подписью TSIG.

На сервере named.conf указывает ключ TSIG и включает подписанные обновления:

key "tsig-key" {
     algorithm hmac-sha256;
     secret "b3BlbnNlc2FtZTAwMA=="; 
};
  
zone "home.net" {
    type master;
    allow-update { key tsig-key; };
    ...
}

Клиенты могут использовать один и тот же ключ для подписи запросов на обновление. Это гарантирует, что только авторизованные узлы могут динамически обновлять свои записи DNS.

Разделенно-горизонтная DNS

Иногда частные внутренние DNS-серверы могут выдавать результаты, отличные от внешних публичных DNS, чтобы обеспечить раздельную настройку DNS. Это известно как split-horizon DNS.

Например, webserver.company.com внутренне может разрешиться на частный IP 192.168.1.101 , в то время как внешне он разрешается в публичный IP 1.2.3.4.

Мы можем достичь этого с помощью Bind, определив company.com зону как в качестве прямой зоны для публичных IP-адресов, так и в качестве отдельной обратной зоны для внутренних IP-адресов.

В named.conf.local:

// Forward Zone
zone "company.com" {
    type master;
    file "/etc/bind/db.company.com.public";
}
// Reverse Zone 
zone "1.168.192.in-addr.arpa"{ 
   type master;
   file "/etc/bind/db.company.com.private";
}

Это позволяет определить различные записи A для webserver.company.com в файлах публичной и частной зон. Сервер BIND можно настроить на прослушивание различных сетевых интерфейсов для получения нужных данных.

Раздельная DNS полезна для обеспечения безопасности, изоляции и контроля политики между публичными и частными данными DNS.

Кэширование и предварительная выборка

Включение кэширования и предварительной выборки на DNS-сервере может повысить производительность. По умолчанию Bind кэширует результаты запросов для повышения скорости разрешения.

Мы можем настроить значения TTL кэша в named.conf.options:

dnssec-validation auto;
recursion yes; 
cache-size 500m;
cache-file "/var/cache/bind/db.cache"; 
prefetch 2;
prefetch-key no-edns;
dnssec-accept-expired yes;
max-cache-ttl 600;        # 10 minutes 
max-ncache-ttl 90;        # 1.5 minutes

Позволяет кэшировать до 500 МБ данных на диск, устанавливает уровень предварительной выборки, ограничения TTL кэша и позволяет использовать истекшие записи при обновлении данных DNSSEC.

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

Ведение журнала и мониторинг

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

В named.conf.options:

logging {
        channel query_log {
                file "/var/log/query.log" versions 3 size 20m;
                severity info;
                print-category yes;
                print-severity yes;
                print-time yes;
        };
        category queries { query_log; };
};

Ключевыми показателями для мониторинга являются:

  • Скорость выполнения запросов и время отклика
  • Использование кэша и коэффициенты попадания
  • Ошибки проверки DNSSEC
  • Неудачные обновления или переносы зон
  • События, связанные с ограничением скорости или нарушением доступа
  • Сетевые ошибки и таймауты

Интеграция DNS-сервера с системой мониторинга обеспечивает важную видимость операций и производительности DNS.

Тестирование и проверка

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

  • Используйте инструменты поиска DNS, такие как dig, nslookup и host для тестирования различных способов поиска записей
  • Выполните обратный поиск, чтобы убедиться, что PTR-записи определены правильно
  • Убедитесь в том, что передача зон работает безопасно для вторичных серверов
  • Протестируйте динамические обновления, добавляя/удаляя записи с помощью nsupdate
  • Проверьте, что конфигурации с разделенным горизонтом возвращают правильные внутренние и внешние результаты
  • Убедитесь, что проверка DNSSEC работает для подписанных зон
  • Проведите нагрузочное тестирование DNS-сервера с помощью таких инструментов, как dnsperf и namebench
  • Проверяйте журналы и мониторы во время тестирования, чтобы выявить любые ошибки
  • Сканирование на предмет проблем безопасности, таких как уязвимые версии программного обеспечения, надежность шифрования
  • Проведите тест на проникновение, чтобы выявить и устранить уязвимости

Тщательное тестирование и проверка DNS-сервера снижают риск и обеспечивают уверенность в доступности, производительности, безопасности и корректности инфраструктуры DNS.

Заключение

В этом подробном руководстве мы рассказали о том, как установить, настроить и сконфигурировать Bind 9 в качестве локального DNS-сервера для частных сетей.

Мы установили пакеты Bind, настроили базовый named.conf файлы, настроили переадресацию, списки контроля доступа и другие параметры. Мы добавили зоны первичного и обратного поиска для доменов и хостов внутренней сети. Также были настроены динамические обновления, разделенный горизонт DNS, кэширование, ведение журнала и мониторинг.

Развертывание Bind в качестве локального DNS-сервера обеспечивает централизованные службы именования для вашей частной среды. Это обеспечивает больший контроль, настройку, конфиденциальность, безопасность и автономность вашей частной DNS-инфраструктуры по сравнению с использованием только внешних провайдеров.

Конечно, для обеспечения надежной работы DNS-служб необходимы усиленная защита, надежный мониторинг, тестирование, резервирование и надлежащее обслуживание. Но благодаря гибким конфигурациям Bind может удовлетворить требования к локальной DNS даже крупных частных сетей и пользовательских развертываний.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *