Create SVCB and HTTPS records for a domain name

Last published : Sep 24, 2026
NetScaler DNS now supports Service Binding (SVCB) and HTTPS resource records as defined in RFC 9460. These records allow clients, such as modern browsers, to obtain service binding details directly from DNS responses. This feature reduces connection setup latency, improves performance, and enables faster adoption of secure protocols such as HTTPS and HTTP/2.
Some of the benefits are:
  • Reduced connection latency
  • Improved performance for HTTP-based applications
  • Native support for modern DNS standards
This feature applies to the following:
  • NetScaler 14.1-72.x and above deployments using:
    • Authoritative DNS (ADNS): Records are locally configured and served directly
    • Proxy Mode: Queries are forwarded to backend DNS servers, with responses cached for improved performance
    • Resolver Mode: Acts as a recursive DNS server (end resolver) that resolves domain names by querying root servers, caching results, and traversing the DNS hierarchy
    • Supported across standalone, HA, and cluster configurations.
Notes:
  • HTTPS records are a specialized form of SVCB records and follow the same configuration model.
  • Multiple SVCB/HTTPS records can be configured per domain using priority values.
  • Lower priority values indicate preferred endpoints.
Prerequisites: Before you begin, ensure that your environment meets the following requirements:
  • NetScaler version: 14.1 build 72.x or later
  • DNS feature enabled
  • For DNSSEC use cases, DNSSEC must be configured and enabled
Related information

Configure SVCB and HTTPS records by using CLI

Add an SVCB record:
add dns svcbRec <domain> -priority <value> -targetName <target-domain> -svcbType SVCB
Add an HTTPS record:
add dns svcbRec <domain> -priority <value> -targetName <target-domain> -svcbType HTTPS -alpn h2 -port 443
View configured records:
show dns svcbRec
show dns svcbRec -svcbType HTTPS

Configure SVCB and HTTPS Records by using GUI

  1. Navigate to Traffic Management > DNS > Records > SVCB Records.
  2. Enter the details and click OK.

Limitations

  • Custom parameters: Custom SVCB parameter sets (svcbParamSet) are not supported. Only standard parameters defined in RFC 9460 are supported.
  • Unsupported RFC parameters: Parameters defined in RFCs later than RFC 9460 are not supported, including:
    • dohpath
    • ohttp
    • tls-supported-groups
    • docpath
  • DNS answer logging: DNS answer logging includes only the priority and target name. Service parameters are not logged.

Use cases

You can use this feature to address the following use cases:

Encrypted ClientHello (ECH)

Modern browsers seek to encrypt the TLS ClientHello to prevent exposure of SNI and connection metadata. Without DNS signaling, clients must attempt a connection first to determine ECH support. HTTPS and SVCB records allow servers to advertise ECH capability and related parameters directly through DNS, which enables encrypted handshakes from the first connection.

HTTP/2 and HTTP/3 discovery

Traditionally, clients discover support for HTTP/2 or HTTP/3 only after establishing a connection and negotiating ALPN. With HTTPS and SVCB records, servers can advertise supported protocols, for example, h2 or h3, in DNS, enabling clients to connect by using the most efficient protocol immediately.

QUIC and modern transport bootstrapping

New transports such as QUIC benefit from DNS-based discovery of service endpoints and parameters. SVCB enables clients to learn port information, supported protocols, and service hints before initiating a connection, which reduces connection setup time.

Alternate and optimized service endpoints

Large deployments often run multiple backends, ports, or optimized edge services. Traditional DNS can only return IP addresses. SVCB allows publishing prioritized alternative service endpoints and connection metadata, which helps clients select the best endpoint without relying on redirects or retries.
SVCB AliasMode records, indicated by a priority of 0, act similarly to CNAME records but offer several advantages in many applications:
  • Zone apex aliasing (root domain redirection): CNAME records cannot coexist with other records at the root domain. AliasMode records work like a CNAME but allow redirecting the root domain to a CDN or Cloud Provider without violating DNS standards. This enables MX and TXT/SPF records to coexist and remain functional.
  • Delegating web traffic to a CDN or Cloud Provider: This mode can be used to delegate operational control of a service to a third-party provider.
  • Service-specific redirection: AliasMode can be used to redirect specific, non-default services, such as _8443._https.example.com to backend.example.net.
The target domain for SVCB and HTTPS ServiceMode records can be set to .. This setting specifies that the service parameters, such as ALPN and port, apply directly to the domain name queried. This provides advantages such as apex domain optimization, where all the properties apply to the apex instead of individual subdomains.