Плагин Technitium DNS

Свои домены — на своих серверах имён, а управление — из хаба: зоны example.com, example1.com… создаются и правятся в разделе «Плагины», командами сценариев и агентами по MCP. Серверы — стек Technitium DNS из примеров конвейеров: ns1 (первичный) и ns2 (вторичный) на разных хостах. Плагин — сервис plugin того же стека; общий принцип плагинов — Плагины.

Без плагина хаб работает как прежде: Traffic Fly, сайты и выкладки DNS не трогают.

Выложить и подключить

1. «Выкладки» → «Новый конвейер» → «Примеры» → «Technitium DNS Server» на хост ns1; второй конвейер — pipeline.secondary.yaml на ns2. Подробно — README примера. Плагин уже в описании: сервис plugin, nkt-plugin.py в files: и NKT_PLUGIN_SECRET: generate:hex32.
2. «О системе» → «Плагины» → «Подключить» → «С конвейера» → конвейер Technitium → «Проверить» → «Подключить».
3. В меню хаба — «Плагины» → Technitium DNS: зоны, записи, делегирование, DNSSEC.

Technitium уже работает — плагин к нему, без переезда

Нативная установка (install.sh, служба dns) или свой compose — сам Technitium не трогается, плагин ставится рядом службой:

1. API-токен в консоли Technitium: Administration → Users → пользователь nkt в группе DNS Administrators (зоны и настройки DNS, без управления пользователями) → Sessions → Create Token от его имени. Пароль администратора плагину не нужен.
2. «О системе» → «Плагины» → «Установить на хост» → «Technitium DNS», хост с Technitium, токен; имена серверов (ns1, ns2) — для проверки делегирования и NS новых зон.
3. Задание поставит плагин службой nkt-plugin-dns и подключит его — в меню появятся «Плагины» → Technitium DNS.

Новые зоны вторичный получает так же, как сейчас (перенос, каталог или кластер Technitium) — плагин в это не вмешивается. На вторичный плагин ставить не нужно.

Или перенести Technitium в стек nkt

Перенести его в стек nkt на том же хосте — без потери зон, записей и ключей: резервная копия из старой консоли (Settings → Backup Settings) → /srv/compose/technitium/import/backup.zip → в конвейере IMPORT_BACKUP: /import/backup.zip → сценарий «остановить службу dns → выложить». dns-init восстановит копию на пустой сервер, ключи TSIG из неё оставит как были (ns2 продолжит забирать зоны), учётные записи — только с IMPORT_AUTH. Откат — «Остановить» выкладку и снова включить службу dns. По шагам, с резолвером хоста, ns2 и откатом — §9 README примера.

Несколько доменов

Каждый домен — своя зона. «Добавить зону» (или dns zone add … в сценарии):

• зона создаётся первичной на ns1 и становится членом зоны каталога (catalog.nkt.invalid, RFC 9432): ns2 получает её сам — заводить её на втором сервере не нужно;
• NS зоны — ns1 и ns2;
• шаблон по желанию: сайт (@ и www на адрес) или почта (MX, SPF, DMARC, mail на адрес).

Дальше — у регистратора домена:

1. NS — ns1.example.com и ns2.example.com (имена ваших серверов);
2. если серверы имён внутри этого же домена — glue-записи (их адреса);
3. «Делегирование» у зоны показывает, что указать, и что уже видят публичные резолверы (Cloudflare, Google): «делегирована», «NS другие», «зона не видна».

Сначала заведите все записи домена (A, MX, TXT…) — потом меняйте NS у регистратора: так сайт и почта не пропадут на время переезда.

Записи

• «Записи» — таблица: имя, TTL, тип, значение; «Добавить запись» и «Удалить» у строки.
• «Текстом» — вся зона строками ИМЯ TTL ТИП ЗНАЧЕНИЕ (@ — сама зона) в окне правки с диффом перед записью и историей версий в хабе. Плагин сравнивает текст с зоной и меняет только разницу; SOA, DNSSEC и записи приложений (Failover) в тексте не показываются и не трогаются.
• Типы: A, AAAA, CNAME, NS, MX, TXT, SRV, CAA, PTR, ANAME.

@        3600   A     203.0.113.10
@        3600   MX    10 mail
@        3600   TXT   "v=spf1 mx -all"
mail     300    A     203.0.113.20
www      3600   CNAME @
_sip._tcp 3600  SRV   10 5 5060 sip.example.com.

DNSSEC

«DNSSEC» у зоны — подписать (ECDSA P-256, ключи и их смена — у Technitium) и записи DS для регистратора. Снять подпись — сначала уберите DS у регистратора.

Сценарии

dns zone add example.com template site ip 203.0.113.10
dns set app.example.com A 203.0.113.10,203.0.113.11 ttl 300
dns add example.com TXT "google-site-verification=…"
dns rm old.example.com
dns check example.com
dns sign example.com
dns zone rm test.example.org

• set — ровно эти значения типа у имени (недостающие добавит, лишние этого типа уберёт); add — одно значение к имеющимся; rm — все записи имени, одного типа или одно значение.
• «Проверить» разбирает команды у плагина; сухой прогон показывает, что изменится (+ / -), ничего не меняя.

MCP

Инструменты агента: dns_zones, dns_records, dns_zone_text, dns_delegation, dns_dnssec (чтение) и dns_zone_add, dns_zone_delete, dns_zone_apply, dns_template_apply, dns_record_set, dns_record_add, dns_record_delete, dns_dnssec_sign, dns_dnssec_unsign — администратору или токену по правам с действием «плагин dns». Пример просьбы: «заведи зону example1.com с сайтом на 203.0.113.10 и проверь делегирование».

Для хаба: Traffic Fly, сайты, имена хостов

Плагин сообщает хабу, что ведёт DNS, — и хаб ставит записи сам:

• Traffic Fly — галочка «DNS через плагин» у маршрута (в сценарии fly route … dns plugin, в конвейере dns: plugin в блоке fly:): при «Применить» имена маршрута получают A-запись на адрес шлюза; одно имя на нескольких шлюзах — запись приложения Failover (Technitium отдаёт только живые шлюзы, проверка tcp443);
• сайт конвейера — dns: auto в блоке site: (публичный адрес хоста) или адреса списком: записи ставятся до сертификата, certbot сразу находит имя;
• автоимена хостов — «О системе» → «Плагины» → «Автоимена хостов»: каждый хост и машина хаба — <хост>.<зона> на адрес, по которому хаб к нему ходит (правка с диффом и историей).

Хаб помнит, что поставил каждому владельцу (маршрут, сайт, хост), и при изменении передаёт плагину и прежнее: лишнее уберётся, чужие значения у того же имени останутся. Имя вне зон плагина — строка в журнале, не ошибка. «Сверить» в «О системе» показывает, что изменится, «Применить» — приводит записи; сверка идёт и сама каждые 10 минут (сменился адрес хоста, плагин был недоступен).

Обновление существующей установки

Зона каталога появилась в этой версии примера:

• первичный: выложите конвейер заново — dns-init создаст зону каталога и включит в неё зоны из ZONES;
• вторичный: выложите его конвейер заново — dns-init заведёт вторичную зону каталога. Заведённые раньше вручную вторичные зоны остаются как есть; чтобы ими управлял каталог, удалите их в консоли ns2 — каталог создаст их снова через несколько секунд.