Кратко

  • 18 августа Datatracker одобрил draft-ietf-dnssd-uld-00 как документ рабочей группы DNSSD и указал, что он заменяет индивидуальный проект. Нормализованный технический текст не изменился.
  • ULD объединяет регистрацию SRP, авторитетный DNS и два прокси на предпочтительном сервере в сегменте. Это может уменьшить издержки mDNS в Wi-Fi, однако раздел безопасности пока пуст.

В новой версии Unicast Local Discovery изменился прежде всего владелец процесса, а не протокол.

История рабочего документа фиксирует в 16:22:50 UTC 18 августа три события: председатель одобрил -00, версия стала доступна и получила связь замены с draft-tlmk-infra-dnssd. После удаления имени, даты, срока действия, адреса репозитория и повторяющихся колонтитулов предыдущий и новый тексты совпадают. Поэтому новость состоит в переходе под ответственность DNSSD, а не в появлении новой функции.

До этого рабочая группа исправила процедуру. История предшественника сообщает, что председатель сначала оформил принятие после поднятия рук на сессии IETF 126, а затем отменил его: вызов на принятие следовало сначала провести в рассылке. Такой вызов вышел 21 июля, и 6 августа появился окончательный статус «Adopted by a WG». Публичное исправление делает решение проверяемым, но не означает согласия с каждой строкой будущего стандарта.

Проект ULD начинает с практической проблемы локальных сетей. В mDNS каждое устройство, публикующее сервис, слушает multicast-запросы и отвечает на них. В Wi-Fi multicast-кадры не подтверждаются и не повторяются на уровне MAC, точка доступа не буферизует их для спящей станции, а передача идёт на низкой обязательной скорости. Батарейному устройству приходится часто просыпаться или пропускать запросы, а небольшой поток занимает непропорционально много эфирного времени.

ULD помещает между клиентами постоянно доступный сервис. Сервер совмещает регистратор SRP, авторитетный DNS, Discovery Proxy и Advertising Proxy. Совместимый клиент регистрирует сервисы на нём и направляет .local-запросы по unicast. Пока сервер доступен, клиент прекращает обычное участие в mDNS на этом сегменте; прокси сохраняют связь с устройствами старого типа.

Базовые компоненты уже описаны стандартами. RFC 9665 задаёт Service Registration Protocol и сроки регистрации. RFC 8766 задаёт Discovery Proxy, отвечающий на unicast-DNS по данным, полученным из mDNS-сегментов. ULD добавляет правила, превращающие эти функции в один обнаруживаемый сервис: объявление, приоритет, наблюдение и переход.

RFC 6762 с Multicast DNS остаётся в системе. Проект говорит, что обновит его в случае утверждения, но использует mDNS для объявления серверов, совместимости со старыми устройствами и отката, когда работоспособного ULD-сервера нет. Предлагается убрать часть рутинной multicast-нагрузки, а не немедленно вывести mDNS из эксплуатации.

Главная операционная перемена — право сервера быть предпочтительным. В управляемой сети оператор должен явно назначить инфраструктурный ULD-сервер, а соответствующую опцию Router Advertisement в одном сегменте должен объявлять не более чем один узел. Временные серверы могут работать с более низким приоритетом. Клиенты продолжают искать лучший вариант, обнаруживают устойчивые сбои и заново регистрируют все сервисы после перехода.

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

В IPv6 инфраструктурный сервер также объявляет себя новой RA-опцией. Клиент должен обнаруживать его по этой опции или проверять ею заявление, полученное через DNS-SD, чтобы роль можно было защитить RA Guard. Клиент только с IPv4 находит серверы через mDNS. Сервер перед обработкой IPv4-запроса .local обязан проверить, что источник находится в напрямую подключённой подсети.

Текст пока не завершает модель доверия. В Security Considerations стоит только TODO; раздел про маршрутизаторы SNAC также не написан; имя сервиса для IANA остаётся шаблоном. Нет опубликованных результатов независимых реализаций, совместимости, расхода батареи, эфирного времени, потери запросов или времени переключения. Internet-Draft может измениться, быть заменён или истечь и не является RFC.

Устав DNSSD объясняет более широкую задачу: mDNS хорошо работает в пределах канала, но не масштабирует обнаружение сам по себе на маршрутизируемые и многоканальные сети; расширение области видимости поднимает вопросы безопасности и приватности. ULD пока остаётся в сегменте, однако выбранный сервер влияет на то, какие локальные сервисы видит клиент. Следовательно, незаполненная безопасность относится к архитектуре, а не к редактуре.

Принятие рабочей группой запускает устойчивую публичную работу. Оно не подтверждает внедрение, производительность или безопасность. Теперь IETF должна показать, что перенос обычного обнаружения на unicast уменьшает реальную нагрузку и при этом не делает власть сервера и сбои менее заметными.

Источники