Шведская контора 33k Networks AB выкатила сервис DynIP (dynip.dev) — динамический DNS, построенный не вокруг проприетарного клиента, который надо ставить на роутер, а вокруг открытого стандарта RFC 2136 с подписью TSIG. Обновлённая запись долетает до резолверов по всему миру меньше чем за минуту, DNSSEC включён по умолчанию, IPv6 — полноправный гражданин (а не приклеенная сбоку фича), а базовый тариф бесплатный. На первый взгляд — мелочь для гиков. На деле это аккуратный и технически грамотный ответ на вполне взрослую болячку современного интернета, и ниже я разберу, почему за этим стоит внимательно следить.
В чём, собственно, боль
Динамический IP — это когда провайдер выдаёт вам адрес на время, а потом без предупреждения меняет. Для среднего пользователя, который только лазит в браузере, это вообще незаметно. Но как только вы хотите достучаться до чего-то своего снаружи — домашнего сервера, Home Assistant, видеонаблюдения, NAS, тестового стенда — адрес обязан быть предсказуемым. Иначе после очередной переподключки роутера ваш сервис просто исчезает из сети.
Классическое лечение — Dynamic DNS (DDNS): на стороне клиента крутится агент, который замечает смену IP и обновляет DNS-запись, чтобы доменное имя всегда указывало на актуальный адрес. Идее этой лет двадцать пять, и в эпоху dial-up она была революцией. Но сегодня к старой проблеме добавился новый поворот, который и делает DynIP актуальным именно сейчас:
📉 IPv4-адреса закончились. Физически. Свободных блоков у региональных регистраторов почти не осталось.
🕳️ Провайдеры массово прячут абонентов за CGNAT (Carrier-Grade NAT) — один белый IPv4 делится между сотнями клиентов из диапазона 100.64.0.0/10. Проброс портов в «большой интернет» в такой схеме невозможен в принципе: у вас просто нет своего публичного адреса.
🌐 Единственным реальным выходом «наружу» всё чаще становится IPv6 — там адресов столько, что каждому устройству хватит с запасом на тысячу жизней.
То есть проблема не просто «адрес иногда меняется», а «адреса у меня толком и нет, зато есть IPv6, который надо как-то обслуживать». Старые DDNS-сервисы, заточенные под один A-record в IPv4, на этот вызов отвечают плохо.
Почему «60 секунд» — это не маркетинговая цифра
Главная фишка DynIP — сквозное распространение обновления меньше чем за минуту. Большинство бесплатных провайдеров кэшируют записи на 30 минут, и это значит, что после смены IP ваш сервис может «висеть мёртвым» полчаса. Откуда у DynIP минута, и почему это честная цифра, а не лозунг?
Тут работают две вещи в связке. Первая — короткий TTL (Time To Live) в 60 секунд: резолверы по миру держат запись в кэше всего минуту, после чего обязаны спросить заново. Вторая, и более интересная, — архитектура на DNS NOTIFY (RFC 1996). Обычно вторичные (secondary) серверы узнают об изменениях лениво — опрашивают первичный по таймеру SOA refresh, раз в час или реже. NOTIFY переворачивает логику: первичный сервер сам пушит уведомление вторичным, мол, «зона изменилась, забирайте обновление немедленно», и те тут же подтягивают свежие данные через IXFR/AXFR.
Сложить это вместе — и получается классический паттерн hidden primary + multi-region secondaries: спрятанный от мира первичный сервер (он же control plane) принимает ваши обновления, мгновенно рассылает NOTIFY на географически разнесённые публичные NS-серверы, а короткий TTL гарантирует, что и кэши резолверов обновятся почти сразу. Минута — это сумма этих задержек, а не оптимистичная оценка.
RFC 2136 + TSIG: открытый стандарт против «ещё одного клиента»
Вот здесь, на мой вкус, и кроется главная элегантность сервиса. Вместо того чтобы заставлять вас ставить фирменный бинарник на роутер (привет, ddclient и зоопарк его форков), DynIP говорит на языке, который ваше железо уже знает, — RFC 2136, он же DNS UPDATE. Это стандарт 1997 года, изначально придуманный для того, чтобы DHCP-серверы автоматически регистрировали хосты в DNS. FortiGate, MikroTik, OPNsense, OpenWrt, Cisco — всё это умеет DNS UPDATE из коробки, без сторонних скриптов.
Аутентификация делается через TSIG (Transaction SIGnature, RFC 2845). Механика простая и надёжная: у клиента и сервера есть общий симметричный ключ, и каждое сообщение UPDATE подписывается HMAC (например, HMAC-SHA256) поверх содержимого плюс временной метки. Сервер проверяет подпись и заодно смотрит, что метка укладывается в допустимое окно (fudge, по умолчанию около 300 секунд) — это защита от replay-атак, когда перехваченный пакет пытаются проиграть повторно. Побочный, но важный нюанс: время на роутере и сервере должно быть синхронизировано, иначе подпись «протухнет». Так что NTP вам в помощь.
Что это даёт по факту:
🔑 Никакой привязки к вендору (vendor lock-in) — настроили ключ один раз, и забыли. Захотите уйти к другому провайдеру, говорящему на RFC 2136, — переедете без переписывания инфраструктуры.
🧰 Никаких сомнительных бинарников на пограничном устройстве. Меньше кода — меньше поверхность атаки.
🤖 Для автоматизации есть ещё и REST API с токенами (read-only или full access), плюс готовые сниппеты под Docker, cURL, PowerShell, Python и даже Arduino/ESP32 на C++. Виртуалка в облаке может прописывать свой адрес сама при старте.
Кстати, любопытная деталь, которую видно прямо в интерфейсе сервиса и которая выдаёт его внутреннее устройство: обновления через HTTP API работают сразу, а вот RFC 2136/TSIG приходится подождать, пока новая зона «расползётся» по NS-серверам. Логично: HTTP-запрос идёт в control plane, который может действовать до полной пропагации, а TSIG-апдейт стучится напрямую в авторитативный сервер, и тому сперва нужно физически получить зону.
DNSSEC «на лету» — вот где настоящая инженерия
DNSSEC включён по умолчанию, и это не галочка ради галочки. DNSSEC криптографически подписывает DNS-записи (RRSIG поверх данных, ключи DNSKEY, а DS-запись в родительской зоне замыкает цепочку доверия до корня), защищая от подмены ответов и отравления кэша.
Но вот в чём фокус: подписывать динамическую зону технически непросто. В обычном DNSSEC записи подписывают офлайн, один раз, и держат подписи. А у DynIP записи меняются каждые 60 секунд — офлайн-подпись тут бесполезна. Значит, нужен online signing: авторитативный сервер пересчитывает подписи на лету при каждом изменении, держит ключ подписи зоны «горячим» и аккуратно перестраивает цепочки отрицания существования (NSEC/NSEC3) по мере того, как записи появляются и исчезают. Это умеют делать движки вроде PowerDNS или Knot DNS, и реализовать это безглючно — отдельное удовольствие. Так что когда сервис «автоматически генерирует ключи, публикует их в родительской зоне и подписывает все записи за 30 секунд», за этой «волшебной кнопкой» прячется довольно серьёзная машинерия.
Сюда же — выдача SSL в один клик. Под капотом это ACME-челлендж типа DNS-01 от Let's Encrypt: чтобы доказать владение доменом, сервис кладёт TXT-запись, и центр сертификации её проверяет. Поскольку DynIP сам держит вашу зону и подписывает её, DNSSEC становится обязательным условием для выпуска сертификата — отсюда и подсказка в интерфейсе, что без активного DNSSEC сертификат не выдадут. Зато вам больше не надо вручную копировать ключи с роутера и возиться с обновлением.
И ещё про чужие домены. Режим BYOD (Bring Your Own Domain) позволяет завести динамические поддомены в своём пространстве имён, делегировав его на ns1/ns2.dynip.dev. Причём делегирование требует обе NS-записи разом — одиночную сервис принципиально отвергает. Это правильная практика: один NS — это гарантированная точка отказа, а отказоустойчивость в DNS не роскошь, а норма.
Личное мнение: к чему присмотреться критически
Сервис мне симпатичен, но честный разбор требует назвать и оборотную сторону — иначе грош цена восторгам.
⚖️ Короткий TTL — это палка о двух концах. Минута до обновления оплачивается возросшим числом запросов к авторитативным серверам: кэши протухают быстро, и трафик на NS растёт. Для бесплатного тарифа это вполне может стать рычагом ограничений.
🔗 Открытые стандарты убирают lock-in на уровне протокола, но доверие вы всё равно делегируете. Ваши NS-серверы теперь у них — если их инфраструктура ляжет, ляжет и резолвинг ваших имён. «No vendor lock-in» означает «легко переехать», а не «ни от кого не зависишь».
🇸🇪 Прописка в Швеции (33k Networks AB, биллинг по шведскому праву с хранением записей 7 лет) — приятный сигнал для тех, кому важна юрисдикция ЕС и GDPR. Но это всё ещё молодой коммерческий сервис, и завязывать на бесплатный тариф что-то по-настоящему критичное я бы поостерёгся, пока он не доказал устойчивость временем.
🆓 «Щедрый бесплатный тариф» — формулировка обтекаемая. API-токены, например, уже фича Pro. Так что перед серьёзным внедрением стоит трезво посмотреть на лимиты по числу зон и на то, что именно прячется за платной стеной.
Вывод
DynIP — хороший пример того, как старую идею переосмысляют под реальные вызовы сегодняшнего дня, а не просто перекрашивают фасад. Исчерпание IPv4, повсеместный CGNAT, ужесточение требований к безопасности DNS и тотальная автоматизация — на каждый из этих пунктов у сервиса есть внятный, построенный на открытых стандартах ответ. И сделан он так, что сложнейшая инженерия (online-подпись DNSSEC, NOTIFY-архитектура, ACME) спрятана за интуитивным интерфейсом.
Мой прогноз простой: подобные сервисы будут только набирать вес по мере того, как IPv6 из «когда-нибудь потом» превращается в «единственный способ достучаться до своего железа сегодня». Расцвет homelab'ов и желание людей держать данные у себя, а не в чужом облаке, эту тенденцию только подстегнут. А лучший комплимент для такой инфраструктуры — когда о ней просто забываешь: настроил роутер один раз, и проблема динамического IP перестаёт существовать. Похоже, именно к этому идея DDNS и шла все эти двадцать пять лет.
Источники
📰 DynIP — официальный сайт сервиса: https://dynip.dev/
📖 «DynIP: Как эволюционировала простая идея за 25 лет и почему она снова актуальна» (полный разбор): https://telegra.ph/DynIP-Kak-ehvolyucionirovala-prostaya-ideya-za-25-let-i-pochemu-ona-snova-aktualna-05-26