RuWeb.net Forum

для чего нужны ns51.ruweb.net и ns52.ruweb.net либо ns53.ruweb.net и ns54.ruweb.net
timru - 22.6.2014 в 14:06

После создания VDS пользователю высылаются данные для доступа. В частности, там есть такое:

dnsmgr1='https://dnsmgr1.deserv.net/manager/dnsmgr'
dnsmgr2='https://dnsmgr2.deserv.net/manager/dnsmgr'
user=k185.11.xxx.xx pass=xxxxxxxx
nameservers='ns52.ruweb.net. ns51.ruweb.net.'

либо такое
dnsmgr1='https://dnsmgr3.deserv.net/manager/dnsmgr'
dnsmgr2='https://dnsmgr4.deserv.net/manager/dnsmgr'
user=k185.11.xxx.xx pass=xxxxxxxx
nameservers='ns53.ruweb.net. ns54.ruweb.net.'

Это вторичные NS-сервера.

Далее инструкция дана на примере с DNS ns52.ruweb.net и ns51.ruweb.net.

С ns53.ruweb.net и ns54.ruweb.net действовать нужно аналогично используя данные из письма.

Если у вас шаблон с предустановленной панелью ISPmanager-5 или VestaCP, то доступ к этим вторичным NS-серверам уже настроен в панели управления. То есть когда в панели управления вы создаете какой-либо домен (например vasya-pupkin.ru), зона автоматически прописывается на этих NS-серверах. Вы можете проделегировать домен vasya-pupkin.ru на них, указав в панели регистратора:
ns51.ruweb.net
ns52.ruweb.net
и все будет работать.

Если же у вас шаблон без предустановленной панели , первичный NS-сервер на VDS по-умолчанию не настроен. Сами по себе вторичные NS-сервера работать не будут, они могут только обновлять зону с первичного NS-сервера. Поэтому если вы хотите их использовать, необходимо будет настроить первичный NS на VDS самостоятельно. (Либо использовать сторонний первичный NS, или даже полностью сторонний DNS-хостинг .)
На первичном DNS обязательно разрешите трансфер зон на вторичные
dig имя_домена.ru @ip_сервера axfr


[Отредактировано 10.9.2016 кто cosupport]

[Отредактировано 15.2.2023 кто kpv]

support - 3.11.2016 в 15:01

Если вы НЕ используете ISPmanager, то для синхронизации локального BIND с DNSManager можно использовать скрипт dnsmgrupdate
(В шаблонах с VestaCP он уже настроен, ничего делать не нужно)

Качаем скрипт:
curl -ku: https://:@svn.deserv.net/dnsmgrupdate/dnsmgrupdate
(Логин и пароль для скачивания - пустые!)
Кладем его по пути: /root/dnsmgr/dnsmgrupdate
Даем права на выполнение: chmod +x /root/dnsmgr/dnsmgrupdate
И создаем конфиг: /root/dnsmgr/dnsmgrupdate.conf

В конфиге описываем параметры вида:
NAMEDPATH=/etc/namedb
MASTERIP=11.22.33.44
DNSMGRURL=https://dnsmgr1.server.net/manager/dnsmgr?out=text&authinfo=user:pass
DNSMGRURL=https://dnsmgr2.server.net/manager/dnsmgr?out=text&authinfo=user:pass
CHANGESONLY=yes
CHECKMASTER=yes

основные настройки:
NAMEDPATH - путь либо к директории в которой создаются файлы зон (обычно /etc/namedb), либо к конфигу, в котором прописываются файлы зон (файлы зон должны иметь расширение .db)
MASTERIP - ip-адрес вашего сервера (с него будут забираться зоны)
DNSMGRURL - URL dnsmgr-а с юзером и паролем (url-ов может быть больше, чем один)
CHANGESONLY - Выводить только изменения
CHECKMASTER - Игнорировать зоны с другим MASTERIP

запускаем скрипт и проверяем, что он отрабатывает, далее в cron ставим задание:
* * * * * [ ЗНАЧЕНИЕ_ИЗ_NAMEDPATH -ot /tmp/dnsmgrupdate.stamp ] || (date; touch /tmp/dnsmgrupdate.stamp; /root/dnsmgr/dnsmgrupdate) >>/var/log/dnsmgrupdate

Смысл работы следующий: команда выполняется каждую минуту, если с момента предыдущего запуска изменился список доменов на локальном сервере, запускается скрипт, который получает зоны со всех slave-серверов, сверяет с локальным списком и синхронизирует их на slave-серверах. Локальный список доменов получается путем сканирования NAMEDPATH. (После передачи списка доменов на slave-сервера, slave-ы начинают делать запросы на MASTERIP для получения и синхронизации зон.)

Также в опциях BIND (в секции options обычно в named.conf) следует добавить:


Код:

notify explicit;
also-notify { 178.208.66.16; 178.208.66.50; 178.57.218.222; 91.218.229.124; 185.12.92.10; 185.12.92.10; 185.11.246.250; };
allow-transfer { 178.208.66.16; 178.208.66.50; 178.57.218.222; 91.218.229.124; 185.12.92.10; 185.12.92.10; 185.11.246.250; };

где 178.208.66.50 и 185.12.92.10 - IP-адреса вторичных ДНС-серверов.

PS: В CentOS для работы скрипта потребуется доустановить perl-LWP-Protocol-https:
Код:
yum install perl-LWP-Protocol-https



[Отредактировано 25.3.2020 кто support]

[Отредактировано 27.4.2023 кто kpv]

[Отредактировано 27.4.2023 кто kpv]

teleoperator27 - 8.2.2018 в 15:11

Извините меня тупого, но я не совсем понял. у меня домен зарегистрирован у другого регистратора. У него мне что писать, ns52.ruweb.net. и ns51.ruweb.net. и все? или у меня в панели управления вторичными ДНС надо еще что то прописывать?

kpv - 8.2.2018 в 15:41

техподдержка у нас http://ruweb.net/support - там пишите вопрос по тому что надо и где сделать. На форуме у нас только обсуждение инструкций. По конкретным техническим вопросам - в тикетовку.
Где регистрировали домен и у какого регистратора не имеет никакого значения.

teleoperator27 - 8.2.2018 в 15:46

Ясно, понял

Piercer - 1.7.2020 в 23:23

Цитата:

Также в опциях BIND (в секции options обычно в named.conf) следует добавить:
Код:

notify explicit;
also-notify { 74.119.194.67; 185.12.92.10; };
allow-transfer { 74.119.194.67; 185.12.92.10; };


у меня bind9 debian 10 не стартует с этими настройками. пишет ошибка.


Цитата:

июл 02 05:01:04 xxx named[20235]: /etc/bind/named.conf:9: unknown option 'notify'
июл 02 05:01:04 xxx named[20235]: /etc/bind/named.conf:10: unknown option 'also-notify'
июл 02 05:01:04 xxx named[20235]: /etc/bind/named.conf:11: unknown option 'allow-transfer'


Вылечил таким образом. В /etc/bind/named.conf.options закомментировал

Цитата:

//auth-nxdomain no;
allow-recursion { 127.0.0.1; ::1; };
//allow-transfer {"none";};
//hostname none;
//server-id none;
//version none;


[Отредактировано 2.7.2020 кто Piercer]

kpv - 2.7.2020 в 09:27

В дебиан раздел options находится в файле /etc/bind/named.conf.options

Piercer - 2.7.2020 в 13:59

Цитата:

options {
directory "/var/cache/bind";
auth-nxdomain no;
allow-recursion { 127.0.0.1; ::1; };
notify explicit;
also-notify { 74.119.194.67; 185.12.92.10; };
allow-transfer { 74.119.194.67; 185.12.92.10; };
};


вот мой конфиг. все выполнено по инструкции выше. скрипт создан и отдает ответ

Цитата:

root@xx:~/dnsmgr# ./dnsmgrupdate

=== dnsmgr1.deserv.net changes:

=== dnsmgr2.deserv.net changes:
=== done


но в разделе https://dnsmgr1.deserv.net/manager/dnsmgr пусто, не появляются домены, созданные через панель.

Вы уверены, что адрес
DNSMGRURL=https://dnsmgr1.server.net/manager/dnsmgr?out=text&authinfo=user:pass правильный? Может быть он должен выглядеть как https://dnsmgr1.deserv.net/manager/dnsmgr?out=text&authinfo=user:pass

ибо домена https://dnsmgr1.server.net вроде как не существует.


[Отредактировано 2.7.2020 кто Piercer]

kpv - 3.7.2020 в 09:39

Адрес надо брать не шаблонный, а тот, который указан в письме с данными сервера.

Piercer - 3.7.2020 в 10:05

Про адрес я догадался. Перечитал мануал про первичные и вторичные ns и теперь понятно, почему при установке сторонней панели управления на голый хостинг изначально нужно устраивать пляски вокруг управления вторичными DNS серверами. Очень мудреный мануал у вас на форуме. Пошагово хотелось бы знать 1.2.3.4. для Debian 10 + сторонняя панель с Bind. Спасибо.

[Отредактировано 3.7.2020 кто Piercer]

Piercer - 4.7.2020 в 10:26

Я так понимаю, вначале нужно свои ns первичные зоны настроить, а уж потом делать синхронизацию со вторичными по вышеуказанной инструкции?

kpv - 6.7.2020 в 11:35

А с каким сервером тогда будет синхронизация, если не настроите?

Piercer - 6.7.2020 в 16:00

Получилось, но очень односторонне. В Debian 10 файлы с db.разрешением создаются в папке /home/username/conf/dns/ (где username - имя пользователя) и поэтому конфиг /root/dnsmgr/dnsmgrupdate.conf:

Цитата:

NAMEDPATH=/home/username/conf/dns/
MASTERIP=185.xxx.xxx.xxx
DNSMGRURL=https://dnsmgr1.server.net/manager/dnsmgr?out=text&authinfo=user:pass
DNSMGRURL=https://dnsmgr2.server.net/manager/dnsmgr?out=text&authinfo=user:pass
CHANGESONLY=yes
CHECKMASTER=yes


username-ов может быть много и у каждого своя папка, где создаются файлы с DB разрешением. По-другому (NAMEDPATH=/etc/bind/named.conf - где прописываются только пути регистрации db-файлов) не работает.

Как же тогда поступить, если на хостинге несколько username и каждый создает свои домены?

Добавлю. Скачал .dnsmgrupdate со своего хостинга, где стоит VestaCP - файлы различаются с вашим (указанным в шапке). Но именно благодаря этому теперь все работает и путь /etc/bind/named.conf со списком доменов корректно пишет домены.
Домены создаются и делегируются на серверах dnsmgr1/2
Проверьте ваш dnsmgrupdate.

[Отредактировано 6.7.2020 кто Piercer]

[Отредактировано 6.7.2020 кто Piercer]

[Отредактировано 6.7.2020 кто Piercer]

Piercer - 7.7.2020 в 11:39

Итак, с большим трудом путем проб, ошибок, логирования и анализа логов я все-таки победил связку Debian 10 + HestiaCP (параллельный проект VestaSP).

Я, пожалуй, отдельным топиком создам тему на форуме для интересующихся. И объясню, почему HestiaCP вытесняет VestaCP.

kpv - 7.7.2020 в 11:44

Цитата:
Исходное сообщение добавлено Piercer
Получилось, но очень односторонне. В Debian 10 файлы с db.разрешением создаются в папке /home/username/conf/dns/

bind сам никаких файлов, тем более в пользовательских каталогах не создаёт.