Zusammenfassung

  • Revision 01 von DNS and mDNS Discovery for MOQT ergänzte am 5. September URI-Normalisierung und detaillierte X.509-Abgleiche. Revision 02 änderte danach nur den Link zum Quellrepository.
  • Führt SVCB oder SRV zu einem anderen Zielhost, bleibt die Authority der ursprünglichen moqt-URI die TLS-Identität. Für eine über mDNS gefundene _moqt._udp-Instanz definiert der Entwurf hingegen noch weder die vertrauenswürdige Referenzidentität noch die Befugnis des Ankündigers; die Security Considerations bestehen weiter nur aus TODO.

In einem Produktions-LAN kann ein Relay schneller im Dienstbrowser auftauchen, als ein Techniker seine Inventarliste öffnet. PTR liefert den Instanznamen, SRV Host und Port, TXT ein erkanntes alpn=moqt. Damit ist ein Kandidat auffindbar. Nicht auffindbar ist der Auftrag, für die Organisation oder den gewünschten Medienstrom zu sprechen.

Der Datatracker-Datensatz datiert den aktuellen Stand auf den 5. September 2026. Der Dokumentname kennzeichnet einen individuellen Internet-Draft; IETF stream und intended standard level sind dort nicht gesetzt. Der Kopf nennt Standards Track als Ziel und die Media-over-QUIC-Liste als Diskussionsort. Das ist keine WG-Adoption, kein Konsens und keine Billigung.

Die Versionsfolge begrenzt die Nachricht. Revision 00 beschrieb im August bereits SVCB, HTTPS, SRV und lokale DNS-SD. Revision 01 fügte die Identitätsregeln hinzu. Revision 02 korrigierte später am selben Tag ausschließlich die GitHub-Adresse. Die I-D-Ankündigung meldet deshalb einen präzisierten Arbeitsstand, keine Standardisierung oder Implementierung.

Ein DNS-Ziel wird nicht zum Dienstherrn

Für natives MOQT über QUIC sieht der Draft SVCB vor, für WebTransport HTTPS, als einfacheren Rückfall SRV. SVCB und HTTPS können ALPN und weitere Verbindungsparameter tragen. SRV liefert nur Ziel und Port. Das ausgewählte Ziel darf den Socket annehmen.

Revision 01 verweigert ihm jedoch die automatische Identität. SNI und Zertifikatsprüfung verwenden weiter den Host der ursprünglichen moqt-URI. Der aufgelöste Name ist ein Zwischenwert der Wegwahl. Er wird nicht zum Principal, nur weil DNS ihn näher an die Verbindung gebracht hat.

Der RFC 9460 zieht dieselbe Grenze für SVCB/HTTPS: alternative Endpunkte ändern die Origin-Authority nicht. RFC 9525 unterscheidet entsprechend zwischen einem Reference Identifier aus sicherem oder konfiguriertem Eingang und den Namen, die während einer DNS-Auflösung auftauchen.

Der neue Text macht auch den Vergleich enger. Groß-/Kleinschreibung und Prozentkodierung werden nach RFC 3986 normalisiert, ein fehlender Port wird zu 443, der abschließende Punkt entfällt und internationale Namen werden nach RFC 5890 in IDNA überführt. Wildcards und CN-ID sind ausgeschlossen. Zulässig sind passende subjectAltName-Formen einschließlich SRVName aus RFC 4985.

Damit kann DNS nicht zugleich Anschlussort und Prüfidentität bestimmen. Die Regel setzt aber voraus, dass eine ursprüngliche URI schon vorhanden ist. Beim Browsen lokaler Dienste ist gerade diese Herkunft noch zu klären.

Lokalität ist Topologie, keine Organisationszugehörigkeit

Im mDNS-Pfad veröffentlicht ein Relay PTR, SRV und TXT unter .local. Die Quelladress- und TTL-Prüfung aus RFC 6762 kann eine von außerhalb des Links eingeschleuste Antwort verwerfen. Ein gegnerisches Gerät auf demselben Link erfüllt die topologische Bedingung ebenfalls.

Der RFC beschreibt Namenskonflikte als Kooperation ohne zentrale Instanz. Sind Teilnehmer nicht durchweg vertrauenswürdig, werden zusätzliche kryptografische Verfahren nötig. .local trägt keine globale Autorität. RFC 6763 ordnet die DNS-SD-Records und empfiehlt DNSSEC, wenn Authentizität wichtig ist; aus einer syntaktisch gültigen Anzeige wird dadurch noch kein institutionelles Mandat.

Der MOQT-Entwurf verlangt im TXT einen erkannten ALPN-Wert. Das beseitigt ein unbrauchbares Protokollangebot, nicht einen unbefugten Anbieter. Seine Security Considerations enthalten derzeit nur TODO. Auch der Übergang von der gebrowsten Instanz zur ursprünglichen moqt-URI und zur lokalen Zulassungspolitik ist noch nicht definiert.

Eine Implementierung kann Vorabkonfiguration, Pinning, eine signierte Discovery-Domain oder bewusste Bestätigung ergänzen. Das ist kein Beleg für eine Schwachstelle oder einen Angriff. Es ist ein Grund, Discovery bis dahin als Kandidatenquelle und nicht als Trust-Entscheidung zu behandeln.

Nach TLS beginnt die Medienberechtigung

MOQT Transport 20 stützt Transportschutz auf QUIC oder WebTransport. Abonnement-, Veröffentlichungs- und Namespace-Rechte bleiben Sache der Anwendung beziehungsweise des Autorisierungsverfahrens. Ein passendes Zertifikat sagt nicht, dass das Relay diesen Track veröffentlichen, geschützte Inhalte lesen oder eine Veranstaltung vertreten darf.

Eine belastbare Spur hält Anzeige, Interface, Link-Herkunft, gewähltes Ziel, ursprüngliche URI, X.509-Ergebnis, lokale Trust-Regel, Namespace-Berechtigung, Sitzung und beobachtetes Medium getrennt. „Relay entdeckt“ ist kein Sammelbeleg.

Heng Lus Minimum Initial Specification spricht für das schmale gemeinsame Invariant, das der Draft bereits besitzt: Indirektion ändert keine Authority. Die Reality Layers trennen Ankündigung, Identität, Erlaubnis und Wirkung. Running-Code Primacy verlangt schließlich die Beobachtung, welchen Namen und welche Regel ein echter Client tatsächlich nutzte.

Quellen

  1. IETF-Datatracker-Datensatz
  2. MOQT Discovery, Revision 02
  3. Revision 01
  4. Revision 00
  5. I-D-Ankündigung zu Revision 02
  6. MOQT Transport, Revision 20
  7. RFC 9460: SVCB und HTTPS
  8. RFC 6762: Multicast DNS
  9. RFC 6763: DNS-Based Service Discovery
  10. RFC 9525: Dienstidentität in TLS
  11. RFC 4985: SRVName
  12. RFC 3986: URI-Syntax
  13. RFC 5890: IDNA
  14. Heng Lu: Minimum Initial Specification
  15. Heng Lu: Reality Layers
  16. Heng Lu: Running-Code Primacy