Кратко

  • FCFS Naming из RFC 9665 привязывает свободное имя к первому принятому ключу SIG(0); эта связь не подтверждает организацию, владельца, регистратора или безопасность сервиса.
  • Для доказательства нужны отдельные квитанции о сетевом допуске, регистрации, публикации на обслуживающих авторитетах, рекурсивном наблюдении, аутентификации endpoint и прикладной операции.

Датчик получил от сети адрес регистратора и отправил обновление для default.service.arpa.. Локальный клиент нашёл сервис. Но ноутбук, настроенный на внешний рекурсивный сервер, не получил ответа. На обоих устройствах DNS работал именно так, как был настроен.

service.arpa. — локально обслуживаемое пространство. Оно создано, чтобы ограниченные устройства не тратили энергию на сложное обнаружение регистрационного домена. Сеть предоставляет регистратор, а он при необходимости переписывает локальное имя в пространство с другой видимостью. Внешний резолвер не обязан знать локальную картину.

Следовательно, успешная регистрация не задаёт единую глобальную реальность. Она создаёт утверждение в конкретном административном контексте.

Непрерывность первого ключа

SRP использует DNS Update и SIG(0), но не требует заранее раздать каждому устройству общий секрет. Requester создаёт уникальную пару ключей, помещает публичный ключ в KEY RR и подписывает сообщение. Если имя ещё свободно, регистратор принимает первую заявку. Пока действует KEY-LEASE, другой ключ не может обновить имя хоста или экземпляра сервиса.

Это доказывает связь последующего сообщения с тем же приватным ключом. Оно не доказывает юридического владельца, производителя, сотрудника, разрешённую бизнес-функцию или исправность приложения. Криптографически последовательное объявление может указывать на недоступный или нежелательный сервис.

Ключ следует хранить устойчиво и долго. Factory reset или смена владельца могут удалить его, но новый ключ не наследует старое имя. До истечения прежнего KEY-LEASE возникает конфликт. Поэтому сброс требует политики инвентаря, имён, ожидания и поддержки, а не только генерации новой пары.

Одна транзакция, длинная цепочка публикации

SRP Update содержит ровно одно описание хоста и может включать несколько описаний и инструкций обнаружения сервисов. Явных prerequisite из RFC 2136 нет: регистратор сам проверяет структуру, связи записей, общий KEY, SIG(0), Update Lease и конфликт имени. Изменение атомарно.

Однако регистратор может быть hidden primary. Он принимает обновление, но клиентские запросы обслуживают другие авторитетные серверы. Между ними находятся journal, подпись зоны и репликация. NoError означает успешный приём, а не наблюдаемую публикацию.

Даже опубликованные SRV, TXT, A и AAAA не подтверждают работу endpoint. Клиент должен отдельно проверить идентичность стороны и выполнить безопасную прикладную операцию. DNS сообщает, куда обратиться; он не гарантирует результат обращения.

Имя живёт дольше сервиса

Обычные сервисные RR используют LEASE, типично около двух часов. KEY может оставаться примерно четырнадцать дней. Отключившийся прибор исчезает из списка сервисов, но сохраняет имя, чтобы его не перехватили во время короткого отсутствия.

Это две разные колонки состояния. Третья — TTL кеша. Когда lease истёк, авторитет больше не должен отдавать RR, но рекурсивный сервер может продолжать выдавать ранее полученную копию до конца её TTL. Нельзя выводить состояние сервиса по одному таймеру.

Кто удостоверяет регистратора

SIG(0) позволяет регистратору проверить requester. Базовая RFC не определяет, как requester автоматически валидирует ответ регистратора. Регистраторы обязаны предлагать DNS-over-TLS, а способные клиенты не должны откатываться к TCP, но без проверки ключа это Opportunistic Privacy, а не подтверждённая личность сервера.

Нужно фиксировать источник адреса регистратора, транспорт, факт TLS, реальную проверку сертификата или pinned key и fallback. Подпись запроса не распространяется на ответ.

Сетевой допуск также отдельный. SRP не имеет организационной авторизации сверх FCFS, поэтому регистратор должен отбрасывать источники вне административного домена. Для TCP важен handshake и политика Fast Open; для UDP в constrained network — фильтрация адреса и входного интерфейса.

Локальное имя не даёт глобального доверия

Приложения не должны считать service.arpa. более надёжным из-за специального суффикса. Такое имя не является глобально уникальным PKI-идентификатором. Аутентификация сервиса остаётся задачей его протокола.

Оператору также нельзя открывать FCFS на apex организации: автоматический клиент смог бы занять www, mail или smtp. Нужны отдельная discovery-зона и запрещённые метки. Обычные DNS Update credentials не должны переписывать SRP-owned records, иначе обещание первому ключу потеряет смысл.

Публичный KEY способен стать долговременным идентификатором устройства. Его можно не выдавать в ответах, но решение должно сохранять корректность DNSSEC и отрицательных ответов.

Полная квитанция

Сохраняются подключение к сети, интерфейс источника, регистрационный домен, механизм получения регистратора, адрес, транспорт и TLS validation. Затем — точное сообщение, связи host/service, KEY fingerprint, алгоритм, SIG(0), конфликт, запрошенные и выданные сроки и ответ.

После приёма проверяются journal, подписанная зона, каждый serving authoritative, локальный recursive resolver и TTL. Завершают цепочку аутентификация endpoint и прикладная транзакция. Если имя было переписано в другой scope, исходное и конечное пространства фиксируются явно.

Источники