Кратко

  • 3 сентября 2026 года IESG вынесла на общественное рассмотрение проект нового устава DNSSD и принимает комментарии до 13 сентября. В объявлении прямо сказано, что решения ещё нет.
  • В проект входят публикация зарегистрированных через SRP имён в mDNS и разрешение конкурирующих обновлений одного имени. Для draft-ietf-dnssd-tsr-03 намечен WGLC в ноябре. TSR помогает обнаружить старую копию у резервного прокси, но не аутентифицирует устройство и не подтверждает работоспособность сервиса.

Устройство регистрирует сервис через первый SRP registrar. Тот одновременно работает advertising proxy и объявляет запись в локальном mDNS. После разделения сети новое обновление попадает ко второму registrar. Адрес изменился, однако первый proxy продолжает распространять прежний RRset.

mDNS видит два несовместимых ответа для одного owner name. Обычная логика сохраняет старый. Для двух самостоятельных устройств это разумно: поздний участник не должен без предупреждения вытеснить существующий принтер или приложение. Но два прокси не представляют двух собственников. Они хранят разные поколения данных одного requester.

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

Сообщение IESG от 3 сентября открыло обсуждение предлагаемого устава DNSSD до 13 сентября. Документ охватывает масштабируемое обнаружение на одном или нескольких каналах, перенос SRP-имён в mDNS и конфликты между обновлениями одного имени.

Это ещё не утверждение. IESG отдельно отмечает отсутствие решения. Ноябрьский WGLC — план, а не достигнутый консенсус. Карточка TSR показывает редакцию 03 как активный Standards Track Internet-Draft. Это не RFC, не выделенный IANA код и не отчёт о внедрении.

RFC 6762 объясняет исходную модель. У Multicast DNS нет единственного authoritative server в локальном сегменте. В отличие от иерархии делегирования в RFC 1034, mDNS зондирует канал и сам разрешает коллизии. RFC 6763 описывает, как DNS-записи представляют типы и экземпляры сервисов.

Позднее появились мосты между областями. RFC 8766 задаёт Discovery Proxy, который публикует через unicast DNS сервисы, найденные в mDNS. RFC 9665 определяет SRP: requester отправляет registrar обновление, привязанное к своему ключу. Проект Advertising Proxy позволяет registrar объявлять эти данные обратно в mDNS.

В результате видимый говорящий больше не является источником истины. Requester создаёт состояние, registrar принимает его, proxy отображает на конкретном канале. Отказ, anycast или новый маршрут могут оставить старое отображение после того, как источник уже выбрал другой registrar.

Редакция 03 TSR предлагает EDNS option Time Since Received для каждого owner name. Поле указывает охваченный набор записей, содержит checksum, связанный с публичным ключом requester, и передаёт время с момента приёма. Получатель переводит offset в локальную абсолютную отметку и сравнивает поколения.

Checksum разделяет источники; время разделяет версии одного источника. Если оба proxy связаны с одним ключом, новое SRP-состояние не должно выглядеть как чужой захват имени. Механизм также сокращает лишние probes и ответы, предотвращает ненужное переименование и не позволяет goodbye от одного proxy удалить данные, которые остаются действительными через другой.

Однако часы не устанавливают право. Задержка влияет на offset. Перезапуск создаёт новую эпоху наблюдения. Потерянная связь между ключом и RRset разрушает основание сравнения. Статусы primary и secondary регулируют дублирование ответов, а не организационное владение именем.

RFC 6891 даёт расширяемую оболочку EDNS. Единый формат координирует байты, но не сертифицирует часы, cache, постоянное состояние или процедуру удаления конкретной реализации.

Граница безопасности остаётся жёсткой. Сам проект TSR предупреждает, что вредоносный узел в том же сегменте способен вмешиваться в конфликты. Даже без TSR он может объявить несовместимые данные и ответить на probe, создав отказ в обслуживании. Нельзя считать mDNS безопасным или приватным. Аутентификацию, авторизацию и секретность должна предоставлять прикладная система либо, в подходящей архитектуре, обнаружение с DNSSEC.

RFC 8882 показывает другую ось: service discovery раскрывает устройства, сервисы и активность. Перенос между каналами увеличивает круг наблюдателей. Самая свежая запись может быть опубликована точно, но в недопустимой административной области.

Проверяемая эксплуатация сохраняет requester и ключ, исходный SRP Update, registrar, advertising proxy, owner name, полный RRset, время приёма и основу часов, checksum, TSR offset, probes, конфликт, выбранную запись, переименование и goodbyes. Затем нужны фактический ответ клиента, выбранный endpoint, результат соединения, прикладная аутентификация и видимый пользователю исход.

Принятое обновление не доказывает, что прежний proxy снял копию. Победа в TSR-сравнении не доказывает доступность endpoint. Соединение не удостоверяет сервис. Прикладная аутентификация не доказывает, что удалённые caches забыли старый адрес.

Удаление проходит тот же путь в обратном направлении. Остановить регистрацию, удалить состояние registrar, увидеть withdrawal каждого proxy, не стереть ещё действительные резервные копии, дождаться TTL и проверить, что старый endpoint больше не получает трафик. Пустая строка в центральной панели не равна исчезновению ответа на другом канале.

Принцип Heng Lu о минимальной начальной спецификации поддерживает узкий общий формат для сравнения копий. Слои реальности не дают смешать возраст, источник, личность и результат. Приоритет работающего кода требует завершать проверку на клиенте и в приложении.

Таким образом, расширение DNSSD — не только вопрос дальности обнаружения. Прокси меняет устройство власти: тот, кто говорит в mDNS, может быть лишь хранителем копии. TSR исправляет порядок копий. Полномочия имени, допустимая область публикации и работа сервиса всё равно требуют независимых решений.

Источники