Знадобилося мені якось на своєму сервері DNS забезпечити функціональність подібну dyndns.com. проте майже відразу з'ясувалося, що сервера як такого у вільному доступі не знайти. Побродивши по мережі, знайшов деякі рішення на кшталт цього. однак деяка брутальність підходу і складність реалізації мені відразу не сподобалася.
На сервері працює bind9. і для нього, зрозуміло, існує рішення, що дозволяють динамічно оновлювати доменні записи з віддалених клієнтів. Однак зводиться воно до використання просунутого методу nsupdate, яка не підтримується средненьким мережевим обладнанням не промислового рівня, а зокрема домашнім маршрутизатором. Тому кращим рішенням, на мій погляд, було мати сервер, протокольно сумісний з ddclient. який є майже у всіх нині існуючих мережевих пристроях.
Деякі вступне слово
Отже, побіжно глянувши спеки. Кайо подумав, що реалізація подібної приблуди - вельми просте завдання. Ось деякі роздуми, які привели до описуваного в статті рішенням:
Ідея перша. Міняти записи безпосередньо було б відносно складно і небезпечно, набагато краще використовувати для цього nsupdate. який по суті приймає на вхід файл змін і послідовно застосовує наявні в ньому команди. При цьому немає необхідності пересмикувати сам bind. щоб зміни вступили в силу.
Ідея четверта. Для адміністрування користувачів в цій реалізації вирішено було написати невеликий скрипт, який автоматично генерує ключі, а також оновлює базу користувачів і список ключів bind.
Динамічно оновлювані зони в bind9
Перед тим, як перейти до опису установки і настройки сервісу, хотілося б розповісти, як працює nsupdate і bind.
створюємо ключі
Отже, перше, що нам потрібно зробити, налаштувати зони, які ми б хотіли оновлювати динамічно. Утиліта nsupdate взаємодіє з bind використовуючи ключі, тому зараз ми повинні генерувати ключ приблизно таким чином:
Тут ми вказали тип ключа (hmac-md5), довжину (512, можна в принципі використовувати будь-яку для цього типу ключа від 1 до 512) і користувача (ddserver).
По завершенні у нас буде пара ключів: публічний і приватний, у мене вийшли такі:
Далі нам потрібно хеш (все, що знаходиться після числа 157 в файлі .key) з публічного ключа для додавання його в конфігурацію сервера.
Створимо файл /etc/bind/ddserver.conf наступного змісту:
Далі включимо його в /etc/bind/named.conf.local (Кайо додав рядок перед описом доменних зон):
Тепер пересмикує bind9:
налаштовуємо доступ
Майже все, однак ми ще не дали дозволу на динамічне оновлення конкретних зон, тому робимо наступне: знаходимо опис потрібної зони, і додаємо в неї дозвіл на оновлення відповідного ключу:
Цього в общем-то буде досить, але так ми дали занадто багато можливостей клієнта з ключем ddserver. Можна визначитися більш конкретно, які оновлення дозволено робити, наприклад додавши наступну директиву замість блоку allow-update:
Тим самим ми дозволили оновлювати лише A запис тільки для поддомена kayo-home.illumium.org.
Щоб надмірно не захаращувати статтю, Кайо не розглядає тут оновлення зворотних зон, однак суть практично та ж.
Тестуємо оновлення зони
Додаємо запис A-типу kayo-home.illumium.org з IP 1.2.3.4 і TTL 60 секунд. Час життя TTL вказувати необхідно, чим воно більше, тим довше запис буде залишатися в кешах DNS серверів. Наприклад, якщо вказати 600 (10 хвилин), запис на протязі 10 хвилин не буде запитуватися знову, і якщо протягом цього часу IP оновиться, про це стане відомо тільки через вказаний інтервал.
Тепер власне пробуємо оновити (робити це можна з будь-якого хоста, де є nsupdate і доступний створений нами раніше приватний ключ):
Дивимося syslog на сервері в момент запуску команди, повинні з'явитися записи виду:
При цьому по завершенні nsupdate не повинен нічого видати на stdout і stderr. Якщо ви не вірно визначили привілеї, утиліта скаже, що оновлення не вдалося. Так що тепер щоб переконатися, що ми не може таким чином оновлювати інші записи, пробуємо змінити ім'я в update.ns і заново викликати nsupdate, якщо все налаштовано, як описано у мене, отримуємо наступне:
А в syslog на сервері bind скаже ось що:
DynDNS Server сумісний з протоколом dyndns2
Кайо розробив ddserver як FastCGI backend. Софт написаний на C і запускається як демон під звичайним користувачем, якому дозволено знаходити ключі користувачів і запускати nsupdate. Проект розмістив на SF.Net. Там же лежать готові пакети для Debian. Загалом, хотілося простіше, вийшло як завжди ^ _
Короткий опис протоколу
Доменні імена повинні бути представлені в повному форматі, але без завершальній точки. У разі, якщо доменних імен кілька, вони повинні бути перераховані через кому.
Керування користувачами
Для адміністрування користувачів був написаний скрипт ddserver-admin, робить він наступне:
- ddserver-admin user-list - виводить список існуючих користувачів
- ddserver-admin user-add
- додає нового користувача або оновлює існуючого - ddserver-admin user-del
- видаляє існуючого користувача
При додаванні і оновленні користувача буде потрібно ввести пароль для доступу через WEB. Скрипт автоматично генерує потрібні ключі і оновлює htpasswd файл відповідної утилітою з apache. Ім'я користувача буде назвою ключа для bind.
В директорії / etc / ddserver у нас будуть два файли:
розмежування доступу
Щоб не дублювати документацію і багато не писати тут, наведу лише деякі приклади налаштування автоматично оновлюваних зон:
Важливо мати на увазі також значення TTL в файлах опису зон, щоб знизити час перебування динамічних записів в кешах серверів імен.
Налаштування поновлення через WEB в Nginx
Оскільки Кайо використовує Nginx, тут буде розказано, як налаштувати роботу сервісу в якості FastCGI backend-а до нього. Перейдемо відразу наприклад конфігурації, який досить простий і практично не вимагає пояснень:
статус проекту
Поки проект знаходиться в стадії активного тестування, так що можуть виникнути проблеми.
В даний момент підтримується:
- оновлення A-записів
- оновлення кількох імен за раз (з однаковим IP)
- оновлення MX записів
- автообновление зворотних зон