What Is an SVCB Record

An SVCB (Service Binding) record is a general-purpose DNS record type that provides connection parameters for services whose clients understand SVCB. It enables those clients to discover service endpoints along with their configuration -- protocol versions, ports, and IP hints -- in a single DNS query.

How SVCB Records Work

SVCB records provide a flexible framework for service discovery:

_myservice._tcp.example.com.    3600    SVCB    1 . alpn="myproto" port=8080

This tells clients: "To connect to myservice over TCP, use protocol 'myproto' on port 8080."

Unlike SRV records, which only provide a target hostname, port, and priority, SVCB records carry additional parameters like protocol negotiation (ALPN), IP address hints, and Encrypted Client Hello (ECH) configuration. This makes SVCB suitable for modern protocol discovery where a single DNS lookup should provide everything a client needs to establish a connection.

SVCB vs HTTPS Records

HTTPS records are essentially SVCB records with a predefined scheme (https). The record format is identical -- an HTTPS record is technically SVCB type 65, while the generic SVCB is type 64. If you are configuring service binding for a web service, use HTTPS records. For everything else, use SVCB.

Record Components

Priority

• 0 = Alias mode (redirect to another name)
• 1-65535 = Service mode (provide connection parameters)

Target

• . = Use the query name
• hostname = Use a different host

Service Parameters (SvcParams)

The alpn (Application-Layer Protocol Negotiation) parameter is particularly important. It tells the client which application protocol to use when connecting, enabling protocol upgrades without additional round trips. This is the same ALPN mechanism used in TLS negotiation, but advertised via DNS instead of requiring a TLS handshake first.

Common Use Cases

Custom Application Protocol

_myapp._tcp.example.com.    3600    SVCB    1 . alpn="myproto/1.0" port=9000

DoH (DNS over HTTPS)

_dns.example.com.    3600    SVCB    1 . alpn="h2" port=443 dohpath="/dns-query"

DNS-over-HTTPS is one of the primary use cases driving SVCB adoption. The dohpath parameter tells clients where to find the DoH endpoint, enabling automated DoH discovery through DNS. This connects to broader DNS security improvements.

DoT (DNS over TLS)

_dns.example.com.    3600    SVCB    1 . alpn="dot" port=853

WebSocket Service

_websocket._tcp.example.com.    3600    SVCB    1 ws.example.com. alpn="h2,h3" port=443

Service with Multiple Endpoints

_api._tcp.example.com.    3600    SVCB    1 api1.example.com. port=443
_api._tcp.example.com.    3600    SVCB    2 api2.example.com. port=443
_api._tcp.example.com.    3600    SVCB    3 backup.example.com. port=8443

Alias Mode (Service CNAME)

_service._tcp.example.com.    3600    SVCB    0 _service._tcp.provider.com.

This is similar to a CNAME record but specifically for service binding. Unlike CNAME, alias-mode SVCB can coexist with other record types at the same name.

Encrypted Client Hello (ECH) Support

SVCB records can carry ECH configuration, which encrypts the TLS Client Hello message to hide the Server Name Indication (SNI). Without ECH, an observer can see which website you're connecting to even when the connection itself is encrypted.

_myservice._tcp.example.com.    3600    SVCB    1 . alpn="myproto" ech="AEX+DQA..."

The ech parameter contains a base64-encoded ECHConfigList that the client uses to encrypt the initial TLS handshake. This is a significant privacy improvement and is being deployed alongside SVCB/HTTPS records across major browsers and services.

Record Format

Adding an SVCB Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter the service name (e.g., _myservice._tcp)
   • Type: Select SVCB
   • Priority: Set priority (1 for primary, 0 for alias mode)
   • Target: Use . for same name or enter target hostname
   • ALPN: Enter protocols (optional)
   • Port: Enter service port (optional)
   • IPv4 Hint: (Optional) IPv4 address
   • IPv6 Hint: (Optional) IPv6 address
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create a basic SVCB record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_myservice._tcp",
    "type": "SVCB",
    "content": "1 . port=9000",
    "ttl": 3600
  }'

With ALPN and IP hints:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_api._tcp",
    "type": "SVCB",
    "content": "1 . alpn=\"myproto\" port=8443 ipv4hint=192.0.2.1",
    "ttl": 3600
  }'

Multiple priorities for failover:

# Primary endpoint
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_service._tcp",
    "type": "SVCB",
    "content": "1 primary.example.com. port=443",
    "ttl": 3600
  }'
 
# Backup endpoint
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_service._tcp",
    "type": "SVCB",
    "content": "2 backup.example.com. port=443",
    "ttl": 3600
  }'

Alias mode:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_myservice._tcp",
    "type": "SVCB",
    "content": "0 _myservice._tcp.provider.com",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "_myservice._tcp.example.com.",
      "type": "SVCB",
      "content": "1 . alpn=\"myproto\" port=8443",
      "ttl": 3600,
      "disabled": false
    }
  }
}

Priority and Failover

SVCB records with different priorities enable failover:

_service._tcp.example.com.    SVCB    1 primary.example.com. port=443
_service._tcp.example.com.    SVCB    2 secondary.example.com. port=443
_service._tcp.example.com.    SVCB    10 backup.example.com. port=8443

• Clients try priority 1 first
• If unavailable, try priority 2
• Priority 10 is last resort

Same priority = client chooses randomly (load balancing). This is similar to how MX records use priority for email routing, but with richer connection parameters.

For high-availability configurations across multiple providers, see Multi-Provider DNS Deployment.

SVCB Naming Conventions

For services following RFC conventions:

_service._protocol.domain
 
Examples:
_https._tcp.example.com.     ; HTTPS (though HTTPS record is preferred)
_imaps._tcp.example.com.     ; IMAPS
_submissions._tcp.example.com. ; SMTP submission
_dns._udp.example.com.       ; DNS over UDP

Alias Mode vs Service Mode

Alias Mode (Priority 0)

Redirects to another SVCB/HTTPS record:

_service._tcp.example.com.    SVCB    0 _service._tcp.provider.com.

• Like CNAME, but for service binding
• No parameters allowed
• Must have a target hostname
• Can coexist with other records (unlike CNAME)

Service Mode (Priority 1+)

Provides direct service parameters:

_service._tcp.example.com.    SVCB    1 . port=8080

• Contains connection details
• Can use . for same name
• Supports all parameters

SVCB vs SRV Records

SRV records have been the traditional DNS mechanism for service discovery, but SVCB improves upon them in several ways:

SRV records remain the right choice for legacy protocols that expect them (SIP, XMPP, LDAP). For new protocol deployments, SVCB is preferred.

Best Practices

1. Use HTTPS record for web -- For HTTP/HTTPS services, use the HTTPS record type instead of SVCB

2. Include essential parameters -- At minimum, specify port if non-standard

3. Plan for failover -- Use multiple priorities for high availability

4. Keep A/AAAA records -- SVCB supplements but doesn't replace address records

5. Use IP hints for performance -- Reduce DNS round trips with ipv4hint/ipv6hint, especially useful with anycast deployments

6. Follow naming conventions -- Use _service._protocol.domain format

Testing SVCB Records

# Query SVCB records
dig SVCB _myservice._tcp.example.com
 
# With detailed output
dig SVCB _myservice._tcp.example.com +short
 
# Check specific nameserver
dig SVCB _myservice._tcp.example.com @ns1.dnscale.eu
 
# Verify DNSSEC on SVCB responses
dig +dnssec SVCB _myservice._tcp.example.com

Some older versions of dig may not understand the SVCB record type. If dig SVCB returns an error, try dig TYPE64 instead, which queries the same record type by number.

Related Record Types

• HTTPS -- SVCB specifically for HTTPS
• SRV -- Legacy service discovery
• A -- IPv4 addresses
• AAAA -- IPv6 addresses
• CNAME -- Domain aliasing
• ALIAS -- Apex domain aliasing
• TLSA -- TLS certificate authentication via DNS
• SSL/TLS Handshake -- How SNI, ALPN, and certificates are negotiated
• DNS Record Types -- Overview of all DNS record types

Conclusion

SVCB records provide a modern, flexible framework for service discovery that goes beyond traditional SRV records. With support for protocol negotiation, port specification, IP hints, and Encrypted Client Hello, SVCB can help supporting clients connect more efficiently. While HTTPS records are preferred for web services, SVCB is useful for custom protocols and non-HTTP services that explicitly define how clients should consume it. DNScale lets you configure SVCB parameters alongside your other DNS records.