Кратко

  • Первый рабочий документ DNSSD по ULD заставляет клиентов на каждом канале связи сходиться к одному предпочтительному серверу и при переходе заново регистрировать на новом сервере все свои службы.
  • Результат выбора не равен доказательству непрерывности. Запись о передаче должна связывать старый и новый серверы, причину перехода, ожидаемый состав, ответы на регистрации, сроки аренды, конфликты, работу прокси, различия IPv4/IPv6 и возврат к mDNS.

Неполный успех опаснее явного отказа

Полный сбой хорошо заметен: запросы DNS не получают ответа, продление аренды SRP прекращается, сессия DNS Push закрывается. Иная картина возникает, когда из пяти объявленных служб возвращаются четыре. Сервер доступен, большая часть приложений работает, а мониторинг показывает успешное переключение. Пятая запись могла столкнуться с чужим именем или не пройти повторную регистрацию, но в общем статусе этого не видно.

draft-ietf-dnssd-uld-00 — действующий Internet-Draft рабочей группы DNSSD IETF от 18 августа 2026 года. Unicast Local Discovery предлагает регистрировать и искать службы на локальном канале через одноадресные SRP и DNS, сохраняя совместимость с устройствами mDNS. Документ нацелен на Standards Track и в случае утверждения обновит RFC 6762, однако пока не является RFC. В разделах о безопасности, маршрутизаторах SNAC и назначении IANA остаются пометки о незавершённой работе.

Служба ULD объединяет пять логических частей. Регистратор SRP наполняет зону .local. Авторитетный DNS-сервер отвечает на одноадресные запросы. Discovery Proxy добавляет объявления, услышанные через mDNS, а Advertising Proxy показывает клиентам mDNS записи, поступившие по SRP. Для общих наборов данных ответ обычно объединяет зону и представление прокси обнаружения.

Поэтому исправный DNS-сервер не гарантирует полноту. Запись может быть в авторитетной зоне, но не попасть на сторону mDNS. Устаревший кэш может временно показывать уже потерянную службу. Клиенты IPv4 и IPv6 могут идти разными путями. Проверка одной положительной выдачи не закрывает вопрос о каталоге.

Приоритет переносит выбор, но не состояние

Серверы ULD публикуют числовой ключ pri; меньшее значение предпочтительнее. Для инфраструктуры проект задаёт 0, для обычных временных серверов — более высокие уровни в зависимости от среды и возможностей. Равные значения разрешаются по численно меньшему локальному IPv6-адресу.

Инфраструктурный сервер также помещает опцию ULD в IPv6 Router Advertisement. IPv6-клиент обязан использовать её для поиска инфраструктуры либо для проверки статуса, ранее полученного через DNS-SD. В качестве защиты такого объявления проект называет RA Guard.

В управляемой сети инфраструктурный статус включается оператором явно; на одном канале не должно быть двух маршрутизаторов, объявляющих соответствующую опцию. В домашней сети пограничный маршрутизатор может заявлять роль по умолчанию, если он уже фактически служит шлюзом. Иное устройство не должно присваивать себе статус без явной настройки.

Клиент сначала ищет инфраструктуру, затем выбирает среди временных серверов и при отсутствии рабочего варианта возвращается к mDNS. Начав использовать ULD, он должен перестать непосредственно участвовать в mDNS на этом канале и доверить операции .local выбранной службе.

Выбор приходится поддерживать во времени. Постоянные тайм-ауты, неудачное продление аренды SRP или потеря DNS Push делают сервер недоступным. Клиент временного сервера продолжает искать более предпочтительный вариант. Отказ старого узла и появление лучшего кандидата приводят к одному действию: клиент переходит и повторно регистрирует все свои службы.

Приложение C объясняет выбор сходимости вместо репликации. Два независимых регистратора способны принять одинаковое имя; конфликт обнаружится лишь позднее на уровне mDNS и может не вернуться к клиентам в понятном виде. Если все выбирают один сервер по детерминированному правилу, такое расщепление уменьшается. Но содержимое старого регистратора само по себе не переезжает.

Истёкший проект SRP Replication описывал альтернативу: партнёры сохраняют копии состояния, уменьшают число конфликтов и скрывают часть отказов от клиентов. Это не компонент ULD 00. В текущей модели именно клиент должен заметить переход и восстановить принадлежащие ему регистрации.

Нужен эталон до перехода

Успешный ответ SRP относится к конкретному обновлению. Он ничего не говорит о службе, которую клиент забыл отправить. Число строк на новом сервере также бесполезно без заранее закреплённого ожидаемого состава.

Сначала запись о передаче ограничивает область: канал, интерфейс, семейство адресов и интервал наблюдения. ULD поддерживает отдельный экземпляр и зону .local на каждом канале. Многосетевой компьютер может применять ULD на одном интерфейсе и mDNS на другом. Общая отметка «устройство мигрировало» смешивает эти процессы.

Далее фиксируются локальные адреса старого и нового серверов, их pri, класс инфраструктуры или временной службы и результат разрешения равенства. Причины следует различать: длительный отказ, невозможность продлить аренду, потеря Push, появление более высокого приоритета либо действие оператора.

Происхождение новой роли тоже является фактом. В управляемой сети можно сослаться на утверждённое изменение конфигурации; дома — на документированную функцию основного шлюза. Наблюдение опции RA и политика RA Guard подтверждают объявление, но не служат общей аутентификацией сервера. Проект допускает самоподписанные сертификаты, советует клиентам не отвергать их и прямо говорит, что аутентификация не является целью данного оппортунистического TLS.

Главная часть — сверка состава. Перед уходом клиент формирует обязательство по нормализованным описаниям, которые намерен повторить. После перехода для каждого элемента отмечаются принятие, отказ, конфликт, тайм-аут, срок аренды и повторная попытка. Новый сервер может предоставить соответствующий дайджест зоны. Затем отдельно проверяются одноадресный ответ, вклад Discovery Proxy и публикация Advertising Proxy в mDNS.

IPv4 и IPv6 требуют отдельных наблюдений. Объявление инфраструктуры через RA относится к IPv6. Клиент только с IPv4 находит серверы посредством mDNS и возвращается к нему, если предпочтительная цель недоступна по IPv4. Успешная проверка с современного двухстекового ноутбука не представляет все устройства.

Преднамеренно снятая служба, переименование после конфликта, регистрация в ожидании и fallback — разные исходы. Каждый может быть оправдан, но должен быть указан как исключение, а не растворён в проценте успеха.

Минимальная проверка вместо архива частной жизни

Локальные имена способны раскрывать людей, помещения, модели устройств и распорядок. Постоянное централизованное хранение всего каталога создаст лишний риск.

Для доказательства достаточно меньшего: солёного дайджеста нормализованных описаний, числа по широким типам и кодов исключений. Полный набор и соль кратковременно остаются на клиенте или в защищённой операционной среде. Долговременная запись хранит идентификатор перехода, значения до и после, расхождения, длительность и криптографическое обязательство против переписывания исходной точки.

Срок хранения должен охватывать истечение аренд, обновление кэшей и запоздалые сообщения. После этого ненужные названия удаляются. Цель — разобрать одну передачу, а не создать историю всех локальных устройств.

Граница допустимого вывода

Текст ULD подтверждает, что выбор и повторная регистрация являются разными операциями. Он не стандартизует предложенную здесь запись; это аналитическая конструкция Daniel Kade. В источниках нет публичных показателей потерь, сроков восстановления или межвендорной совместимости.

RFC 7113 описывает ограничения реализации RA Guard. Ключи и SIG(0) в SRP защищают контроль над регистрацией, но не удостоверяют полноту всего набора при смене серверов. Авторитетность ULD ограничена зоной .local на конкретном канале и не является делегированием публичного DNS.

Переход завершён не тогда, когда новый сервер победил и ответил. Он завершён, когда каждая ожидаемая служба снова видима, намеренно снята либо отражена как проверяемое отклонение.

Источники

  1. Текущий проект ULD
  2. История документа
  3. Зафиксированная редакция 00, HTML
  4. Зафиксированная редакция 00, текст
  5. API документа Datatracker
  6. Рабочий репозиторий DNSSD
  7. Доклад ULD на IETF 126
  8. Устав рабочей группы DNSSD
  9. RFC 6762 — Multicast DNS
  10. RFC 6763 — DNS-Based Service Discovery
  11. RFC 9665 — Service Registration Protocol
  12. RFC 8766 — Discovery Proxy
  13. RFC 8765 — DNS Push Notifications
  14. RFC 8490 — DNS Stateful Operations
  15. RFC 6105 — RA Guard
  16. RFC 7113 — Рекомендации по RA Guard
  17. RFC 4861 — IPv6 Neighbor Discovery
  18. Проект Advertising Proxy
  19. Проект Time Since Received
  20. Истёкший проект SRP Replication