Загадочный DDNS

Персональный блог одноименного форумчанина. Человека и парохода, не побоюсь этого сравнения :)

Модератор: tyomitch

tyomitch
Пользователь #1352
Пользователь #1352
Аватара пользователя
 
Сообщения: 12822
Зарегистрирован: 20.10.2002 (Вс) 17:02
Откуда: חיפה

Загадочный DDNS

Сообщение tyomitch » 02.04.2006 (Вс) 22:51

В качестве компенсации за предыдущий пост, этот будет покороче :-)

* у меня стоят BIND 9.3.1 и ISC DHCPD 3.0.3; на внутренней зоне (видной только из локалки) поднят DDNS, благодаря которому все машины сети видны по netbios-именам. DDNS поднят полностью по мануалу от DHCPD, и я имею весьма смутное представление о том, как оно работает.

Кроме компов локалки, добавленных во внутреннюю зону DHCP-сервером, мне показалось удобным иметь в ней сокращённые имена для некоторых Интернет-хостов -- чтобы не набирать каждый раз их полный адрес. Просто прописать их в \WINNT\system32\drivers\etc\hosts на рабочей машине мне показалось недостаточно кошерным, и я искал способ вносить изменения в DDNS-зону вручную. Это оказалось не так просто: то ли BIND, то ли DHCPD ведёт журнал изменений в зоне. Формат этого журнала страшный и непонятный; и если вносить изменения напрямую в файл зоны, то сервер замечает его рассогласование с журналом и отказывается работать. Иногда помогали пляски с бубном и удаление журнала нафиг; иногда нет.

* Я случайно наткнулся на утилиту nsupdate(8‍) из состава BIND, которая заявляла, что может посылать на сервер DDNS-обновления. Пароль от DDNS-зоны ей мог, судя по мануалу, передаваться двумя способами: ключом -k с путём к файлу с паролем, или ключом -y непосредственно в командной строке. При этом сама утилита на ключ -y жаловалась, что такого ключа она не знает, а на ключ -k -- что путь надо передавать в виде каталог:имя файла. (При этом передача пути в таком виде всё равно ни к чему не приводила.) Было очевидно, что либо мануал какой-то левый, либо утилита. А может быть, оба :-)

Потом оказалось, что это давно известный баг в связке FreeBSD+BIND: более новые версии BIND кладут свои файлы не туда, куда клали старые, и в итоге после обновления системы в ней одновременно оказываются конфликтующие версии одних и тех же файлов. (А вы ещё говорите, DLL hell...) В моём случае мануал оказался от новой версии nsupdate, бинарник которой лежал в /usr/bin; однако бинарник старой версии продолжал существовать в /usr/sbin, который в PATH стоит первее. Решение проблемы, к счастью, очень простое -- chmod -x /usr/sbin/nsupdate

* Теперь, когда поведение утилиты соответствует её мануалу, мне удаётся обновлять зону, передавая пароль в командной строке: nsupdate -y DDNS:XXxXXXxxxxxxXXxXxxXxXX==

Это, естественно, несекурно. Любой пользователь смог бы подглядеть мой пароль при помощи ps(1).

Если же я указываю путь файла с паролем, то nsupdate ругается:
Код: Выделить всё
tyomitch# cat DDNS.key
Private-key-format: v1.2
Algorithm: 157 (HMAC)
Key: XXxXXXxxxxxxXXxXxxXxXX==
tyomitch# nsupdate -k DDNS.key
could not read key from DDNS.key: unexpected token

Объясните мне кто-нибудь, чего ей не нравится?

* И ещё один вопрос: нет ли более простой и визуальной утилиты для работы с DDNS? Идеально, если бы она загружала зону в текстовый файл, давала его отредактировать, и потом отсылала на сервер. Гугл не помог :-(
Изображение

Вернуться в Tyomitch

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7

    TopList  
cron