Search... ⌘ K
Get Started Contact Sales

What Are Service Binding Records (SVCB and HTTPS)?

Last updated

Table of Contents

What is a service binding?

A service binding is the association between a domain name and the configuration information needed to access a network service at that domain. It provides clients with the necessary details to establish a connection to a service, including where the service is available, which protocols it supports, and what connection parameters to use.

Traditionally, clients would need to make multiple connection attempts or perform additional lookups to discover how to connect to a service. A service binding delivers this information upfront through DNS, allowing clients to make informed decisions about which endpoint to use and how to configure the connection before attempting to connect.

Service bindings enable several important capabilities:

  • Service discovery: Clients can discover alternative endpoints where a service is available
  • Protocol negotiation: Clients can learn which protocols and versions are supported before connecting
  • Connection optimization: Clients receive hints about connection parameters (ports, IP addresses) to reduce lookup overhead
  • Domain aliasing: Domain owners can redirect clients to alternative domains for specific services

What are service binding records?

Service Binding records are a pair of DNS record types standardized in RFC 9460 that provide service binding information for network services. They deliver configuration information and parameters to clients before they establish a connection to a service, enabling performance improvements, privacy benefits, and protocol optimization.

The two record types are:

  • SVCB records (record type 64): Service Binding records for any service type
  • HTTPS records (record type 65): Service Binding records specifically optimized for HTTP/HTTPS services

Both record types share the same structure. HTTPS records add rules specific to HTTP, and use a simpler naming format.

How service binding records work

Service binding records provide clients with complete instructions for accessing network services. When a client queries for a service binding record, it receives information about:

  • Alternative endpoints where the service is available
  • Transport protocol configurations (e.g., supported protocols, ports)
  • Connection parameters that optimize the connection process
  • Alias targets for domain name redirection

This information allows clients to make more informed decisions about which server to connect to and how to establish the connection, reducing unnecessary connection attempts and improving overall performance.

SVCB vs HTTPS: The key difference

The most visible difference between SVCB and HTTPS records is the naming format:

SVCB Records (Type 64)

SVCB record names start with one or more labels beginning with an underscore, which identify the service. The exact format is defined by each service’s specification. RFC 9460 uses the scheme name, with the port in front of it for non-default ports, for example _8443._foo.api.example.com. DNSimple’s record editor suggests the _port._protocol form, such as _443._tcp.

Example:

_example._tcp.example.com.  3600  IN  SVCB  1  server.example.com.  port=8443

Note

SVCB records with underscore-prefixed names, such as _443._tcp.example.com, may create Empty Non-Terminals (ENTs) at intermediate names like _tcp.example.com. If you are using wildcard records, this may affect DNS resolution. Learn more about wildcards and ENTs.

HTTPS Records (Type 65)

HTTPS records are implicitly associated with HTTP/HTTPS services and use the hostname itself, for example example.com or www.example.com. No prefix is needed for the default port, 443. For a non-standard port, put the port and _https in front of the hostname, for example _8443._https.example.com.

Example:

example.com.  3600  IN  HTTPS  1  example.com.  alpn=h2,h3  port=443

When to use which

  • Use HTTPS records for HTTP/HTTPS services (most common use case). The simpler naming format makes them easier to configure and understand.
  • Use SVCB records for:
    • Custom services that are not HTTP/HTTPS
    • Services that benefit from explicit service and protocol specification
    • Future extensibility as new service types are defined

Service binding record modes

Both SVCB and HTTPS records operate in two distinct modes based on the priority value:

AliasMode (Priority 0)

When a service binding record has a priority value of 0, it operates in AliasMode. In this mode, the record functions similarly to a CNAME record, redirecting the query to another domain name. However, unlike CNAME records, service binding records can be used at the apex domain (the root domain, for example example.com), which CNAME records cannot. Clients that do not support service binding records ignore them, so keep A and AAAA records (or an ALIAS record) at the apex as well.

HTTPS example:

example.com.  3600  IN  HTTPS  0  example.net.

SVCB example:

_example._tcp.example.com.  3600  IN  SVCB  0  example.net.

Both records indicate that the source domain should be treated as an alias for example.net for the specified service.

ServiceMode (Priority > 0)

When a service binding record has a priority value greater than 0, it operates in ServiceMode. In this mode, the record provides information about alternative endpoints where the service is available, along with associated service parameters.

HTTPS example:

example.com.  3600  IN  HTTPS  1  example.com.  alpn=h2,h3  port=443

SVCB example:

_example._tcp.example.com.  3600  IN  SVCB  1  server1.example.com.  port=8443
_example._tcp.example.com.  3600  IN  SVCB  2  server2.example.com.  port=8443

These records indicate alternative endpoints with different priorities. Clients will try endpoints in order of priority (lower numbers first).

Service binding record structure

Both SVCB and HTTPS records contain three main components:

  1. SvcPriority: A 16-bit priority value (0-65535). Lower values are preferred, similar to MX records. A priority of 0 indicates AliasMode.
  2. TargetName: The fully-qualified domain name (FQDN) of either an alias target (AliasMode) or alternative endpoint (ServiceMode). This must be a hostname, not an IP address.
  3. SvcParams: Optional service parameters in key=value format that provide additional configuration information.

Common service parameters

  • alpn: Lists supported Application-Layer Protocol Negotiation (ALPN) protocols (e.g., h2 for HTTP/2, h3 for HTTP/3). Primarily used with HTTPS records.
  • port: Specifies the port number for the service
  • ipv4hint: Provides IPv4 address hints to avoid additional DNS lookups
  • ipv6hint: Provides IPv6 address hints to avoid additional DNS lookups
  • mandatory: Lists service parameters that must be understood by the client
  • ech: Encrypted ClientHello configuration (for TLS)

Benefits of service binding records

Performance improvements

Service binding records allow clients to avoid connecting to suboptimal servers by providing information about alternative endpoints and their capabilities upfront. This reduces failed connection attempts and improves overall connection efficiency.

Privacy benefits

Service binding records can carry an ech parameter, which lets clients use Encrypted ClientHello. That hides the name of the site being visited from observers on the network.

Protocol optimization

Service binding records can specify supported transport protocols and connection parameters, allowing clients to select the most appropriate protocol and configuration for their needs. For HTTPS records, this lets browsers upgrade http:// requests to HTTPS, and discover HTTP/3 support before connecting.

Apex domain aliasing

Unlike CNAME records, which cannot exist at the apex domain, service binding records in AliasMode can be used at the root domain. This enables apex domain aliasing, allowing domain owners to redirect their root domain to another domain for specific services.

Service delegation

Service binding records provide a standardized mechanism for service delegation, allowing service providers to publish information about where services are available and how to connect to them, independent of the underlying IP addresses.

Limitations and considerations

Zone structures with multiple aliases

Keep chains of aliases (service binding records in AliasMode) short. Each client and resolver sets its own limit on how many aliases it follows, so a long chain may fail for some of them (RFC 9460, Section 2.4.2). Similar to CNAME chains, each alias also adds a DNS lookup, which slows down resolution.

If your zone structure needs several aliases in a row, consider alternative approaches such as:

  • Restructuring your DNS zone to reduce the number of alias hops
  • Using A records or AAAA records for direct IP address mapping where possible
  • Consolidating multiple aliases into a single target where appropriate

Use cases

HTTPS records

HTTPS records are ideal for:

  • HTTP/HTTPS websites and APIs
  • Enabling HTTP/2 and HTTP/3 support
  • Apex domain aliasing for HTTP/HTTPS services
  • HTTP-to-HTTPS upgrades

SVCB records

SVCB records are ideal for:

  • Custom services that need service binding information but are not HTTP/HTTPS
  • Protocol-specific services that benefit from explicit service and protocol specification
  • Service discovery scenarios where clients need to find alternative endpoints
  • Apex domain aliasing for non-HTTP services
  • Future extensibility as new service parameters are defined

Adding and managing service binding records

DNS hosting at DNSimple supports creating and managing SVCB and HTTPS records in the record editor.

Record Editor features

The record editor offers two tabs for SVCB and HTTPS records:

  • : separate fields for (SvcPriority), (TargetName), and (SvcParams).
  • : a single field for the complete record content. This is useful for pasting records from other sources.

Validation

The Record Editor includes validation per RFC 9460 to ensure records are correctly formatted:

  • SvcPriority validation: Ensures priority values are within the valid range (0-65535)
  • TargetName validation: Validates that the target name is a valid hostname or .
  • SvcParams validation: Validates service parameters, including:
    • Standard keys (mandatory, alpn, no-default-alpn, port, ipv4hint, ipv6hint, ech)
    • Generic keys using the keyNNNNN format
    • Proper formatting and value ranges for each parameter type

Live preview

As you type in the record editor, a live preview updates to show how the record will appear, helping you verify the configuration before saving.

API support

SVCB and HTTPS records are fully supported through the DNSimple API, allowing you to programmatically create, update, and manage these records. For more information, see the DNSimple API documentation.

For step-by-step instructions on how to add, update, and remove service binding records (SVCB and HTTPS) in DNSimple using the record editor, please refer to our dedicated How-To Guide: Manage Service Binding Records (SVCB and HTTPS). This guide covers configuring priority values, target hostnames, service parameters, and the naming format requirements for both record types.

Integrated DNS Provider support

SVCB and HTTPS records are supported for syncing and management with the following Integrated DNS Providers:

  • Route 53: Full SVCB/HTTPS sync support. Records created in DNSimple can be synced to Route 53, and records in Route 53 can be imported and managed through DNSimple.
  • CoreDNS: Full SVCB/HTTPS sync support. Records configured in DNSimple can be synced to CoreDNS instances.

Note

Azure DNS: Azure DNS does not support SVCB/HTTPS records. If you are using Azure DNS as an Integrated DNS Provider, SVCB/HTTPS records cannot be synced to Azure DNS zones.

For more information about Integrated DNS Providers, see:

Comparing service binding records with other record types

If you are trying to decide between HTTPS records and other record types, these comparison articles may help:

Specification

The specification for service binding records (SVCB and HTTPS) is formally defined in RFC 9460.

Have more questions?

If you have additional questions or need any assistance with service binding records, just contact support, and we will be happy to help.