Кратко

  • 5 сентября редакция 01 DNS and mDNS Discovery for MOQT добавила нормализацию URI и подробные правила сопоставления сертификатов X.509. Редакция 02 поменяла только ссылку на исходный репозиторий.
  • После перенаправления через SVCB или SRV TLS по-прежнему проверяет authority исходного moqt URI, а не имя целевого хоста. Для найденного через mDNS _moqt._udp проект пока не определяет, как получить доверенную reference identity и кто уполномочивает объявителя; Security Considerations всё ещё состоят из TODO.

На временной площадке ретранслятор может появиться в списке сервисов до того, как оператор успеет раздать настройки. PTR называет экземпляр, SRV сообщает хост и порт, TXT предлагает alpn=moqt. Клиент уже знает, куда послать первый пакет. Он ещё не знает, принадлежит ли устройство площадке и вправе ли оно обслуживать нужный медиапоток.

Запись Datatracker датирует текущую редакцию 5 сентября 2026 года. Это индивидуальный Internet-Draft: у записи нет IETF stream и intended standard level. В шапке указан предполагаемый Standards Track, обсуждение идёт в списке Media over QUIC. Эти признаки не означают принятие рабочей группой, консенсус или одобрение.

Событие видно в сравнении версий. Редакция 00 в августе уже предлагала SVCB, HTTPS, SRV и локальный DNS-SD. Редакция 01 добавила контракт идентичности. Редакция 02 позже в тот же день исправила только адрес GitHub. Сообщение I-D относится к уточнённому рабочему документу, а не к RFC, реализации или внедрению.

Точка соединения не получает имя принципала

Для нативного MOQT поверх QUIC проект применяет SVCB, для WebTransport — HTTPS, а SRV оставляет запасным вариантом. SVCB и HTTPS способны передать ALPN и параметры соединения; SRV даёт лишь цель и порт. Найденная цель определяет, куда подключится сокет.

Редакция 01 не позволяет ей определять, кому доверять. В SNI и проверке сертификата остаётся хост исходного moqt URI. Имя, возникшее при разрешении, — промежуточный локатор, а не новая authority сервиса.

Так же устроен RFC 9460: альтернативная точка SVCB/HTTPS не меняет origin authority. RFC 9525 требует строить reference identifier из настроенного или безопасно полученного ввода. Промежуточные DNS-имена нельзя автоматически использовать как новую проверочную идентичность.

Новый раздел точно задаёт сравнение. Регистр и percent-encoding нормализуются по RFC 3986, отсутствующий порт становится 443, финальная точка удаляется, международные имена переводятся в IDNA по RFC 5890. Wildcard и CN-ID запрещены. Допустимы соответствующие формы subjectAltName, включая SRVName из RFC 4985.

Это полезное ограничение полномочий DNS. Но оно начинается с уже известного исходного URI. При browsing локальных сервисов первым объектом может быть объявленный экземпляр, а источник доверенной URI ещё не определён.

Локальный источник — топологический факт, не мандат

В mDNS ретранслятор публикует PTR, SRV и TXT в .local. Проверки адреса источника и IP TTL из RFC 6762 помогают отсечь удалённый пакет, притворяющийся локальным. Враждебное устройство на том же канале удовлетворяет топологическому условию.

RFC прямо говорит, что разрешение конфликтов mDNS предполагает сотрудничающих участников без центральной власти. В недоверенной среде нужны дополнительные криптографические механизмы. .local не несёт глобальной authority. RFC 6763 описывает структуру DNS-SD и рекомендует DNSSEC, когда важна аутентичность; он не выдаёт организационных полномочий тому, кто создал запись.

MOQT-проект требует узнаваемого ALPN в TXT. Это фильтр совместимости, но не удостоверение оператора. В текущем тексте Security Considerations — только TODO. Не определено и то, как найденный экземпляр получает исходный moqt URI для X.509-проверки и какая локальная политика разрешает ему рекламировать сервис.

Реализация может добавить заранее заданную конфигурацию, pinning, подписанный домен обнаружения или явное подтверждение. Пробел в draft не доказывает уязвимость или атаку. Он означает, что найденная запись должна оставаться кандидатом, пока отдельная политика не создаст доверие.

TLS не распоряжается namespace

MOQT Transport 20 опирается на QUIC или WebTransport для защиты транспорта. Право подписываться, публиковать и использовать namespace остаётся у приложения или схемы авторизации. Валидный сертификат подтверждает имя в заданной модели доверия, но не право представлять мероприятие, читать закрытый контент или публиковать конкретный track.

Нужно хранить раздельные квитанции: объявление, интерфейс, происхождение с канала, выбранную цель, исходный URI, результат X.509, локальное правило доверия, авторизацию namespace, сессию и наблюдаемый медиарезультат. Статус «ретранслятор найден» склеивает решения разных владельцев.

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

Источники

  1. Запись IETF Datatracker
  2. MOQT Discovery, редакция 02
  3. Редакция 01
  4. Редакция 00
  5. I-D-анонс редакции 02
  6. MOQT Transport, редакция 20
  7. RFC 9460: SVCB и HTTPS
  8. RFC 6762: Multicast DNS
  9. RFC 6763: DNS-Based Service Discovery
  10. RFC 9525: идентичность сервиса в TLS
  11. RFC 4985: SRVName
  12. RFC 3986: синтаксис URI
  13. RFC 5890: IDNA
  14. Heng Lu: минимальная исходная спецификация
  15. Heng Lu: слои реальности
  16. Heng Lu: приоритет работающего кода