Как настроить BIND9 вторичным DNS-сервером на Ubuntu 20.04
Антон Белов
4 мая 2021
Обновлено 8 августа 2022
Linux Ubuntu VPS
Вторичный (secondary) DNS-сервер необходим в качестве резервного. Если по какой-то причине перестанет работать первичный, вторичный обеспечит работоспособность сайта и других указанных в нем ресурсов.
Начальные настройки
- IP первичного DNS-сервера — 10.1.1.9
- IP вторичного DNS-сервера — 10.1.1.10
- Пример доменного имени — domain-name.com
Дополнительные настройки для первичного DNS-сервера BIND9
Если вы настраивали первичный DNS-сервер по нашей инструкции, можете пропустить этот шаг.
Мы должны разрешить первичному DNS-серверу передавать данные DNS-зоны вторичному серверу. Откройте файл конфигурации BIND9.
sudo nano /etc/bind/db.
domain-name.com
Добавьте в настройки зоны 2 параметра: allow-transfer и also-notify, подставив в них IP-адрес вторичного сервера. Результат будет примерно таким.
zone "domain-name.com" {
type master;
file "/etc/bind/db.domain-name.com";
allow-transfer { 10.1.1.10; };
also-notify { 10.1.1.10; };
};
Сохраните файл и перезагрузите BIND9.
sudo systemctl reload bind9
Настройка BIND9 в качестве вторичного DNS-сервера
Откройте файл настройки BIND9.
sudo nano /etc/bind/named.conf.local
Добавьте к нему следующую директиву.
zone "domain-name.com" {
type slave;
file "db.domain-name.com";
masters { 10.1.1.9; };
};
Параметр masters должен содержать IP-адрес первичного DNS-сервера. Сохраните файл и перезагрузите BIND9.
sudo systemctl reload bind9
Чтобы проверить, правильно ли работает вторичный DNS-сервер, используйте команду на любом удаленном компьютере.
nslookup domain-name.com 10.1.1.10
Используйте свое полное доменное имя вместо domain-name.com и IP-адрес вашего вторичного DNS-сервера вместо 10.1.1.10.
Результат:
Server: 10.1.1.10
Address: 10.1.1.10#53Name: domain-name.com
Address: 10.1.1.10
Оценка:
Аverage rating : 3.5
Оценок: 2
191028 Санкт-Петербург Литейный пр., д. 26, Лит. А
+7 (812) 403-06-99
700 300
ООО «ИТГЛОБАЛКОМ ЛАБС»
191028
Санкт-Петербург
Литейный пр.
, д. 26, Лит. А
+7 (812) 403-06-99
ООО «ИТГЛОБАЛКОМ ЛАБС»
700 300
зачем это нужно и как настроить сеть
Единственное неудобство в том, что вам приходится создавать и удалять каждую зону на обоих серверах, так как это автоматически не происходит. Вот почему вы создаёте доменную зону на master сервере и потом создаёте эту же доменную зону на slave сервере и указываете адрес master сервера. После того, как вы добавили ресурсные записи домена на master сервер, можете быть уверены, что slave сервер будет автоматически получать их от master сервера.
На протяжении многих лет интеграция Plesk и slave DNS сервера была непростой задачей. Подразумевается, что сервер Plesk должен быть master сервером. В Plesk есть режимы slave и master для доменной зоны и есть список ip адресов , которые отдаются доменной зоной .
Но в плеск нет механизма создания новой доменной зоны на slave сервере. И этого механизма никогда не будет, потому что концепция плеск — это автоматизация хостинговых процедур на одном сервере. Для интеграции нескольких серверов разделённых для работы по видам сервисов, компания Parallels предлагает использовать продукты PPA (Parallels Plesk Automation) и PA (Parallels Automation).
На данный момент существует множество пользователей Plesk для которых решения PPA или РА превосходят их необходимые потребности для работы, так как им необходима только интеграция slave сервера. Ранее для решения этой проблемы каждый администратор Plesk должен был писать скрипты или приобретать коммерческие версии или вручную создавать и удалять доменные зоны на slave сервере.
Казалось бы, какие могут быть трудности. В Plesk есть собственный локальный сервер имён, который, предположим, будет master сервер. И есть система событий — давайте назначим исполнение нашего скрипта на события «создание DNS зоны» и «удаление DNS зоны» и проблема будет решена.
Но, к сожалению, Plesk не поддерживает такие события.
Программисты Plesk не только разрабатывают одноименный продукт, но и пользуются своими разработками. Вот почему создали расширение, которое позволяет пользователям интегрировать Plesk с внешним slave сервером с установленным BIND9 . Скачать это расширение можно здесь
КАК ЭТО РАБОТАЕТ
Plesk использует BIND как локальный сервер имён. Им можно управлять удалённо с помощью штатной утилиты rndc . Нет причин, по которым мы не можем установить BIND на удалённом сервере и управлять им с помощью rndc. В Plesk 12.5 реализован механизм “Custom DNS backend”, который может быть использован для подключения внешнего DNS сервиса, например AWS Route53.
Если вкратце, то этот способ позволяет зарегистрировать в Plesk скрипт, который будет получать описание DNS зоны в JSON формате с инструкциями для исполнения, такими как создание, изменение, удаление любой DNS зоны в Plesk. Это то, что нам нужно. Реализовывая этот функционал, Plesk подразумевали, что будет использоваться внешний DNS сервис вместо того, чтобы устанавливать BIND сервер в Plesk.
Также нет нужды удалять локальный сервер BIND . Этот скрипт может одновременно работать с локальной DNS службой. Такова идея использования данного расширения.
- Регистрируется slave сервер в своих настройках скрипта
- IP адрес slave сервер автоматически добавляется в список адресов разрешённых для трансфера доменных зон из сервера Plesk
- Когда вы создаёте, меняете или удаляете активную зону домена в Plesk , то эти действия происходят на локальном DNS сервере
- После этого скрипт запускается , получает доменное имя и выполняет соответствующую операцию
- Скрипт инициирует команду rndc для каждого подключённого slave сервера
- Slave серверы синхроинизируют доменные зоны с сервером Plesk.
Все настройки, такие как формат зоновых файлов, подключение и перезапуск служб управляются службой DNS. Администратор должен настроить slave сервер для работы с внешним сервером Plesk только один раз.
После этого вы можете сообщить регистратору, что теперь Plesk сервер и slave сервер являются серверами имён для ваших доменов. Таким образом мы решили все вопросы обозначенные в начале статьи.
А ТЕПЕРЬ О ТЕХНИЧЕСКОЙ СТОРОНЕ — КАК РЕШИТЬ ЗАДАЧУ
Для установки slave сервера возьмём, к примеру, сервер с Centos 7
В начале проверим что система имеет все последние обновления.
yum update -y
Если не указать «-y» ключ, то придется отвечать на все вопросы установщика, а с ним все ответы ставятся автоматически по умолчанию.
Установить bind и bind-utils
yum install bind bind-utils -y
Разрешим создание новых зон с помощью rndc. В файле /etc/named.conf, в фигурных скобках {}, напишите директиву:
allow-new-zones yes;
Укажите ip адрес от которого должны быть приняты инструкции управления и установите BIND для прослушивания на всех доступных сетевых интерфейсах. Определите ключ rndc , который будет использоваться Plesk .
В файле /etc/named.conf напишите:
key «plesk-key» {
algorithm hmac-md5;
secret «vwOxonI4n4CVRUhKAOAAIA==»;
};
controls {
inet * port 953 allow { ; ; 127.0.0.1; } keys {«rndc-key», «plesk-key»; };
};
Вот и всё, slave сервер установлен.
После этого установите расширение на сервере Plesk . В настройках расширения добавьте slave сервер, установите его ip адрес и ключ . Расширение создаст конфигурационный файл с настройками slave севрера для утилиты rndc.
Теперь Plesk будет автоматически передавать все созданные изменённые и удалённые зоны на slave сервер при выполнении следующей команды для каждого slave сервера:
# Создание
/usr/sbin/rndc -c slave.config addzone example.com ‘{ type slave; file «example.com»; masters { ; }; };’
# Изменение
/usr/sbin/rndc -c slave.config refresh example.com
# Удаление
/usr/sbin/rndc -c slave.config delzone example.com
Сейчас , когда вы добавили домен в Plesk, его ДНС зона автоматически создалась на slave сервер аналогично как на master сервере.
Расширение (Slave DNS manager) доступно для загрузки здесь
Обращаем внимание, что Plesk не пр оводит техподдержку для для данного расширения . Это расширение лишь пример как можно решить техническую задачу.
Перевод: Сергей Гордеев (Русоникс)
Оригинал
Что такое вторичный DNS?
Мы видим изрядную путаницу в отношении вторичного DNS — отчасти потому, что это перегруженный термин. Многие регистраторы запрашивают у вас «первичный» и «вторичный» серверы имен для вашего домена, но на самом деле это не то, что касается вторичного DNS.
Вместо этого вы можете думать о вторичном DNS как таковом: это способ для DNS-сервера или службы извлекать DNS-записи с другого DNS-сервера и поддерживать их в актуальном состоянии, используя сам протокол DNS.
Первичный и вторичный DNS
Чтобы понять вторичный DNS, нам необходимо иметь четкое представление об определениях RFC для настройки первичного/вторичного DNS-сервера. Настройка первичного/дополнительного DNS-сервера (RFC 1996) включает один первичный DNS-сервер и один или несколько вторичных DNS-серверов.
Первичный DNS-сервер — это любой полномочный сервер, настроенный как источник передачи зоны для одного или нескольких вторичных серверов. Существуют и другие типы первичных/вторичных конфигураций DNS, но для ясного объяснения вторичного DNS мы будем использовать простые примеры конфигурации.
При настройке основного/дополнительного DNS-сервера вторичный сервер создается у второго поставщика DNS для обеспечения избыточности в сети DNS.
Первичный DNS-сервер — это полномочный сервер, для которого информация о зоне настраивается локально (RFC 2182), обычно через интерфейс провайдера или API. В сети первичного DNS-сервера могут быть как первичные, так и вторичные серверы.
Дополнительный DNS-сервер — это авторитетный сервер, который получает информацию о зоне от основного сервера посредством передачи зоны. (RFC 2182) Таким образом, вторичный DNS-сервер привязан к первичному серверу.
Причины использования вторичного DNS
В прошлом вторичный DNS использовался главным образом для привязки вашего резервного сервера имен к основному.
Однако в современном Интернете все еще используются вторичные DNS. У некоторых клиентов есть инструменты, код или другие зависимости от существующего DNS-сервера или службы, но они хотят использовать высокопроизводительную и надежную платформу для доставки DNS. Например, у вас могут быть сценарии, которые автоматизируют создание новых DNS-записей в файлах зон BIND на внутреннем DNS-сервере, но вы не хотите запускать собственную DNS-сеть с произвольным вещанием, гарантированную SLA. Вы можете продолжить использовать существующую настройку DNS в качестве уровня управления и настроить вторичный DNS с помощью надежного поставщика с произвольной адресацией и гарантией SLA.
Другие заказчики предъявляют строгие требования к единым точкам отказа. Некоторые организации, особенно сайты с высокой посещаемостью, которые могут сильно пострадать от любого сбоя, придают большое значение идее о том, что ни одна система или служба не должны нести ответственность за какой-либо критический этап пути доставки, включая DNS. Эти клиенты могут использовать двух или более поставщиков управляемых DNS и настраивать серверы имен обоих для своих доменов.
Вместо того, чтобы вносить изменения в записи в системах обоих провайдеров, общий подход заключается в настройке одного из провайдеров в качестве основного, а другого в качестве вторичного, подчиненного основному провайдеру. Затем все управление осуществляется в первичном провайдере, но для доставки используются как первичный, так и вторичный.
Для получения дополнительной информации об использовании вторичного DNS или о других решениях DNS см. эту статью о настройке вторичных зон NS1 или посетите нашу страницу решений выделенного DNS.
Что такое резервный DNS-сервер?
Вторичная служба DNS предоставляет вам дополнительный набор авторитетных серверов имен для ответа на запросы для вашего домена. Информация, хранящаяся на обоих серверах имен, идентична. Вторичный DNS позволяет автоматически создавать резервную копию файла доменной зоны и хранить его как копию на вторичном сервере. Если один провайдер недоступен, другой будет систематически вмешиваться, чтобы ответить на запросы.
Поскольку распознаватели изучают шаблоны скорости серверов, они также могут предпочесть более быстрый ресурс в качестве начальной точки контакта для входящих запросов.
Как работает избыточный/вторичный DNS?
Наличие вторичного DNS очень похоже на установку пункта назначения в картографическом приложении на мобильном телефоне и позволяет ему вести вас. Если есть два способа попасть в одно и то же место, он проведет вас по пути «наименьшего сопротивления» — тому, который не только приведет вас туда, но и выберет более быстрый маршрут. Вторичный DNS — это критически важная конфигурация, которая обеспечивает дополнительная избыточность для вашего домена, так как вы можете установить поддерживающий набор автоматически обновляемых файлов зон.Это важно для обхода сбоев службы DNS, неправильных конфигураций, стихийных бедствий и целевых атак, таких как попытки распределенного отказа в обслуживании (DDoS).
Кому нужен резервный DNS?
Любой веб-сайт, приносящий доход, будь то услуги по подписке или за счет продаж, был бы идеальным кандидатом для вторичного DNS.
Наличие дополнительного набора серверов имен позволяет направлять трафик либо на первичный, либо на вторичный DNS-сервер, помогая увеличить время безотказной работы вашего домена. Без «резервной копии» ваш веб-сайт будет полностью недоступен в случае сбоя, а это может стоить вам и вашим клиентам денег. Что делать, если ваш веб-сайт не приносит прямого дохода, но все же помогает в продажах? Применяются те же потери. Например, если вы размещаете веб-сайт для риелторов или агентств по управлению недвижимостью, потенциальные клиенты не могут просматривать списки, когда они находятся на рынке, чтобы купить или арендовать дом. Это потеря вокруг, которую вы не хотели бы испытать.
Однако наличие только основного DNS-сервера для домена, не приносящего дохода, также может нанести ущерб как компаниям, так и клиентам. Если сервер недоступен, соответствующая информация недоступна. Для веб-сайтов, таких как новостные агентства, информация о возможных чрезвычайных ситуациях не может быть получена общественностью.
Знаете ли вы? Некоторые популярные медицинские организации, занимающиеся предоставлением медицинской информации, ресурсов и продуктов для спасения жизни, таких как COVID-19вакцинация, полагаться только на одного провайдера DNS?
Некоторым регистраторам доменов может потребоваться вторичный DNS, однако в настоящее время в отрасли рекомендуется настраивать второго поставщика услуг (SP). Это лучший подход по причине.
Как проверить свои серверы имен DNS
Существует несколько онлайн-инструментов для проверки учетных данных вашего домена, включая серверы имен DNS.
- Поиск Whois от Constellix
- Who.is
- MX Lookup
Серверы имен DNS, которые применяются к домену, будут отображаться на странице результатов поиска используемого вами инструмента поиска. Вот пример того, что вы увидите при использовании Whois Lookup. DNS-серверы имен показаны в нижней части экрана.