Установка кэширующего dns сервера
Важной частью управления конфигурацией и инфраструктурой сервера является поддержка простого поиска сетевых интерфейсов и IP-адресов по имени путем настройки правильной системы доменных имен (DNS, Domain Name System). Использование полных доменных имен (FQDN) вместо IP-адресов для определения сетевых адресов облегчает настройку сервисов и приложений и упрощает поддержку файлов конфигурации. Настройка собственного DNS-сервера для частной сети – отличный способ улучшить управление серверами.
Данный мануал поможет настроить в Debian 9 внутренний DNS-сервер с помощью сервера имен BIND (BIND9), который может использоваться вашими серверами для разрешения внутренних имен хостов и IP-адресов. Это обеспечивает централизованный способ управления внутренними именами хостов и IP-адресами, что необходимо для среды, которая состоит из нескольких хостов.
1: Установка BIND на DNS-серверы
Примечание: Обратите внимание на текст, выделенный красным цветом. Он часто указывает, что необходимо заменить своими данными или добавить в файл конфигурации.
На серверах ns1 и ns2 обновите индекс пакетов:
sudo apt-get update
Затем установите BIND:
sudo apt-get install bind9 bind9utils bind9-doc
Настройка режима IPv4
Прежде чем продолжить, переведите BIND в режим IPv4, поскольку частная сеть использует только IPv4. На обоих серверах отредактируйте конфигурационный файл по умолчанию bind9:
sudo nano /etc/default/bind9
Добавьте опцию -4 в конец параметра OPTIONS:
Сохраните и закройте файл.
Чтобы обновить настройки, перезапустите BIND:
sudo systemctl restart bind9
Клиенты CentOS
В CentOS, RedHat и Fedora Linux отредактируйте файл /etc/sysconfig/network-scripts/ifcfg-eth0. Возможно, вам придется заменить eth0 именем своего сетевого интерфейса:
sudo nano /etc/sysconfig/network-scripts/ifcfg- eth0
Сохраните и закройте файл.
sudo systemctl restart network
Команда может висеть в течение нескольких секунд, но вскоре должна вернуть вас в командную строку.
Убедитесь, что ваши изменения были применены:
Вы должны увидеть свои серверы имен и домен в списке:
Настойка клиента завершена.
Добавление хоста в DNS
Всякий раз, когда вы добавляете хост в свою среду (в том же центре данных), вам нужно добавить его и в DNS. Вот как это делается.
- Файл зоны прямого просмотра: добавьте запись «А» для нового хоста, увеличьте значение Serial.
- Файл зоны обратного просмотра: добавьте запись PTR для нового хоста, увеличьте значение Serial.
- Добавьте внутренний IP-адрес нового хоста в ACL trusted (named.conf.options).
- Протестируйте настройку:
sudo systemctl reload bind9
Теперь ваш первичный сервер должен поддерживать новый хост.
- Добавьте внутренний IP нового хоста в ACL trusted (named.conf.options).
- Проверьте синтаксис:
sudo systemctl reload bind9
Теперь ваш вторичный сервер должен поддерживать новый хост.
Чтобы настроить новый хост для поддержки DNS:
- Настройте поддержку в файле /etc/resolv.conf.
- Протестируйте работу хоста с помощью nslookup.
Заключение
Теперь вы можете ссылаться на внутренние сетевые интерфейсы своих серверов по имени, а не по IP-адресу. Это упрощает настройку сервисов и приложений, поскольку вам больше не нужно запоминать IP-адреса, и файлы станет легче читать и понимать.
После настройки внутреннего DNS важно обеспечить DNS-серверам хорошую поддержку. Если они оба станут недоступными, ваши сервисы и приложения, которые полагаются на них, перестанут функционировать должным образом. Вот почему рекомендуется использовать в настройке DNS как минимум один вторичный сервер и поддерживать рабочие резервные копии всех серверов.
DNS (Domain Name System) – важный и довольно сложный в настройке компонент, необходимый для работы веб-сайтов и серверов. Многие пользователи обращаются к DNS-серверам, которые предоставляет их хостинг-провайдер, однако собственные DNS-серверы имеют некоторые преимущества.
В данном мануале вы узнаете, как установить Bind9 и настроить его как кэширующий или перенаправляющий DNS-сервер на сервере Ubuntu 14.04.
Клиенты CentOS
В CentOS, RedHat и Fedora Linux отредактируйте файл /etc/sysconfig/network-scripts/ifcfg-eth0. Возможно, вам придется заменить eth0 именем своего сетевого интерфейса:
sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0
Сохраните и закройте файл.
sudo systemctl restart network
Команда может висеть в течение нескольких секунд, но вскоре должна вернуть вас в командную строку.
Убедитесь, что ваши изменения были применены:
Вы должны увидеть свои серверы имен и домен в списке:
Настойка клиента завершена.
4: Проверка настроек и перезапуск Bind
Теперь нужно убедиться, что настройки работают должным образом.
Чтобы проверить синтаксис конфигурационных файлов, введите:
Если в файлах нет ошибок, командная строка не отобразит никакого вывода.
После этого можно перезапустить демон Bind, чтобы обновить настройки.
sudo service bind9 restart
После нужно проверить логи сервера. Запустите на сервер команду:
sudo tail -f /var/log/syslog
Теперь откройте новый терминал и приступайте к настройке клиентской машины.
2: Настройка первичного DNS-сервера
Конфигурация BIND состоит из нескольких файлов, которые включены в основной файл конфигурации named.conf. Имена этих файлов начинаются с named, потому что это имя процесса, который запускает BIND. Начнем с настройки файла options.
Настройка файла local
На ns1 откройте файл named.conf.local:
sudo nano /etc/bind/named.conf.local
Добавьте зону прямого просмотра, заменив имя зоны и внутренний IP-адрес вторичного DNS-сервера в директиве allow-transfer:
Учитывая, что вы используете частную подсеть 10.128.0.0/16, добавьте зону обратного просмотра (обратите внимание, что имя этой зоны начинается с «128.10», обратно от «10.128»):
Если ваши серверы охватывают несколько частных подсетей, но находятся в одном и том же центре данных, обязательно укажите дополнительный файл зоны и зону для каждой отдельной подсети. Когда вы закончите добавлять все нужные зоны, сохраните и выйдите из файла named.conf.local.
Теперь, когда зоны указаны в BIND, необходимо создать соответствующие файлы зон прямого и обратного просмотра.
Пример инфраструктуры и цели
В мануале предполагается, что:
Хост | Роль | Частный FQDN | Внутренний IP-адрес |
ns1 | Первичный DNS-сервер | ns1.nyc3.example.com | 10.128.10.11 |
ns2 | Вторичный DNS-сервер | ns2.nyc3.example.com | 10.128.20.12 |
host1 | Клиент Host 1 | host1.nyc3.example.com | 10.128.100.101 |
host2 | Клиент Host 2 | host2.nyc3.example.com | 10.128.200.102 |
Примечание: Ваша ситуация будет отличаться, но условные имена и IP-адреса будут использоваться в этом мануале для демонстрации настройки DNS-сервера для обеспечения работы внутреннего DNS. Вы должны легко адаптировать эту настройку к своей собственной среде, заменив имена хостов и внутренние IP-адреса своими собственными данными. Использовать имя региона центра обработки данных в схеме именования нет необходимости, но мы используем его здесь, чтобы обозначить, что эти хосты принадлежат частной сети одного центра обработки данных. Если вы используете несколько центров обработки данных, вы можете настроить внутренний DNS в каждом соответствующем ЦОД.
В результате у вас будет первичный DNS-сервер ns1 и вторичный DNS-сервер ns2.
5: Тестирование клиентов
Используйте nslookup, чтобы проверить, могут ли ваши клиенты запрашивать серверы имен. Вы должны иметь возможность сделать это на всех клиентах, которые вы настроили и которые находятся в доверенном ACL.
На клиентах CentOS может потребоваться установить утилиту с помощью команды:
sudo yum install bind-utils
Чтобы установить утилиту на клиенты Debian, введите:
sudo apt install dnsutils
Начнем с прямого просмотра.
Создание файла(ов) зоны обратного просмотра
На ns1 для каждой зоны обратного просмотра, указанной в файле named.conf.local, создайте отдельный файл. Этот файл (ы) зоны обратного просмотра можно создать на основе файла db.127. Скопируйте его в нужное место (имя целевого файла должно соответствовать определению вашей зоны обратного просмотра):
sudo cp /etc/bind/db.127 /etc/bind/zones/db. 10.128
Отредактируйте файл зоны, соответствующий зоне (зонам) обратного просмотра, определенной в named.conf.local:
sudo nano /etc/bind/zones/db. 10.128
Изначально файл будет выглядеть так:
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line
Так же, как и в файле зоны прямого просмотра, здесь нужно отредактировать запись SOA и увеличить значение serial. Этот блок должен выглядеть примерно так:
Теперь удалите две записи в конце файла (после записи SOA). Выше они помечены комментарием «delete this line».
В конце файла добавьте записи своего сервера имен (замените имена на свои). Обратите внимание, что во втором столбце указано, что это записи NS.
Затем добавьте записи PTR для всех ваших серверов, чьи IP-адреса находятся в подсети этой зоны. В данном примере она включает в себя все хосты, потому что все они находятся в подсети 10.128.0.0/16. Обратите внимание: первый столбец состоит из двух последних октетов внутренних IP-адресов серверов в обратном порядке. Не забудьте заменить имена и внутренние IP-адреса своими данными.
Сохраните и закройте файл зоны. Повторите этот раздел для каждой отдельной зоны обратного просмотра.
В результате файл имеет такой вид:
Клиенты Ubuntu 18.04
На Ubuntu 18.04 сеть настроена с помощью Netplan, абстракции, которая позволяет писать стандартизованную конфигурацию сети и применять ее к несовместимому сетевому программному обеспечению. Чтобы настроить DNS, нужно создать файл конфигурации Netplan.
Сначала найдите устройство, связанное с частной сетью, запросив его с помощью команды ip address:
ip address show to 10.128.0.0/16
3: eth1 : mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
valid_lft forever preferred_lft forever
В данном случае используется интерфейс eth1.
Затем создайте новый файл 00-private-nameservers.yaml в /etc/netplan:
sudo nano /etc/netplan/00-private-nameservers.yaml
В файл вставьте следующее содержимое. Вам нужно изменить интерфейс частной сети, адреса DNS-серверов ns1 и ns2 и зону DNS:
Примечание: Netplan использует формат сериализации данных YAML в своих файлах конфигурации.
Сохраните и закройте файл.
Затем сообщите Netplan, что новый файл конфигурации можно использовать с помощью netplan try. Если у вас возникают проблемы, которые вызывают потерю сети, Netplan автоматически откатит изменения после таймаута:
sudo netplan try
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
Если обратный отсчет внизу корректно обновляется, то новая конфигурация, по крайней мере, работает достаточно хорошо, чтобы не нарушить соединение SSH. Нажмите Enter, чтобы принять новую конфигурацию.
Теперь убедитесь, что системный DNS-резолвер применил новую конфигурацию:
sudo systemd-resolve --status
Прокрутите страницу вниз, пока не увидите раздел вашего сетевого интерфейса. Вы сначала должны увидеть внутренние IP-адреса ваших DNS-серверов, а затем некоторые резервные значения. Ваш домен должен находиться в DNS Domain.
3: Настройка вторичного DNS-сервера
В большинстве сред рекомендуется создать вторичный DNS-сервер, который будет отвечать на запросы, если первичный сервер выйдет из строя. К счастью, вторичный DNS-сервер намного проще настроить.
На ns2 отредактируйте файл named.conf.options:
sudo nano /etc/bind/named.conf.options
В начале файла добавьте ACL с внутренними IP-адресами доверенных серверов.
Под директивой directory вставьте такие строки:
Сохраните и закройте файл named.conf.options. Этот файл должен выглядеть точно так же, как и файл named.conf.options сервера ns1, за исключением того, что он должен прослушивать внутренний IP-адрес ns2.
Теперь отредактируйте файл named.conf.local:
sudo nano /etc/bind/named.conf.local
Определите вторичные зоны, соответствующие зонам первичного DNS-сервера. Обратите внимание, что тип должен быть slave, файл не содержит пути, и в нем есть директива masters, которая должна указывать внутренний IP-адрес первичного DNS-сервера. Если вы определили несколько зон обратного просмотра на первичном DNS-сервере, обязательно укажите их все здесь.
Сохраните и закройте файл.
Чтобы проверить файлы на наличие ошибок, введите:
Если ошибок нет, перезапустите BIND:
sudo systemctl restart bind9
Разрешите подключения DNS, изменив правила брандмауэра UFW:
sudo ufw allow Bind9
Теперь у вас есть первичный и вторичный DNS-сервер. Пора настроить клиентские серверы.
Прямой просмотр
Теперь попробуем обратный просмотр.
Пара моментов в конфиге
В принципе, кэширование можно сделать менее агрессивным (min_ttl=1m например), но за год работы проблем особых не возникло. В случае проблем — при желании можно вытереть одну запись из кэша:
или сразу все:
Перезапуск BIND
Чтобы перезапустить BIND, введите:
sudo systemctl restart bind9
Если у вас настроен брандмауэр UFW, откройте доступ к BIND:
sudo ufw allow Bind9
Первичный DNS-сервер настроен и может обрабатывать запросы DNS. Теперь создадим вторичный сервер.
Прямой просмотр
Теперь попробуем обратный просмотр.
6: Поддержка DNS-записей
Итак, у вас есть рабочий внутренний DNS, и вам необходимо сохранить свои записи DNS, чтобы они точно отражали вашу серверную среду.
Обратный просмотр
Чтобы протестировать обратный просмотр, запросите DNS-сервер:
Команда должна вернуть такой вывод:
Теперь рассмотрим сохранение записей в зоне.
Требования
Для работы вам понадобится следующая инфраструктура. Все серверы должны находиться в одном ЦОД с включенной поддержкой частной сети.
- Свежий сервер Ubuntu 18.04 для настройки первичного DNS-сервера (в мануале он называется ns1).
- Рекомендуется: сервер Ubuntu 18.04 для настройки вторичного DNS-сервера (в мануале он называется ns2).
- Дополнительные серверы в том же центре обработки данных, которые будут использовать DNS-серверы.
На каждом из этих серверов настройте пользователя sudo и брандмауэр, следуя мануалу по начальной настройке сервера Ubuntu 18.04.
Обратный просмотр
Чтобы протестировать обратный просмотр, запросите DNS-сервер:
Команда должна вернуть такой вывод:
Теперь рассмотрим сохранение записей в зоне.
Пример инфраструктуры и цели
В мануале предполагается, что:
Хост | Роль | Частный FQDN | Внутренний IP-адрес |
ns1 | Первичный DNS-сервер | ns1.nyc3.example.com | 10.128.10.11 |
ns2 | Вторичный DNS-сервер | ns2.nyc3.example.com | 10.128.20.12 |
host1 | Клиент Host 1 | host1.nyc3.example.com | 10.128.100.101 |
host2 | Клиент Host 2 | host2.nyc3.example.com | 10.128.200.102 |
Примечание: Ваша ситуация будет отличаться, но условные имена и IP-адреса будут использоваться в этом мануале для демонстрации настройки DNS-сервера для обеспечения работы внутреннего DNS. Вы должны легко адаптировать эту настройку к своей собственной среде, заменив имена хостов и внутренние IP-адреса своими собственными данными. Использовать имя региона центра обработки данных в схеме именования нет необходимости, но мы используем его здесь, чтобы обозначить, что эти хосты принадлежат частной сети одного центра обработки данных. Если вы используете несколько центров обработки данных, вы можете настроить внутренний DNS в каждом соответствующем ЦОД.
В результате у вас будет первичный DNS-сервер ns1 и вторичный DNS-сервер ns2.
Файл options
На сервере ns1 откройте этот файл:
sudo nano /etc/bind/named.conf.options
Над существующим блоком options создайте новый блок управления доступом ACL (access control list) под названием trusted. Здесь можно определить список клиентов, которые могут отправлять рекурсивные DNS-запросы (например, ваши серверы, находящиеся в том же ЦОД, что и ns1). Добавьте ns1, ns2, host1 и host2 в список доверенных клиентов:
Теперь, когда у вас есть список доверенных DNS-клиентов, можно отредактировать блок options. В настоящее время начало блока выглядит следующим образом:
Под директивой directory добавьте выделенные строки конфигурации (и укажите соответствующий IP-адрес сервера ns1):
Теперь сохраните и закройте файл named.conf.options. В приведенной выше конфигурации указано, что только ваши доверенные серверы смогут запросить внешние домены у DNS-сервера.
Затем нужно настроить файл local, чтобы определить DNS-зоны.
4: Настройка DNS-клиентов
Прежде чем все ваши серверы из ACL trusted смогут запрашивать DNS-серверы, нужно настроить каждый из них для использования ns1 и ns2 в качестве серверов имен. Этот процесс зависит от ОС, но в большинстве дистрибутивов Linux для этого нужно добавить серверы имен в файл /etc/resolv.conf.
Создание файла(ов) зоны прямого просмотра
На ns1 для каждой зоны обратного просмотра, указанной в файле named.conf.local, создайте отдельный файл. Этот файл(ы) зоны обратного просмотра можно создать на основе файла db.127. Скопируйте его в нужное место (имя целевого файла должно соответствовать определению вашей зоны обратного просмотра):
sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128
Отредактируйте файл зоны, соответствующий зоне (зонам) обратного просмотра, определенной в named.conf.local:
sudo nano /etc/bind/zones/db.10.128
Изначально файл будет выглядеть так:
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line
Так же, как и в файле зоны прямого просмотра, здесь нужно отредактировать запись SOA и увеличить значение serial. Этот блок должен выглядеть примерно так:
Теперь удалите две записи в конце файла (после записи SOA). Выше они помечены комментарием «delete this line».
В конце файла добавьте записи своего сервера имен (замените имена на свои). Обратите внимание, что во втором столбце указано, что это записи NS.
Затем добавьте записи PTR для всех ваших серверов, чьи IP-адреса находятся в подсети этой зоны. В данном примере она включает в себя все хосты, потому что все они находятся в подсети 10.128.0.0/16. Обратите внимание: первый столбец состоит из двух последних октетов внутренних IP-адресов серверов в обратном порядке. Не забудьте заменить имена и внутренние IP-адреса своими данными.
Сохраните и закройте файл зоны. Повторите этот раздел для каждой отдельной зоны обратного просмотра.
В результате файл имеет такой вид:
Требования
Для работы вам понадобится следующая инфраструктура. Все серверы должны находиться в одном ЦОД с включенной поддержкой частной сети.
- Свежий сервер Debian 9 для настройки первичного DNS-сервера (в мануале он называется ns1).
- Рекомендуется: сервер Debian 9 для настройки вторичного DNS-сервера (в мануале он называется ns2).
- Дополнительные серверы в том же центре обработки данных, которые будут использовать DNS-серверы.
На каждом из этих серверов настройте пользователя sudo и брандмауэр, следуя мануалу по начальной настройке сервера Debian 9.
2: Настройка кэширующего DNS-сервера
Сначала нужно настроить Bind в качестве кэширующего DNS-сервера. Такая конфигурация заставит сервер рекурсивно искать ответы на клиентские запросы на других DNS-серверах. Он будет последовательно опрашивать все соответствующие DNS-сервера, пока не найдет ответ.
Конфигурационные файлы Bind хранятся в каталоге /etc/bind.
Большую часть файлов редактировать не нужно. Главный конфигурационный файл называется named.conf (named и bind – два названия одного приложения). Этот файл ссылается на файлы named.conf.options, named.conf.local и named.conf.default-zones.
Для настройки кэширующего DNS-сервера нужно отредактировать только named.conf.options.
sudo nano named.conf.options
Этот файл выглядит так (комментарии опущены для простоты):
Чтобы настроить кэширующий сервер, нужно создать список контроля доступа, или ACL.
Нужно защитить DNS-сервер, обрабатывающий рекурсивные запросы, от злоумышленников. Атаки DNS-усиления особенно опасны, поскольку могут вовлечь сервер в распределенные атаки на отказ в обслуживании.
Атаки DNS-усиления – это один из способов прекращения работы серверов и сайтов. Для этого злоумышленники пытаются найти общедоступные DNS-серверы, которые обрабатывают рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который вернет DNS-серверу очень объемный ответ. При этом DNS-сервер возвращает на сервер жертвы слишком много данных в ответ на небольшой запрос, увеличивая доступную пропускную способность злоумышленника.
Для размещения общедоступного рекурсивного DNS-сервера требуется тщательная настройка и администрирование. Чтобы предотвратить возможность взлома сервера, настройте список IP-адресов или диапазонов сети, которым сервер сможет доверять.
Перед блоком options добавьте блок acl. Создайте метку для группы ACL (в данном мануале группа называется goodclients).
В этом блоке перечислите IP-адреса или сети, у которых будет доступ к этому DNS-серверу. Поскольку сервер и клиент работают в подсети /24, можно ограничить доступ по этой подсети. Также нужно разблокировать localhost и localnets, которые подключаются автоматически.
acl goodclients 192.0.2.0/24;
localhost;
localnets;
>;
options . . .
Теперь у вас есть ACL безопасных клиентов. Можно приступать к настройке разрешения запросов в блоке options. Добавьте в него такие строки:
options directory "/var/cache/bind";
recursion yes;
allow-query < goodclients; >;
. . .
Блок options явно включает рекурсию, а затем настраивает параметр allow-query для использования списка ACL. Для ссылки на группу ACL можно также использовать другой параметр, например allow-recursion. При включенной рекурсии allow-recursion определит список клиентов, которые могут использовать рекурсивные сервисы.
Однако если параметр allow-recursion не установлен, Bind возвращается к списку allow-query-cache, затем к списку allow-query и, наконец, к спискам по умолчанию localnets и localhost. Поскольку мы настраиваем только кэширующий сервер (он не имеет собственных зон и не пересылает запросы), список allow-query всегда будет применяться только к рекурсии. Это самый общий способ определения ACL.
Сохраните и закройте файл.
Это все настройки, которые нужно добавить в конфигурационный файл кэширующего DNS-сервера.
Примечание: Если вы хотите использовать только этот тип DNS, переходите к проверке конфигураций, перезапустите сервис и настройте свой клиент.
Создание файла зоны прямого просмотра
Создайте каталог, в котором будут находиться файлы зон. Согласно конфигурации named.conf.local, его расположение – /etc/bind/zones:
sudo mkdir /etc/bind/zones
В качестве основы для файла зоны прямого просмотра можно использовать файл зоны db.local. Скопируйте его в нужное место:
Откройте файл в редакторе:
Изначально он выглядит так:
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
Затем удалите три записи в конце файла (после записи SOA). В исходном файле выше они отмечены комментарием «delete this line».
В конце файла добавьте записи своего сервера имен (замените имена своими данными). Обратите внимание, что во втором столбце указано, что это записи NS.
Сохраните и закройте файл.
В результате файл зоны имеет такой вид:
Теперь пора заняться файлом (файлами) зоны обратного просмотра.
5: Настройка клиента
Войдите на клиентскую машину. Убедитесь, что клиент был указан в группе ACL настроенного DNS-сервера. В противном случае DNS-сервер откажется обслуживать запросы этого клиента.
Изменения, внесенные здесь, будут сохраняться только до перезагрузки, что отлично подходит для тестирования. Если результаты тестовой настройки вас удовлетворят, вы сможете сделать эти настройки постоянными.
Откройте файл с помощью sudo в текстовом редакторе:
sudo nano /etc/resolv.conf
В файле нужно перечислить DNS-серверы, которые будут использоваться для разрешения запросов. Для этого используйте директиву nameserver. Закомментируйте все текущие записи и добавьте строку nameserver, указывающую на ваш DNS-сервер:
Сохраните и закройте файл.
Для этого можно использовать ping:
Более подробную информацию предоставит инструмент dig. Попробуйте подключиться к другому домену:
Как видите, обработка запроса заняла 36 миллисекунд. Повторите запрос. Сервер должен извлечь данные из кэша, что укорит обработку запроса:
Теперь запрос обрабатывается гораздо быстрее.
Также можно протестировать обратное преобразование. Для этого используйте найденный IP (в данном случае 140.211.169.4) и dig с флагом –x:
Как видите, обратное преобразование выполнено успешно.
Вернитесь на DNS-сервер. Если во время настройки клиента возникли какие-либо ошибки, вы увидите их. К примеру, часто случается такая ошибка:
Это значит, что сервер пытается разрешить данные IPv6, но он не настроен для поддержки IPv6. Чтобы устранить ошибку, нужно настроить Bind для обслуживания только IPv4.
sudo nano /etc/default/bind9
Найдите параметр OPTIONS и добавьте в него флаг -4, чтобы настроить поддержку только IPv4.
Сохраните и закройте файл.
sudo service bind9 restart
После этого в логах не должно быть ошибок.
1: Установка Bind на DNS-сервер
Пакет Bind можно найти в официальном репозитории Ubuntu. Обновите индекс пакетов и установите Bind с помощью менеджера apt. Также нужно установить пару зависимостей.
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
После этого можно начать настройку сервера. Конфигурацию кэширующего сервера можно использовать в качестве шаблона для настройки перенаправляющего сервера, поэтому сначала нужно настроить кэширующий DNS-сервер.
Настойка режима IPv4
Прежде чем продолжить, переведите BIND в режим IPv4, поскольку частная сеть использует только IPv4. На обоих серверах отредактируйте конфигурационный файл по умолчанию bind9:
sudo nano /etc/default/bind9
Добавьте опцию -4 в конец параметра OPTIONS:
Сохраните и закройте файл.
Чтобы обновить настройки, перезапустите BIND:
sudo systemctl restart bind9
Перенаправляющий DNS-сервер
С точки зрения клиента перенаправляющий DNS-сервер будет выглядеть почти идентично кэширующему серверу, но механизмы и рабочая нагрузка у них совершенно разные.
Перенаправляющий DNS-сервер имеет те же преимущества, что и кэширующий сервер. Однако на самом деле он не выполняет ни одного рекурсивного запроса. Вместо этого он перенаправляет все запросы на внешний разрешающий сервер, а затем кэширует результаты для последующих запросов.
Проверка синтаксиса конфигурации BIND
Запустите следующую команду, чтобы убедиться, что в файлах нет ошибок:
Команда named-checkzone может использоваться для проверки правильности ваших файлов зон. Ее первый аргумент указывает имя зоны, а второй – соответствующий файл зоны, которые определены в named.conf.local.
А чтобы проверить конфигурацию зоны обратного просмотра 128.10.in-addr.arpa, выполните следующую команду:
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
Проверив все конфигурационные файлы, вы можете перезапустить сервис BIND.
Удаление хоста из DNS
Если вы удалите хост из своей среды или просто хотите удалить его из DNS, просто удалите все данные о нем, которые вы добавили при настройке поддержки DNS.
Кэширующий DNS-сервер
Серверы этого типа также называются определителями, поскольку они обрабатывают рекурсивные запросы и, как правило, могут выполнить поиск данных DNS не других серверах.
Почти все DNS-серверы в вашей сетевой конфигурации будут кэширующими. Кэширующий DNS-сервер – хороший выбор для многих ситуаций. Если вы не хотите полагаться на DNS-серверы вашего хостинг-провайдера или другие общедоступные DNS-серверы, настройте собственный кэширующий DNS-сервер. Чем меньше расстояние от DNS-сервера к клиентским машинам, тем меньше время обслуживания запросов DNS.
Результаты тестирования в NameBench
Видим, что для 50% запросов ответ мы получаем менее чем за 10мс, для 85% быстрее Google Public DNS, ну а дальше результаты естественно совпадают с гуглом.
По результатам тестов NameBench нам радостно сообщает:
Таким образом, умный кэширующий DNS прокси с параллельными запросами — позволяет ускорить даже 100-мегабитный интернет. А уж для медленных (радио)линков с большой латентностью и потерей пакетов — и вовсе разница может быть как между небом и землей.
В этой статье я опишу настройку авторитетного DNS сервера, на основе решения PowerDNS. PowerDNS — высокопроизводительный, бесплатный DNS сервер с открытым исходным кодом.
Моя версия ПО:
PowerDNS authoritative v3.4.8
PowerDNS recursor v3.7.3
Poweradmin v2.1.7
1) Обновляем систему и подключаем репозитории:
2) Устанавливаем различные полезные утилиты
3) Отключение firewalld и устанавливаем iptables
Создаем правила для файервола
И перезагружаем iptables
4) Создаем папку со скриптами для управления
5) Устанавливаем базу данных. Для Centos 7 лучше подходит MariaDB.
Тут есть несколько вариантов:
— Локальная база без репликации
— SQL кластер.
Установка локальной базы без репликации
Добавляем репозиторий.
Вставляем в файл следующие строки:
Затем выполните следующую команду, чтобы защитить сервер базы данных.
Затем выберите «Y» (Да) для остальных подсказок, пока вы не закончите.
Последнее, необходимо заменить cnf.ini файл по умолчанию в /etc/ для MariaDB. Но для начала нужно перейти в:
И использовать один из предопределенных cnf.ini конфигураций которые доступны (Huge, Medium и Small) в данной папке.
Сделаем резервное копирование cnf.ini файла:
Затем скопируйте один из предварительных конфигураций в MariaDB:
Перезапускаем MariaDB и добавляем в автозапуск
Мне нужно создать пользователя и чтобы он мог подключатся с любого компьютера, для этого:
Можно попробовать подключиться к базе данных, например с помощью программы Navicat Premium.
Также в качестве базы данных для PowerDNS, можно использовать SQL кластер.
Настройка SQL кластера
Ноды кластера устанавливаются на тех же серверах, что и сам PowerDNS. При изменении зоны на одном сервере, происходит репликация базы, следовательно зона изменяется на другом сервере.
Я устанавливал кластер так:
Добавляем репозиторий MariaDB как в первой части статьи и устанавливаем необходимые пакеты.
Запуск на первичной ноде (primary)
Запуск на остальных нодах (secondary)
Проверяем репликацию
На каждой ноде смотрим статус кластера:
Создаем тестовую базу данных на первой ноде
Проверяем наличие этой базы на каждой ноде
На всех нодах, должно быть правильно установленно время, это обязательно. Иначе вы столкнётесь с тем что, при SST ноды с донора, синхронизируемая нода будет просто чего-то ждать, без каких бы то ни было признаком активности.
Устанавливаем ntp:
Также можно указать свой ntp сервер в файле /etc/ntp.conf
7) Устанавливаем PowerDNS autoritative.
Через репозиторий epel
Либо из исходников
Исходники PowerDNS можно найти на github.
Устанавливаем необходимые программы для сборки из исходников и выполняем предварительное конфигурирование.
Далее собираем и устанавливаем PowerDNS. Также можно посмотреть доступные опции.
8) Настраиваем конфигурацию авторитетного сервера
9) Устанавливаем рекурсивный DNS
v4.0.0 Через репозиторий powerdns
10) Установка веб интерфейса администратора
Подготовительные действия.
Открываем доступ к веб GUI
В этом файле меняются строки:
$db_host = 'localhost';
$db_port = '3306';
$db_user = 'imperituroard';
$db_pass = 'password';
$db_name = 'powerdns';
$db_type = 'mysql';
Меняем Default session encryption key
12) Финальная настройка
Заходим по адресу 172.24.184.177/poweradmin/install/index.php
Где 172.24.184.177 — IP вашего сервера.
И вводим все предложенные данные.
После завершения установки, удаляем папку /var/www/html/poweradmin/install и заходим в веб интерфейс управления по
адресу 172.24.184.177/poweradmin/index.php
При настройке, есть несколько особенностей:
-при вводе сервера, где находится база, следует вводить localhost а не 127.0.0.1
-следует обязательно создавать пользователя с ограниченными правами на последнем шаге, в противном случае у админа будут ограниченные права.
А вот так выглядит веб интерфейс (есть русский язык):
P.S. Эта статья — первая часть моего рассказа. В следующей части я расскажу про дальнейшие настройки, для оптимизации производительности и пр.
Клиенты Ubuntu 18.04
На Ubuntu 18.04 сеть настроена с помощью Netplan, абстракции, которая позволяет писать стандартизованную конфигурацию сети и применять ее к несовместимому сетевому программному обеспечению. Чтобы настроить DNS, нужно создать файл конфигурации Netplan.
Сначала найдите устройство, связанное с частной сетью, запросив его с помощью команды ip address:
ip address show to 10.128.0.0/16
3: eth1: mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
valid_lft forever preferred_lft forever
В данном случае используется интерфейс eth1.
Затем создайте новый файл 00-private-nameservers.yaml в /etc/netplan:
sudo nano /etc/netplan/00-private-nameservers.yaml
В файл вставьте следующее содержимое. Вам нужно изменить интерфейс частной сети, адреса DNS-серверов ns1 и ns2 и зону DNS:
Примечание: Netplan использует формат сериализации данных YAML в своих файлах конфигурации.
Сохраните и закройте файл.
Затем сообщите Netplan, что новый файл конфигурации можно использовать с помощью netplan try. Если у вас возникают проблемы, которые вызывают потерю сети, Netplan автоматически откатит изменения после таймаута:
sudo netplan try
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
Если обратный отсчет внизу корректно обновляется, то новая конфигурация, по крайней мере, работает достаточно хорошо, чтобы не нарушить соединение SSH. Нажмите Enter, чтобы принять новую конфигурацию.
Теперь убедитесь, что системный DNS-резолвер применил новую конфигурацию:
sudo systemd-resolve --status
Прокрутите страницу вниз, пока не увидите раздел вашего сетевого интерфейса. Вы сначала должны увидеть внутренние IP-адреса ваших DNS-серверов, а затем некоторые резервные значения. Ваш домен должен находиться в DNS Domain.
Перезапуск BIND
Чтобы перезапустить BIND, введите:
sudo systemctl restart bind9
Если у вас настроен брандмауэр UFW, откройте доступ к BIND:
sudo ufw allow Bind9
Первичный DNS-сервер настроен и может обрабатывать запросы DNS. Теперь создадим вторичный сервер.
Заключение
Теперь вы умеете настраивать кэширующий и перенаправляющий DNS-сервер. Это поможет вам ускорить обработку DNS-запросов.
Важной частью управления конфигурацией и инфраструктурой сервера является поддержка простого поиска сетевых интерфейсов и IP-адресов по имени путем настройки правильной системы доменных имен (DNS, Domain Name System). Использование полных доменных имен (FQDN) вместо IP-адресов для определения сетевых адресов облегчает настройку сервисов и приложений и упрощает поддержку файлов конфигурации. Настройка собственного DNS-сервера для частной сети – отличный способ улучшить управление серверами.
Данный мануал поможет настроить в Ubuntu 18.04 внутренний DNS-сервер с помощью сервера имен BIND (BIND9), который может использоваться вашими серверами для разрешения внутренних имен хостов и IP-адресов. Это обеспечивает централизованный способ управления внутренними именами хостов и IP-адресами, что необходимо для среды, которая состоит из нескольких хостов.
Сохранение настроек клиента DNS
Параметры файла /etc/resolv.conf сбрасываются после перезапуска. Чтобы эти настройки использовались на постоянной основе, нужно отредактировать файлы, которые обращаются к этому файлу.
Откройте этот файл:
sudo nano /etc/network/interfaces
Найдите параметр dns-nameservers. Удалите текущую запись и замените ее данными о вашем DNS-сервере или просто добавьте новый DNS-сервер в качестве одного из значений.
. . .
iface eth0 inet static
address 111.111.111.111
netmask 255.255.255.0
gateway 111.111.0.1
dns-nameservers 192.0.2.1
. . .
Сохраните и закройте файл.
В системах CentOS и Fedora для этого нужно открыть файл /etc/sysconfig/network/network-scripts/ifcfg-eth0:
sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0
В нем найдите строки, которые начинаются с DNS. Среди них будет строка DNS1, в ней нужно указать ваш DNS-сервер. Если вы не хотите пользоваться другими DNS-серверами, удалите остальные записи.
Сохраните и закройте файл.
Заключение
Теперь вы можете ссылаться на внутренние сетевые интерфейсы своих серверов по имени, а не по IP-адресу. Это упрощает настройку сервисов и приложений, поскольку вам больше не нужно запоминать IP-адреса, и файлы станет легче читать и понимать.
После настройки внутреннего DNS важно обеспечить DNS-серверам хорошую поддержку. Если они оба станут недоступными, ваши сервисы и приложения, которые полагаются на них, перестанут функционировать должным образом. Вот почему рекомендуется использовать в настройке DNS как минимум один вторичный сервер и поддерживать рабочие резервные копии всех серверов.
С каждым годом скорость интернета — как последней мили, так и магистральных каналов становится все выше. Лишь одно неизменно — латентность уже уперлась в физические ограничения: скорость света в оптоволокне — около 200тыс километров в секунду, и соответственно, быстрее чем за ~150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).
Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…
Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.
Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.
pdnsd — кэширующий DNS proxy. Помимо банального кэширования DNS запросов (с возможностью жестко задавать минимальный TTL — может быть нужно на очень плохом интернете), он умеет отсылать запрос одновременно на несколько «родительских» DNS серверов, и отдавать клиенту первый вернувшийся ответ.
Именно включение параллельного опроса и дает нам основное преимущество в скорости, т.к. при нахождении результата в кеше любого из провайдеров мы получаем результат очень быстро, и не ждем полного и медленного разресолвивания если у первого провайдера нет ответа в кэше.
Ставится в Ubuntu — банальным apt-get.
3: Настройка перенаправляющего DNS-сервера
Если вашей инфраструктуре больше подходит перенаправляющий DNS-сервер, вы можете немного откорректировать настройку.
На данный момент файл named.conf.options выглядит так:
Можно использовать тот же список ACL, чтобы ограничивать DNS-сервер конкретным списком клиентов. Однако при этом необходимо немного изменить конфигурацию, чтобы сервер больше не пытался выполнять рекурсивные запросы.
Не меняйте значение recursion на no. Перенаправляющий сервер все-таки поддерживает рекурсивные сервисы. Чтобы настроить перенаправляющий сервер, нужно создать список кэширующих серверов, на которые он будет перенаправлять запросы.
Это делается в блоке options <>. Сначала нужно создать в нем новый блок forwarders, где будут храниться IP-адреса рекурсивных серверов имен, на которые нужно перенаправлять запросы. В данном случае это будут DNS-серверы Google (8.8.8.8 и 8.8.4.4):
Далее нужно в директиве forward установить значение only, поскольку сервер должен только перенаправлять все запросы и не пытаться разрешить их самостоятельно.
В результате конфигурация выглядит так:
Чтобы избежать их, нужно изменить значение параметра dnssec-validation на yes и явно разрешить dnssec.
Сохраните и закройте файл. Настройка перенаправляющего DNS-сервера завершена.
Создание файла зоны прямого просмотра
Создайте каталог, в котором будут находиться файлы зон. Согласно конфигурации named.conf.local, его расположение – /etc/bind/zones:
sudo mkdir /etc/bind/zones
В качестве основы для файла зоны прямого просмотра можно использовать файл зоны db.local. Скопируйте его в нужное место:
Откройте файл в редакторе:
Изначально он выглядит так:
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
Затем удалите три записи в конце файла (после записи SOA). В исходном файле выше они отмечены комментарием «delete this line».
В конце файла добавьте записи своего сервера имен (замените имена своими данными). Обратите внимание, что во втором столбце указано, что это записи NS.
Сохраните и закройте файл.
В результате файл зоны имеет такой вид:
Теперь пора заняться файлом (файлами) зоны обратного просмотра.
Файл options
На сервере ns1 откройте этот файл:
sudo nano /etc/bind/named.conf.options
Над существующим блоком options создайте новый блок управления доступом ACL (access control list) под названием trusted. Здесь можно определить список клиентов, которые могут отправлять рекурсивные DNS-запросы (например, ваши серверы, находящиеся в том же ЦОД, что и ns1). Добавьте ns1, ns2, host1 и host2 в список доверенных клиентов:
Теперь, когда у вас есть список доверенных DNS-клиентов, можно отредактировать блок options. В настоящее время начало блока выглядит следующим образом:
Под директивой directory добавьте выделенные строки конфигурации (и укажите соответствующий IP-адрес сервера ns1):
Теперь сохраните и закройте файл named.conf.options. В приведенной выше конфигурации указано, что только ваши доверенные серверы смогут запросить внешние домены у DNS-сервера.
Затем нужно настроить файл local, чтобы определить DNS-зоны.
5: Тестирование клиентов
Используйте nslookup, чтобы проверить, могут ли ваши клиенты запрашивать серверы имен. Вы должны иметь возможность сделать это на всех клиентах, которые вы настроили и которые находятся в доверенном ACL.
На клиентах CentOS может потребоваться установить утилиту с помощью команды:
sudo yum install bind-utils
Начнем с прямого просмотра.
Удаление хоста из DNS
Если вы удалите хост из своей среды или просто хотите удалить его из DNS, просто удалите все данные о нем, которые вы добавили при настройке поддержки DNS.
6: Поддержка DNS-записей
Итак, у вас есть рабочий внутренний DNS, и вам необходимо сохранить свои записи DNS, чтобы они точно отражали вашу серверную среду.
Требования
- Понимание базовых типов DNS-серверов. Ознакомиться с подробностями можно в этой статье.
- Две машины, из которых хотя бы одна работает на Ubuntu 14.04. Первая машина будет настроена как клиент (IP-адрес 192.0.2.100), а вторая – как DNS-сервер (192.0.2.1).
Вы научитесь настраивать клиентскую машину для отправки запросов через DNS-сервер.
1: Установка BIND на DNS-серверы
Примечание: Обратите внимание на текст, выделенный красным цветом. Он часто указывает, что необходимо заменить своими данными или добавить в файл конфигурации.
На серверах ns1 и ns2 обновите индекс пакетов:
sudo apt update
Затем установите BIND:
sudo apt install bind9 bind9utils bind9-doc
Клиенты Ubuntu 16.04 и Debian
На серверах Ubuntu 16.04 и Debian Linux вы можете отредактировать файл /etc/network/interfaces:
sudo nano /etc/network/interfaces
Сохраните и закройте файл.
Теперь перезапустите сетевые сервисы. Убедитесь, что вместо eth0 указали имя своего сетевого интерфейса:
sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0
Это должно перезапустить вашу сеть, не сбрасывая текущее соединение. Если все работает правильно, вы должны увидеть что-то вроде этого:
RTNETLINK answers: No such process
Waiting for DAD. Done
Повторно проверьте, применены ли новые параметры:
Вы увидите серверы имен в файле /etc/resolv.conf, а также ваш домен:
Настройка клиента завершена.
Клиенты Ubuntu 16.04 и Debian
На серверах Ubuntu 16.04 и Debian Linux вы можете отредактировать файл /etc/network/interfaces:
sudo nano /etc/network/interfaces
Сохраните и закройте файл.
Установите пакет resolvconf:
sudo apt update
sudo apt install resolvconf
Теперь перезапустите сетевые сервисы. Убедитесь, что вместо eth0 указали имя своего сетевого интерфейса:
sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0
Это должно перезапустить вашу сеть, не сбрасывая текущее соединение. Если все работает правильно, вы должны увидеть что-то вроде этого:
RTNETLINK answers: No such process
Waiting for DAD. Done
Повторно проверьте, применены ли новые параметры:
Вы увидите серверы имен в файле /etc/resolv.conf, а также ваш домен:
Настройка клиента завершена.
2: Настройка первичного DNS-сервера
Конфигурация BIND состоит из нескольких файлов, которые включены в основной файл конфигурации named.conf. Имена этих файлов начинаются с named, потому что это имя процесса, который запускает BIND. Начнем с настройки файла options.
Добавление хоста в DNS
Всякий раз, когда вы добавляете хост в свою среду (в том же центре данных), вам нужно добавить его и в DNS. Вот как это делается.
- Файл зоны прямого просмотра: добавьте запись «А» для нового хоста, увеличьте значение Serial.
- Файл зоны обратного просмотра: добавьте запись PTR для нового хоста, увеличьте значение Serial.
- Добавьте внутренний IP-адрес нового хоста в ACL trusted (named.conf.options).
- Протестируйте настройку:
5. Перезапустите BIND:
sudo systemctl reload bind9
Теперь ваш первичный сервер должен поддерживать новый хост.
- Добавьте внутренний IP нового хоста в ACL trusted (named.conf.options).
- Проверьте синтаксис:
3. Перезапустите BIND:
sudo systemctl reload bind9
Теперь ваш вторичный сервер должен поддерживать новый хост.
Чтобы настроить новый хост для поддержки DNS:
- Настройте поддержку в файле /etc/resolv.conf.
- Протестируйте работу хоста с помощью nslookup.
3: Настройка вторичного DNS-сервера
В большинстве сред рекомендуется создать вторичный DNS-сервер, который будет отвечать на запросы, если первичный сервер выйдет из строя. К счастью, вторичный DNS-сервер намного проще настроить.
На ns2 отредактируйте файл named.conf.options:
sudo nano /etc/bind/named.conf.options
В начале файла добавьте ACL с внутренними IP-адресами доверенных серверов.
Под директивой directory вставьте такие строки:
Сохраните и закройте файл named.conf.options. Этот файл должен выглядеть точно так же, как и файл named.conf.options сервера ns1, за исключением того, что он должен прослушивать внутренний IP-адрес ns2.
Теперь отредактируйте файл named.conf.local:
sudo nano /etc/bind/named.conf.local
Определите вторичные зоны, соответствующие зонам первичного DNS-сервера. Обратите внимание, что тип должен быть slave, файл не содержит пути, и в нем есть директива masters, которая должна указывать внутренний IP-адрес первичного DNS-сервера. Если вы определили несколько зон обратного просмотра на первичном DNS-сервере, обязательно укажите их все здесь.
Сохраните и закройте файл.
Чтобы проверить файлы на наличие ошибок, введите:
Если ошибок нет, перезапустите BIND:
sudo systemctl restart bind9
Разрешите подключения DNS, изменив правила брандмауэра UFW:
sudo ufw allow Bind9
Теперь у вас есть первичный и вторичный DNS-сервер. Пора настроить клиентские серверы.
Настройка файла local
На ns1 откройте файл named.conf.local:
sudo nano /etc/bind/named.conf.local
Добавьте зону прямого просмотра, заменив имя зоны и внутренний IP-адрес вторичного DNS-сервера в директиве allow-transfer:
Учитывая, что вы используете частную подсеть 10.128.0.0/16, добавьте зону обратного просмотра (обратите внимание, что имя этой зоны начинается с «128.10», обратно от «10.128»):
Если ваши серверы охватывают несколько частных подсетей, но находятся в одном и том же центре данных, обязательно укажите дополнительный файл зоны и зону для каждой отдельной подсети. Когда вы закончите добавлять все нужные зоны, сохраните и выйдите из файла named.conf.local.
Теперь, когда зоны указаны в BIND, необходимо создать соответствующие файлы зон прямого и обратного просмотра.
4: Настройка DNS-клиентов
Прежде чем все ваши серверы из ACL trusted смогут запрашивать DNS-серверы, нужно настроить каждый из них для использования ns1 и ns2 в качестве серверов имен. Этот процесс зависит от ОС, но в большинстве дистрибутивов Linux для этого нужно добавить серверы имен в файл /etc/resolv.conf.
Проверка синтаксиса конфигурации BIND
Запустите следующую команду, чтобы убедиться, что в файлах нет ошибок:
Команда named-checkzone может использоваться для проверки правильности ваших файлов зон. Ее первый аргумент указывает имя зоны, а второй – соответствующий файл зоны, которые определены в named.conf.local.
А чтобы проверить конфигурацию зоны обратного просмотра 128.10.in-addr.arpa, выполните следующую команду:
sudo named-checkzone 128.10 .in-addr.arpa /etc/bind/zones/db. 10.128
Проверив все конфигурационные файлы, вы можете перезапустить сервис BIND.
Читайте также: