Use SVCB with DNS Service Discovery

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 2 September 2025.¶

Copyright Notice

Copyright (c) 2025 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

This document describes the use of Service Binding (SVCB) resource records in the DNS Service Discovery process. The use of SVCB records alongside SRV records during service discovery enables richer metadata exchange, enhancing the ability to identify and select optimal connection parameters. Specifically, SVCB records allow service instances to advertise properties such as Application-Layer Protocol Negotiation (ALPN) identifiers and other endpoint configuration options which streamlines client connections by providing essential information for protocol negotiation and connection setup during the discovery phase.¶

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. Motivation

The DNS Service Discovery, with the SRV and TXT records, provides some metadata about the service instance. The TXT records specifically are designed to give additional information about the service itself. The specific nature of the additional data in TXT records, and how it is to be used, is service-dependent. However, additional properties which are not service-specific, like supported protocols, or privacy requirements which speed up connection establishment and improve user privacy do not fit naturally in this scheme.¶

This documents describes how with the use of SVCB / HTTPS resource records [SVCB] in the DNS service discovery process we can support these non service specific properties such as Application-Layer Protocol Negotiation (ALPN) [ALPN] identifiers and other endpoint configuration options such as Encrypted Client Hello (ECH) [ECH] so that a client can select its preferred options to optimally initiate the connection to the service instance.¶

4. Use of SVCB with Service Instance Resolution

Typically, the DNS-SD [DNSSD] process begins with a client enumerating service instance names using a PTR record query. The result of this PTR query is a list of zero or more PTR records each pointing to a unique service instance. For example, a query for _foo._tcp.example.com might return multiple PTR records, each corresponding to a specific service instances, such as service1._foo._tcp.example.com and service2._foo._tcp.example.com.¶

Once the client identifies the exact service instance it wants to connect to, the client issues an SRV query for the service instance. The SRV record for the service instance includes the hostname of the service instance, the port number on which the service is listening, and priority and weight fields for load balancing or failover. For example, querying the SRV record for service1._foo._tcp.example.com might return a hostname like host1.example.com and a port number, such as 8080.¶

After resolving the SRV record, the client issues A and AAAA queries to map the hostname in the SRV record to an IP address. For example, querying for host1.example.com might return an A record with the IPv4 address 192.0.2.3 or an AAAA record with the IPv6 address 2001:db8::1. Once the IP address is obtained, the client can initiate a connection to the desired service instance using the port number specified in the SRV record.¶

Once the client has resolved the SRV record to identify the hostname and the port of the service instance, and along with or before the A and AAAA queries are issued, the client can issue a query for an SVCB or HTTPS record, depending on the relevant URI scheme the application is using. The client is expected to use "Port Prefix Naming" [SVCB] to encode the port learned from the SRV response, and the scheme from the URI being accessed by the application. If there is no notion of a URI scheme for the application, then SVCB or HTTPS queries SHOULD NOT be made. If the URI scheme is "http" or "https", the client will issue a query for an HTTPS record; and if the port learned from the SRV response is the same as the default port (443), it will leave off the port prefix.¶

service1._foo._tcp.example.com  3600  IN  SRV   (
    0  0  8080  host1.example.com )

_8080.host1.example.com  7200  IN HTTPS  1  .  (
    alpn=h2,h3 )

5. Security Considerations

TODO¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

Appendix A. Acknowledgments

Authors' Addresses