Введение
Связать (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 даже крупных частных сетей и пользовательских развертываний.