| Internet-Draft | moq-discovery | August 2026 |
| Jennings & Nandakumar | Expires 15 February 2027 | [Page] |
This document defines how MOQT clients discover server endpoints using
DNS and Multicast DNS (mDNS). It specifies SVCB and HTTPS DNS record
mappings for the moqt URI scheme, SRV records as a fallback
mechanism, and DNS-SD over mDNS for local network discovery.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jennings-moq-discovery/.¶
Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/.¶
Source for this draft and an issue tracker can be found at https://github.com/moq-wg/moq-transport.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Media over QUIC Transport (MOQT) protocol [moq-transport] identifies
servers using the moqt URI scheme. Clients establish MOQT sessions over
native QUIC or over WebTransport ([moq-transport], Section 3).¶
This document defines three complementary discovery mechanisms:¶
Unicast DNS records that carry connection parameters — including supported
ALPNs — alongside address records. Section 2.4 of [RFC9460] requires a
mapping document for each URI scheme using SVCB; this document fulfills
that requirement for moqt.¶
Unicast DNS records that provide port and target information for load balancing and failover. They carry no ALPN or connection parameters.¶
Multicast DNS [RFC6762] and DNS Service Discovery [RFC6763] for local network discovery without a central DNS server.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
MOQT uses two DNS record types:¶
For native QUIC MOQT endpoints. Published at a moqt-specific owner
name (Section 3.2); carries moqt/moqt-N ALPNs only.¶
For WebTransport MOQT endpoints. MAY carry both moqt and HTTP ALPN
(h3). moqt URIs using WebTransport map to https
URIs ([moq-transport], Section 3); both schemes default to port 443.¶
For a moqt URI with host H and port P, the SVCB (type 64) owner
name is:¶
For a moqt URI with host H and port P, the HTTPS (type 65) owner
name is:¶
H when P is 443 or omitted (defaulting to 443).¶
_P._https.H when P is any other value, as specified in
[RFC9460], Section 9.1.¶
Unlike https (which implies h2/h3), the moqt URI scheme has no
implicit default ALPN. Every ServiceMode record MUST include an explicit
alpn SvcParamKey listing all supported protocols.¶
The following ALPN identifiers are defined for MOQT:¶
moqt:Native QUIC, published MOQT specification ([RFC7301]). MUST appear in SVCB records; MAY appear in HTTPS records when the server supports both native QUIC and WebTransport.¶
moqt-N (where N is a non-negative integer):Native QUIC, draft version N (e.g., moqt-15). Ephemeral; MUST NOT
be used in production. Same record-placement rules as moqt.¶
h3:WebTransport over HTTP/3 ([moq-transport]). HTTPS records only.¶
A client MUST treat a record whose alpn contains none of its supported
identifiers as unusable and proceed as if no record were present.¶
TODO: Define ALPN identifier and record-placement rules for qmux once the qmux specification matures.¶
The moqt scheme introduces no additional automatically mandatory
SvcParamKeys; standard [RFC9460] processing rules apply. Omitting alpn
is equivalent to publishing a record with no supported protocols
(Section 3.3), which clients will treat as unusable.¶
The alpn SvcParamKey MUST be present in every ServiceMode record
(see Section 3.3). The no-default-alpn SvcParamKey MUST NOT
appear; with no default ALPNs defined, it has no effect and would be
misleading.¶
When present, port specifies the UDP port (native QUIC or WebTransport
over HTTP/3). When absent, the port from the moqt URI is used,
defaulting to 443.¶
ECH [RFC9580] MAY appear in SVCB or HTTPS records. Clients that
support ECH SHOULD use it; without it, the moqt URI authority is
exposed in the TLS SNI extension ([moq-transport]).¶
MAY be used to provide address hints that reduce DNS round trips. Hints are advisory and do not replace A/AAAA resolution.¶
A client uses the alpn SvcParamKey to determine which connection modes
the server supports and connects using any ALPN identifier from the record
that it supports. Selection among multiple supported ALPNs is a matter of
local client policy and is out of scope for this document.¶
SRV records [RFC2782] provide port and target for load balancing and failover but carry no ALPN or connection parameters.¶
For a moqt URI with host H, SRV queries are performed at:¶
_moqt._udp.H (both native QUIC and WebTransport over HTTP/3 use UDP).¶
When SRV records are found:¶
The target hostname and port from the SRV record MUST be used as the connection endpoint.¶
The original moqt URI's host component MUST be used as the TLS
SNI value and for certificate validation; it MUST NOT be replaced by
the SRV target hostname.¶
SRV targets with a port of 0 and a dot (.) target indicate that the
service is not available at this name and MUST be treated as indicating
no service.¶
When SVCB (type 64) or HTTPS (type 65) records are available and usable
for a moqt authority, clients SHOULD prefer them over SRV records and
MAY skip the SRV query entirely.¶
Operators SHOULD publish SVCB and/or HTTPS records rather than (or in addition to) SRV records for new deployments.¶
mDNS [RFC6762] and DNS-SD [RFC6763] enable MOQT discovery on local links without a central DNS server.¶
MOQT uses the following DNS-SD service types, which are also registered for SRV use (Section 7.1):¶
_moqt._udp:Advertises MOQT endpoints (native QUIC and WebTransport over HTTP/3).¶
A MOQT relay on the local network announces itself by publishing PTR,
SRV, and TXT records under the appropriate service type in the .local.
domain, as specified in [RFC6763].¶
The TXT record for a MOQT DNS-SD instance MUST contain the following key-value pair:¶
alpn:The ALPN identifier for the transport mode advertised by this instance
(e.g., moqt, moqt-15, h3).¶
A client MUST treat an instance whose TXT record does not contain a
recognized alpn value as unusable.¶
IANA is requested to register the following entry in the "Service Name and Transport Protocol Port Number Registry":¶
Service Name: moqt¶
Transport Protocol(s): udp¶
Assignee: IETF¶
Contact: moq@ietf.org¶
Description: Media over QUIC Transport¶
Reference: This document and [moq-transport]¶
Port Number: 443¶
This registration covers use of the _moqt._udp service label in SRV
records ([RFC2782]) and DNS-SD ([RFC6763]).¶
The ALPN identifier moqt is already registered in the "TLS Application-
Layer Protocol Negotiation (ALPN) Protocol IDs" registry by [moq-transport].
No additional registrations are requested by this document.¶
TODO: Acknowledgments to be added.¶