Данные для slave домена до сих пор не загружены с dns мастера
Посмотрев недавно статью, был сильно удивлен, что кто-то еще задается вопросом автоматического прописывания ДНС доменов на вторичном сервере. Хочу поделится своим вариантом «Automate slave DNS support», которым пользуюсь уже много лет. Возможно он подойдет не всем, но он довольно прост.
В качестве вторичного использую PowerDNS, мастером использую Bind, хотя подойдет любой другой сервер умеющий DNS NOTIFY при изменении/создании зоны (присматриваюсь к YADIFA, но руки пока не дошли). Именно эту фичу мы и будем использовать чтобы создавать и изменять зоны на вторичном сервере, минус будет только в том при удалении зоны на слейве, ее нужно удалить вручную. В логах удаленные зоны хорошо видны и при необходимости можно навоять скриптик для автоматизации процесса, у меня зоны удаляются довольно редко, поэтому такой необходимости не было.
Наверное если Вы заинтересовались этой статьей, то имеете представление о том, как настроить мастер или при желании самостоятельно найдете материал по настройке. В случаи Bind хочу обратить внимание, что в конфиге обязательная должна быть прописана опция:
Приступим к установке и настройки Pdns. На серверах у меня Debian:
Такой вариант автоматом подтянет pdns-server, sqlite3, а так же все что необходимо для запуска PowerDNS сервер с Sqlite v3, который используется хранения днс записей. Sqlite3 выбран так как не требует для себя много внимания, но ничто не мешает Вам выбрать другой вариант.
Итак у нас есть установленный PowerDNS сервер с базой Sqlite3 в дистрибутивах отличных от Debian возможно придется вручную настроить базу. К сожалению в пакете ошибка и чтобы сервер увидел базу нужно закомментировать одну строчку.
В файле /etc/powerdns/pdns.d/pdns.simplebind нужно удалить или закомментировать строчку bind-config=/etc/powerdns/bindbackend.conf
Так же в конфиге нужно объявить сервер как вторичный:
/etc/powerdns/pdns.conf
Теперь нам можно прописать Master DNS в Sqlite базу:
На этом настройка завершена, но это еще не все, теперь надо загрузить в sqlite базу, есть два способа это сделать.
Самый простой на мой взгляд это обновление Serial на мастере, чтобы он отправил слейву DNS NOTIFY и тем самым оповестил его о наших доменах, заставив его завести и забрать их.
На местере это выглядит так:
Альтернативой могу предложить завести домены напрямую в sqlite:
Где 0 это сериал зоны, на мастере он явно будет больше и поэтому произойдет обновление.
Надеюсь теперь вопрос автоматического создания доменов на вторичном сервере больше не будет Вас беспокоить.
Бинд пишет, что не может писать в директорию. Он у Вас случайно не чрутится? Тогда путь к директории надо считать относительно чрута.
ну и директорию data заодно
все права уже дал (( всё тоже самое приходит в логах уже ничего не пишет вообще
Попробуйте запустит bind руками, что то типа
named -g -u named -c /etc/bind/named.conf
возможно станет понятней в чем дело
P.S. и заодно стоит почистить /var/named на слейве
Видимо, это raw-формат, в котором BIND 9.9 по умолчанию хранит slave-зоны. Попробуйте почитайть этот файл с помощью «named-compilezone».
а как им открывать?
да, и если будешь в настройках указывать «masterfile-format text;», то удали старые файлы зон чтобы в plain text новые появились
а указывать надо на slave опцию masterfile-format text?
всё добавил опцию masterfile-format text и всё заработало =) ух парни всем спасибо особенно mky и shrub =)
named-compilezone -j -f raw -F text -o /tmp/ИМЯ_ФАЙЛА test /var/named/test
test — это зона (имя), а /var/named/test — файл, где она лежит. Резльтат будет записан в файл /tmp/ИМЯ_ФАЙЛА.
Правильно ли я понял, что отличие в настройках master и slave bind DNS-сервера выражаются только в файле /var/named/chroot/var/named/named.zones?
В slave-овском DNS-сервере этот файл такой:
zone "mydomain.ru" IN <
type slave;
masters < xxx.xxx.xx.xx; >;
file "mydomain.ru.zone";
>;
zone "xx.xxx.xxx.in-addr.arpa" IN <
type slave;
masters < xxx.xxx.xx.xx; >;
file "xx.xxx.xxx.in-addr.arpa.zone";
>;
Где xxx.xxx.xx.xx - IP-ник master-a.
В master-ском DNS-сервере этот файл такой:
zone "mydomain.ru" IN <
type master;
file "mydomain.ru.zone";
>;
zone "xx.xxx.xxx.in-addr.arpa" IN <
type master;
file "xx.xxx.xxx.in-addr.arpa.zone";
>;
И может ли неработоспособность DNS связана с тем, что айпишник master-a и slave принадлежат одной и той же подсети класса C?
ну есть еще такой процесс, как передача зоны мастера слейву.. с ними разобрался?
и в чем кстати выражается неработоспособность dns? логи имеются?
>айпишник master-a и slave принадлежат одной и той же подсети класса C?
Принадлежность ip-адресов разным сетям класса C требется только при регистрации домена. То есть это требование регистраторов, а не протокола DNS.
У master должен быть разрешен трансфер зоны для slave сервера и между серверами должен быть окрыт 53-tcp порт.
> и в чем кстати выражается неработоспособность dns? логи имеются?
Неработоспособность dns выражается в том, что после того, как у регистратора были прописаны настраиваемые dns-серверы, он стал недоступен в браузере уже в течении нескольких недель.
> ну есть еще такой процесс, как передача зоны мастера слейву.. с ними разобрался?
> У master должен быть разрешен трансфер зоны для slave сервера и между серверами должен быть окрыт 53-tcp порт.
53-tcp порт открыт.
Правильно я понял, что для трансфер зоны мастера слейву достаточно прописать в мастерском файле /var/named/chroot/etc/named.conf (и/или в файле /etc/named.conf ) строчку: allow-transfer < Айпишник_слейва ; >; ?
Нужно ли, чтобы rndc.key совпадал для мастера и слейва?
> 53-tcp порт открыт.
Должен быть открыт также UDP (причём, даже в первую очередь).
> Правильно я понял, что для трансфер зоны мастера слейву достаточно прописать в мастерском файле /var/named/chroot/etc/named.conf (и/или в файле /etc/named.conf ) строчку: allow-transfer < Айпишник_слейва ; >; ?
Да. allow-transfer можно также указывать в описании зоны.
> Нужно ли, чтобы rndc.key совпадал для мастера и слейва?
>Неработоспособность dns выражается в том, что после того, как у регистратора были прописаны настраиваемые dns-серверы
>Принадлежность ip-адресов разным сетям класса C требется только при регистрации домена. То есть это требование регистраторов, а не протокола DNS.
тебя для начала просто пошлют со слейвом в це-сетке, как не настраивай..
Трансфер зоны сделал. А есть ли специальные команды bind, которые позволяют проверять работоспсобность DNS-серверов мастер и слейв, вместо того, что бы ждать каждый раз 2 суток и проверять в браузере домен, который использует эти ДНСы?
В предыдущем посте мы рассказали, как настроить первичный DNS-сервер с помощью BIND9 . Мы будем изучать, как настроить вторичный DNS-сервер. Подчиненный DNS-сервер получает копию данных с основного DNS-сервера с использованием метода зонной передачи. Этот метод сохраняет данные зоны в кэше в течение определенного времени и использует их для обслуживания DNS-запросов.
В нашей настройке у нас есть первичный DNS-сервер с IP-адресом 172.16.10.2 и доменным именем ns1.infoit.local .
Мы настраиваем вторичный сервер с 172.16.10.10 и ns2.infoit.local .
Конфигурация slave name сервера
Конфигурирование slave name сервера проходит так же как и master за исключением двух моментов:
- При редактировании файла конфигурации named.conf надо указать какие доменные зоны slave
- Не надо добавлять доменные зоны, так как они обновятся с master сервера автоматически
Не забываем стартовать сервер и включить его в автоматический старт при запуске системы.
Теперь у нас есть два сконфигуренных name сервера.
Осталось открыть порт в firewall
Отредактируем файл /etc/sysconfig/iptables:
Добавим следующие правила для 53 порта.
Не забудьте обновить этот файл на обоих серверах.
Теперь у нас есть два работающих name сервера.
Вывод
Вы успешно настроили подчиненный DNS-сервер в Ubuntu 20.04 с помощью BIND9. Поделитесь своим мнением в комментариях.
Настройте подчиненный DNS
Установите необходимые пакеты:
Отредактируйте файл в /etc/bind/ named.conf.local и добавьте параметры прямой и обратной зоны:
Перезапустите службу DNS:
Конфигурация на Bind Master DNS
Для настройки Master-Slave нам необходимо настроить главный DNS-сервер и включить передачу зоны на вторичный сервер имен.
Мы будем редактировать /etc/named.conf.local файл на первичном сервере (ns1.infoit.local) и добавить allow-transfer и also-notify параметры.
Это будет сделано как для прямого, так и для обратного ввода.
allow-transfer Параметр позволяет передавать файлы зоны от ведущего к ведомому DNS в то время как also-notify помогает предупредить подчиненный , когда есть обновление файлов зона от мастера.
Мы должны перезапустить службу DNS на ns1.infoit.local:
Leave a Reply Отменить ответ
Тестовый ведомый DNS
Чтобы проверить, была ли передача зоны успешной и DNS работает на подчиненном сервере, нам нужно настроить клиентский хост и использовать подчиненный сервер в качестве своего DNS-сервера.
Затем мы можем использовать dig команду для проверки DNS.
езультат показывает, что подчиненный DNS может обрабатывать запросы. Это подразумевает, что настройка DNS «главный-подчиненный» работает должным образом.
Конфигурирование доменных зон
В файле конфигурации мы указали файл sibway.pro.zone как файл конфигурации доменой зоны sibway.pro.
Проще всего взять какой-либо существующий и отредактировать до нужной конфигурации. Файлы можно разместить в поддиректории.
Вот простой пример того что необходимо прописать в доменной зоне.
Делаем рестар name сервера
Определяем чтобы name сервер стартовал при загрузки системы.
Теперь проверим как работает наш name сервер.
В ответе должен быть указан правильный IP запрошенного домена. Теперь сконфигурируем slave сервер.
СПОНСОР
Мы используем файлы cookie на нашем веб-сайте, чтобы предоставить вам наиболее релевантный опыт, запоминая ваши предпочтения и повторные посещения. Нажимая «Принять все», вы соглашаетесь на использование ВСЕХ файлов cookie. Однако вы можете посетить «Настройки файлов cookie», чтобы предоставить контролируемое согласие.
Privacy Overview
Этот веб-сайт использует файлы cookie, чтобы улучшить вашу работу во время навигации по веб-сайту. Из них файлы cookie, которые классифицируются как необходимые, хранятся в вашем браузере, поскольку они необходимы для работы основных функций веб-сайта. Мы также используем сторонние файлы cookie, которые помогают нам анализировать и понимать, как вы используете этот веб-сайт. Эти файлы cookie будут храниться в вашем браузере только с вашего согласия. У вас также есть возможность отказаться от этих файлов cookie. Но отказ от некоторых из этих файлов cookie может повлиять на ваш опыт просмотра.
За все время работы не сталкивался с установкой DNS на сервер, а тут пришлось устанавливать Slave DNS на новом сервере клиента. Думаю, что порядок действий будет полезен, как админам так и web-разработчикам.
Заходим на сервер (для примера Master DNS будет ставиться на сервер с IP 10.10.10.10, Slave DNS — IP 20.20.20.20)
В начале проверим что система имеет все последние обновления.
Если не указать "-y" ключ, то придется отвечать на все вопросы установщика, а с ним все ответы ставятся автоматически по умолчанию.
Установить bind и bind-utils.
На примере моего домена «sibway.pro», для своего поменяйте все вхождения в примерах. Будем считать что master имеет IP 10.10.10.10, slave 20.20.20.20. Master и slave насколько я понимаю деление условное, так как и тот и другой сервер будет выполнять одни и те же функции, различие только в том что slave берет все данные с мастера.
Теперь отредактируем конфигурационный файл любым текстовым редактором, я использую vi так как он есть всегда в любой системе.
При установке bind, файл конфигурации ставится автоматически и нам надо только его отредактировать.
Комментируем строку, чтобы сервер мог слушать эфир со всех адресов и портов (наверное можно указать просто IP 10.10.10.10, но руки не дошли поэкспериментировать. Извне все равно все закрывает firewall).
Позволяем запрашивать сервер с любого адреса.
Позволяем брать информацию о доменах slave серверам.
Добавляем доменную зону, в тот же конфигурационный файл прописываем.
Читайте также: