rndc remote control vol2 :(

0

1

Доброго времени суток. Думал что разобрался с удаленным управлением rndc, но оказалось - не совсем. Изучил
ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/man.rndc.html
ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/man.rndc.conf.html
ftp://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/man.rndc-confgen.html
http://www.zytrax.com/books/dns/ch7/controls.html

Тестирую удаленное управление rndc на трех машинах, итак стенд: master (194.135.107.238), slave1 (194.135.107.234), slave2 (194.135.107.231), планируется возможность управления с мастера обоими слэйами и им самим, при запуске rndc на слэйвах - управление named только на локальном хосте. На каждой машине уже есть дефолтный rndc.key файл с именем ключа rndc-key (генерируются автоматически при установке из репозитория). Запустил rndc-conf на каждом слэйве, получил выводы со строками в base-64 для аутентификации rndc (secret). Вот куски named.conf слэйвов: slave1:

#acl для удаленного управления
acl "rndc-remote-controllers" {
194.135.107.238;
};
key rndc-slave1 {
        algorithm hmac-md5;
        secret "qOIGQ4jTuvTDLp0n5JNhGw==";
};
controls {
        #если ключ не указан, то будет использоваться default-key, но у меня нет на слэйвах rndc.conf, так что в любом случае будет использоваться /etc/bind/rndc.key
        inet 127.0.0.1 port 953 allow {localhost;};
        # для удаленного управления указываю нужный key_id
        inet 194.135.107.234 port 953 allow {"rndc-remote-controllers";} keys {"rndc-slave1";};
};

slave2

acl "rndc-remote-controllers" {
194.135.107.238;
};

key rndc-slave2 {
        algorithm hmac-md5;
        secret "aboGZF0oyZB9EO3uG9dSDw==";
};

controls {
        inet 127.0.0.1 port 953 allow {localhost;};
        #предположим я хочу 7766 порт
        inet 194.135.107.231 port 7766 allow {"rndc-remote-controllers";} keys {"rndc-slave2";};
};

На слэйвах rndc.conf не создавал.

Создал rndc.conf на мастере (тот, который будет иметь возможность управления слэйвами). master rndc.conf:

options {
        default-server localhost;
        default-port 953;
        default-source-address 194.135.107.238;
};

server slave1 {
        addresses {194.135.107.234 port 953;};
        key rndc-slave1;
};

server slave2 {
        addresses { 194.135.107.231 port 7766; };
        key rndc-slave2;
};

key rndc-slave1 {
        algorithm hmac-md5;
        secret "qOIGQ4jTuvTDLp0n5JNhGw==";
};

key rndc-slave2 {
        algorithm hmac-md5;
        secret "aboGZF0oyZB9EO3uG9dSDw==";
};

да, я не указал default-key, честно говоря я хочу использовать уже существующий /etc/bind/rndc.key при подключении к default-server (т.е. к localhost), но не знаю как его включить в rndc.conf, не добавляя отдельный statement в виде key rndc-key {...}; в rndc.conf, наверное с помощью $INCLUDE, но если как использовать $INCLUDE для файлов зон я представляю, то в данном случае не могу представить синтаксис. named.conf на master`е не исправлялся! Т.е. controls я туда не добавлял.

И что я получил в итоге:
1. на слэйвах rndc работает нормально, т.е. используется дефолтный ключ rndc.key.
2. на мастере rndc к локальному хосту не работает, очевидно потому, что я не указал default-key, НО даже если я пишу так: rndc -k /etc/bind/rndc.key, он игнорирует это, говоря что используется rndc.conf и читает ключи оттуда.
3. при попытке удаленного управления с мастера (194.135.107.238) slave`ом 1 получаю вот что:

root@bind9master:~# rndc -s 194.135.107.234 status
WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)
rndc: get default key: not found

ну не может он найти дефолтный ключ, а зачем? ведь для 194.135.107.234 явно указан нужный ключ, и он ДОЛЖЕН использоваться, судя по статьям по rndc. Помогает только явное указание key_id:

rndc -s 194.135.107.234 -y rndc-slave1 status

4. при попытке управления slave2 (194.135.107.231) еще интереснее - нужно помимо key_id (-y) указывать еще и порт, порт (который вообще-то указан в statement server):

server slave2 {
        addresses { 194.135.107.231 port 7766; };
        key rndc-slave2;

но этот порт почему-то не читается и при попытке отправить команду rndc без указания порта пишет .... 194.135.107.231#953: connection refused. Что за бред, почему нужный порт не читается из нужного sever?

В общем, если резюмировать: как добавить в dafeult-key уже существующий файл ключа и почему не читаются параметры вроде key и port из statement server и все приходится указывать руками?
Большое спасибо тем, кто осилит эту простыню текста.

Ссылка

←	zentyal ipip

NGinx не хочет использовать мою стандартную директорию

→

UPDATE 1

update1: хм, оказалось достаточно просто добавить

include "/etc/bind/rndc.key";

в начало rndc.conf и добавить default-key rndc-key в options {}. Теперь

rndc status
rndc -s localhost status
rndc -s 127.0.0.1 status

работают нормально, т.е. управлять локальным named я могу, но проблема с необходимостью указания key_id и порта для удаленного управления slave`ами осталась.

nokogerra ★
(24.02.15 08:01:45 MSK) автор топика

Ссылка

UPDATE 2

Добавлю еще наблюдений: Видимо важно обращаться именно к имени оператора server, т.е. в моем случае это именно slave1 и slave2, и учитывая что они даже НЕ РЕЗОЛВЯТСЯ, rndc будет отправлять команды на адреса, указанные в пункте addresses. Т.е. команда должна выглядеть в моем случае не так:

rndc -s 194.135.107.231 -y rndc-slave2 -p 7766 status

а так:

rndc -s slave2 status

и тогда все пункты, указанные в операторе server {} читаются. Но есть одно НО: если в команде rndc к серверу поставить заведомо неверный key_id, например:

rndc -s slave2 -y rndc-slave1 status

то я получу ошибку, что логично. Но если я указываю заведомо неверный порт, например slave2 в named.conf указан 7766 порт, а я указываю -p 953, то команда все равно отрабатывает (и это видно в syslog того сервера, которому я шлю команду, пробовал на reload).

Если, например, вместо имен slave1/slave2 в rndc.conf использовать IP-адреса и убрать пункты addresses, то при попытке постучаться на заведомо неверный порт я получаю сообщение о том, что в подключении отказано, т.е. работает правильно. Что за странное поведение при использовании addresses?

nokogerra ★
(24.02.15 09:49:24 MSK) автор топика

Ссылка

UPDATE 3

Я разобрался: Если в addresses в операторе server {} вместе с адресом указан порт, как например здесь:

server slave1 {
        addresses {194.135.107.234 port 953;};
        key rndc-slave1;
        source-address 194.135.107.238;
};

то явное указание порта в rndc игнорируется, например на 194.135.107.234 указано слушать только на 953:

controls {
        inet 127.0.0.1 port 953 allow {localhost;};
        inet 194.135.107.234 port 953 allow {"rndc-remote-controllers";} keys {"rndc-slave1";};
};

но если я отправлю что-то подобное:

root@bind9master:~# rndc -s slave1 -p 5555 reload
WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)
server reload successful

то команда будет успешно выполнена, а опция -p 5555 проигнорирована. НО если rndc.conf имеет такой вид:

server slave1 {
        addresses {194.135.107.234};
        port 953;
        key rndc-slave1;
        source-address 194.135.107.238;
};

т.е. порт указан вне пункта addresses, то попытка отправить команду на другой порт провалится:

root@bind9master:~# rndc -s slave1 -p 5555 reload
WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)
rndc: connect failed: 194.135.107.234#5555: connection refused

при этом если указать явно 953 или не указывать вообще (он указан в соответсвующем операторе server slave1 {}), то все работает как надо:

root@bind9master:~# rndc -s slave1 reload
WARNING: key file (/etc/bind/rndc.key) exists, but using default configuration file (/etc/bind/rndc.conf)
server reload successful

Все вопросы исчерпаны. Всем спасибо.

nokogerra ★
(24.02.15 12:35:05 MSK) автор топика