Media Over QUIC C. Jennings Internet-Draft S. Nandakumar Intended status: Standards Track Cisco Expires: 15 February 2027 14 August 2026 DNS and mDNS Discovery for MOQT draft-jennings-moq-discovery-00 Abstract 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. About This Document 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. Status of This Memo 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. Jennings & Nandakumar Expires 15 February 2027 [Page 1] Internet-Draft moq-discovery August 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. SVCB and HTTPS Records for MOQT . . . . . . . . . . . . . . . 3 3.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Record Names . . . . . . . . . . . . . . . . . . . . . . 3 3.2.1. SVCB Record Name . . . . . . . . . . . . . . . . . . 4 3.2.2. HTTPS Record Name . . . . . . . . . . . . . . . . . . 4 3.3. Default ALPN Identifiers . . . . . . . . . . . . . . . . 4 3.4. Automatically Mandatory SvcParamKeys . . . . . . . . . . 5 3.5. Relevant SvcParamKeys . . . . . . . . . . . . . . . . . . 5 3.5.1. alpn and no-default-alpn . . . . . . . . . . . . . . 5 3.5.2. port . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5.3. ech . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5.4. ipv4hint and ipv6hint . . . . . . . . . . . . . . . . 5 3.6. ALPN Selection . . . . . . . . . . . . . . . . . . . . . 5 4. SRV Records for MOQT . . . . . . . . . . . . . . . . . . . . 5 4.1. SRV Record Names . . . . . . . . . . . . . . . . . . . . 6 4.2. Using SRV Target and Port . . . . . . . . . . . . . . . . 6 4.3. Interaction with SVCB . . . . . . . . . . . . . . . . . . 6 5. mDNS and DNS-SD Discovery for MOQT . . . . . . . . . . . . . 6 5.1. DNS-SD Service Names . . . . . . . . . . . . . . . . . . 6 5.2. TXT Record Parameters . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.1. Service Name Registration . . . . . . . . . . . . . . . . 7 7.2. ALPN Registration . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Jennings & Nandakumar Expires 15 February 2027 [Page 2] Internet-Draft moq-discovery August 2026 1. Introduction 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: SVCB and HTTPS records (Section 3): 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. SRV records (Section 4): Unicast DNS records that provide port and target information for load balancing and failover. They carry no ALPN or connection parameters. mDNS and DNS-SD (Section 5): Multicast DNS [RFC6762] and DNS Service Discovery [RFC6763] for local network discovery without a central DNS server. 2. Conventions and Definitions 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. 3. SVCB and HTTPS Records for MOQT 3.1. Record Types MOQT uses two DNS record types: SVCB RRs (RR type 64): For native QUIC MOQT endpoints. Published at a moqt-specific owner name (Section 3.2); carries moqt/moqt-N ALPNs only. HTTPS RRs (RR type 65): 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. 3.2. Record Names Jennings & Nandakumar Expires 15 February 2027 [Page 3] Internet-Draft moq-discovery August 2026 3.2.1. SVCB Record Name For a moqt URI with host H and port P, the SVCB (type 64) owner name is: * _moqt.H when P is 443 or omitted (defaulting to 443). * _P._moqt.H when P is any other value. 3.2.2. HTTPS Record Name 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. 3.3. Default ALPN Identifiers 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. Jennings & Nandakumar Expires 15 February 2027 [Page 4] Internet-Draft moq-discovery August 2026 3.4. Automatically Mandatory SvcParamKeys 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. 3.5. Relevant SvcParamKeys 3.5.1. alpn and no-default-alpn 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. 3.5.2. port 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. 3.5.3. ech 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]). 3.5.4. ipv4hint and ipv6hint MAY be used to provide address hints that reduce DNS round trips. Hints are advisory and do not replace A/AAAA resolution. 3.6. ALPN Selection 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. 4. SRV Records for MOQT SRV records [RFC2782] provide port and target for load balancing and failover but carry no ALPN or connection parameters. Jennings & Nandakumar Expires 15 February 2027 [Page 5] Internet-Draft moq-discovery August 2026 4.1. SRV Record Names 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). 4.2. Using SRV Target and Port 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. 4.3. Interaction with SVCB 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. 5. mDNS and DNS-SD Discovery for MOQT mDNS [RFC6762] and DNS-SD [RFC6763] enable MOQT discovery on local links without a central DNS server. 5.1. DNS-SD Service Names 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]. Jennings & Nandakumar Expires 15 February 2027 [Page 6] Internet-Draft moq-discovery August 2026 5.2. TXT Record Parameters 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. 6. Security Considerations TODO 7. IANA Considerations 7.1. Service Name Registration 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]). 7.2. ALPN Registration 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. 8. References Jennings & Nandakumar Expires 15 February 2027 [Page 7] Internet-Draft moq-discovery August 2026 8.1. Normative References [moq-transport] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet- Draft, draft-ietf-moq-transport-19, 6 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . 8.2. Informative References Jennings & Nandakumar Expires 15 February 2027 [Page 8] Internet-Draft moq-discovery August 2026 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, . Acknowledgments TODO: Acknowledgments to be added. Authors' Addresses Cullen Jennings Cisco Email: fluffy@iii.ca Suhas Nandakumar Cisco Email: snandaku@cisco.com Jennings & Nandakumar Expires 15 February 2027 [Page 9]