What Is an HTTPS Record

An HTTPS record is a specialized DNS record type that provides connection information for HTTPS services. It enables browsers to connect more efficiently by advertising support for HTTP/3, Encrypted Client Hello (ECH), and providing connection hints -- all in a single DNS query.

How HTTPS Records Work

HTTPS records are a specific use of the more general SVCB (Service Binding) record type:

example.com.    3600    HTTPS    1 . alpn="h3,h2" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

This tells browsers:

• Connect to the same hostname (. = use the query name)
• Server supports HTTP/3 (h3) and HTTP/2 (h2)
• Server IPs are 192.0.2.1 (IPv4) and 2001:db8::1 (IPv6)

Without HTTPS records, a browser connecting to a new site must complete several round trips: a DNS lookup for the A/AAAA record, a TCP handshake, a TLS handshake, and then discover via the Alt-Svc header that HTTP/3 is available. With HTTPS records, the browser learns the protocol support, IP addresses, and encryption parameters all from the initial DNS query.

Benefits of HTTPS Records

1. Faster Connections

Browsers receive all connection parameters in one DNS query instead of multiple round trips. The IP hints in the HTTPS record can eliminate the need for separate A/AAAA lookups.

2. HTTP/3 Discovery

Browsers can attempt HTTP/3 (QUIC) connections immediately, without needing an Alt-Svc header first. This is especially valuable for first-time visitors who have no cached Alt-Svc information.

3. Encrypted Client Hello (ECH)

Enables encrypted SNI to hide which site you're connecting to. When HTTPS records carry ECH configuration, the TLS Client Hello is encrypted so that network observers cannot see the Server Name Indication (SNI) field. This is a significant privacy improvement over standard TLS.

4. No HSTS Preload Required

HTTPS records signal HTTPS-only access without browser preload lists. When a browser sees an HTTPS record for a domain, it knows the domain supports HTTPS and can upgrade the connection without relying on HSTS headers or preload lists.

5. IP Address Hints

Provide IP addresses directly, potentially saving an A/AAAA lookup. This reduces DNS round trips and can improve time-to-first-byte.

Record Components

Priority

• 0 = Alias mode (like CNAME for HTTPS)
• 1-65535 = Service mode (connection parameters)

Target

• . = Same as query name
• Hostname = Redirect to different host

Service Parameters (SvcParams)

ALPN Protocol Values and Priorities

The order of ALPN values indicates preference. alpn="h3,h2" means "prefer HTTP/3, fall back to HTTP/2." Browsers use this to decide which protocol to attempt first:

• h3 first: Browser attempts a QUIC connection immediately. If it fails (e.g., UDP is blocked by a firewall), it falls back to h2 over TCP. This is the recommended configuration.
• h2 only: Browser uses HTTP/2 over TCP. Useful if your infrastructure doesn't support QUIC.
• h3 only with no-default-alpn: Forces HTTP/3 only. Use with caution -- clients that can't use QUIC won't be able to connect.

When listing ALPN values, put your preferred protocol first. Browsers will attempt protocols in the listed order, falling back as needed.

Encrypted Client Hello (ECH) in Detail

ECH is one of the most impactful features enabled by HTTPS records. Without ECH, the TLS Client Hello message is sent in plaintext, revealing the SNI (the hostname you're connecting to) to anyone observing the network. With ECH, the Client Hello is encrypted using a public key published in the HTTPS record:

example.com.    3600    HTTPS    1 . alpn="h3,h2" ech="AEX+DQA..."

The ech parameter contains a base64-encoded ECHConfigList. The browser uses this to encrypt the Client Hello before sending it to the server. The server decrypts it using its private key.

ECH requires HTTPS records -- there is no other standard way to distribute the ECH configuration to browsers. This makes HTTPS records essential for deploying ECH.

For related certificate security considerations, see also CAA records which control certificate issuance.

Common Use Cases

Basic HTTPS Record with HTTP/3

example.com.        3600    HTTPS    1 . alpn="h3,h2"
www.example.com.    3600    HTTPS    1 . alpn="h3,h2"

With IP Address Hints

example.com.    3600    HTTPS    1 . alpn="h3,h2" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

Including IP hints can be useful with anycast deployments where the HTTPS record can publish addresses for the service endpoint. For IPv6 considerations, include both ipv4hint and ipv6hint when your server supports dual stack and your deployment expects clients to use those hints.

Alias Mode (HTTPS CNAME)

Point apex to a CDN without using CNAME:

example.com.    3600    HTTPS    0 cdn.example.net.

This is an alternative to ALIAS records for the apex domain problem. Alias-mode HTTPS records tell the browser to look up HTTPS records for the target hostname instead.

Non-Standard Port

api.example.com.    3600    HTTPS    1 . alpn="h3,h2" port=8443

Multiple Priority Levels (Failover)

example.com.    3600    HTTPS    1 . alpn="h3,h2"
example.com.    3600    HTTPS    2 backup.example.com. alpn="h2"

Lower priority values are preferred. If the primary service (priority 1) is unreachable, the browser falls back to the backup (priority 2). This provides DNS-level failover similar to how MX records prioritize mail servers.

With ECH (Encrypted Client Hello)

example.com.    3600    HTTPS    1 . alpn="h3,h2" ech="AEX+DQA..."

Alias Mode vs Service Mode

Alias Mode (Priority 0)

Works like CNAME but for HTTPS services:

example.com.    HTTPS    0 cdn.example.net.

• Points to another hostname
• Inherits target's HTTPS configuration
• Works at apex domain (unlike CNAME)
• Can coexist with A, AAAA, MX, TXT, and other records

Service Mode (Priority 1+)

Provides direct connection parameters:

example.com.    HTTPS    1 . alpn="h3,h2"

• Specifies connection details
• Can include IP hints
• Multiple records for failover

Record Format

Adding an HTTPS Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter subdomain or @ for apex
   • Type: Select HTTPS
   • Priority: Set priority (1 for primary, 0 for alias mode)
   • Target: Use . for same name or enter target hostname
   • ALPN: Enter protocols (e.g., h3,h2)
   • Port: (Optional) Non-standard port
   • 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 HTTPS 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": "@",
    "type": "HTTPS",
    "content": "1 . alpn=\"h3,h2\"",
    "ttl": 3600
  }'

With IP address 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": "@",
    "type": "HTTPS",
    "content": "1 . alpn=\"h3,h2\" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1",
    "ttl": 3600
  }'

Alias mode (HTTPS CNAME):

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": "@",
    "type": "HTTPS",
    "content": "0 cdn.cloudprovider.com",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "example.com.",
      "type": "HTTPS",
      "content": "1 . alpn=\"h3,h2\" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1",
      "ttl": 3600,
      "disabled": false
    }
  }
}

HTTPS Records and DNS-Based Redirects

HTTPS records complement but do not replace DNS redirects and URL forwarding. An HTTPS record tells a browser how to connect optimally to a service, while an HTTP redirect tells the browser to go to a different URL entirely. You can use both: an HTTPS record to enable HTTP/3 on your primary domain, and web server redirects to handle HTTP-to-HTTPS upgrades or www-to-apex canonicalization.

Best Practices

1. Always include ALPN -- Browsers need protocol information; alpn="h3,h2" is standard

2. Use IP hints for performance -- Saves additional DNS lookups, especially important for global DNS resolution balancing

3. Keep A/AAAA records -- HTTPS records don't replace A/AAAA; maintain both for compatibility with older clients

4. Start with priority 1 -- Use lower numbers for higher priority

5. Test browser support -- Verify with Chrome/Firefox DevTools that HTTPS records are being used

6. Use alias mode for CDN -- Priority 0 is ideal for pointing apex to CDN providers

7. Consider DNSSEC -- HTTPS records carrying ECH configuration should be DNSSEC-signed to prevent tampering

Browser Support

All modern browsers support HTTPS records. Older browsers will simply ignore them and fall back to standard A/AAAA resolution and Alt-Svc header-based protocol discovery.

Testing HTTPS Records

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

Test in browser:

1. Open DevTools (F12)
2. Go to Network tab
3. Look for "Protocol" column showing h3 or h2

If dig HTTPS returns an error on older versions, try dig TYPE65 example.com which queries the same record type by number.

Related Record Types

• SVCB -- General service binding (HTTPS is SVCB for HTTPS)
• A -- IPv4 addresses (still needed)
• AAAA -- IPv6 addresses (still needed)
• CNAME -- Traditional aliasing
• ALIAS -- Apex domain aliasing
• TLSA -- TLS certificate authentication via DNS
• CAA -- Certificate authority authorization
• SSL/TLS Handshake -- How ClientHello, SNI, ALPN, and certificates are negotiated
• DNS Record Types -- Overview of all DNS record types

Conclusion

HTTPS records give supporting clients connection metadata earlier in the request path. By advertising HTTP/3 support, providing connection hints, and enabling Encrypted Client Hello where supported, they can reduce upgrade round trips and enable modern protocols sooner. DNScale's support for HTTPS records lets you manage those parameters alongside the rest of your DNS.