The IETF is introducing a new type of record for DNS called SVCB/HTTPS. this SVCB/HTTPS record can solve some very important problems and I have been following the advancement of the standard. Today I’ll give you an introduction.

1987 CNAME records

The DNS system first supported CNAME records in 1987 (RFC 1034), which means canonical name in Chinese. For example, we can set the a.example.com record type to CNAME and its value to b.example.com. This way, I am parsing other records of a.example.com (e.g. A/AAAA) and actually getting the value of the record b.example.com. b.example.com is the authoritative domain name for a.example.com. If we set up A/AAAA records for both a.example.com and b.example.com, which one should be used in the query? From the CNAME semantics, the record of b.example.com should prevail. To avoid ambiguity, the standard stipulates that if a domain name sets a CNAME record, no other type of record can be set. All other records are to be based on the domain name pointed to by the CNAME.

This poses a problem, you can’t set a CNAME for the apex domain, which is the root domain. For example, the apex domain name for a.example.com is example.com. Why can’t you set a CNAME for example.com? Because each apex domain name must have an NS type record. Without an NS record there is no way to look up other records for the domain (including CNAME records).

2000 SRV records

SRV records were introduced to the DNS system in 2000 (RFC 2782).SRVs can be seen as a generalized form of MX records and can theoretically be used to discover protocols, ports, weights, etc. of other services.SRV records are structured as follows.

1

_Service._Protocol.Subdomain TTL IN SRV [Priority Weight] [Port] [Destination Domain]

SRV is mainly used in SIP, LDAP and other protocols. In theory, we can also query the SRV record of _http._tcp.example.com to get the domain name and port information of the http service, but few HTTP clients/browsers implement this feature.

2000-2015 Large-scale use of CDNs

From 2000 to 2015, CDN technology was heavily promoted. We only need to set a CNAME record for www.example.com to point to the domain name of the corresponding CDN to achieve global acceleration.

However, if we want to use example.com as the primary domain name (we cannot set a CNAME record), we can.

  • Set up an A/AAAA record for example.com, pointing to the CDN’s IP (hard-coded)
    • This requires the IP to have global anycast capability, otherwise the acceleration will not be accomplished.
  • Let the CDN vendor manage your domain name
    • This is indeed a better approach, but it requires adjusting the business model or cooperative trust relationship, etc.
  • Self-resolution

In summary, we can add a CDN to the root domain, but it’s not very convenient.

2010-2020 Multi-CDN Deployment

Can we assign multiple CDNs to a domain name? Previously, Ali’s server room was tapped out of fiber and affected all CDN customers. So you can’t put all your eggs in one basket.

One way is to set two CNAME records. This is more or less against the return standard, but it works. The other is to set up multiple A/AAAA records. But this requires that the different CDN nodes be interchangeable.

2018 ESNI/ECH

With the increasing popularity of HTTPS/TLS, the privacy issues of the Internet have been greatly alleviated. However, many domains are now deployed in the cloud and share IPs, so it is necessary to negotiate which domain’s certificate to use when establishing a TLS session. To this end, TLS supports an extension called SNI. When a browser initiates a TLS connection it sends the domain name of the target website to the server in explicit text. Someone with an ulterior motive can then monitor the website visited by the user.

Therefore, SNI becomes the last privacy risk of TLS. For this reason, the ESNI scheme has been proposed to encrypt SNI information. The basic principle is to publish a public key (TXT record) through DNS. The browser queries the public key through DNS to encrypt SNI, and then initiates a TLS connection. The earliest encrypted SNI information. At first, we only encrypted SNI information, but later we found that there were still problems, so we simply encrypted all ClientHello information. In this way, the last weak link of TLS is fixed (the standard is still under development).

Different CDNs must use different ECH keys. If you use CDN A’s public key to encrypt and connect to CDN B’s IP, this will definitely fail. Existing DNS systems also do not provide the ability to bind different records together.

Therefore, it is necessary to introduce a new type of record that correlates the IP address of the service, the ECH public key, and other information needed to establish the connection, and that also supports binding the root domain. This new type of record is called Service Binding Record (SVCB).

SVCB record overview

The structure of the SVCB record is as follows.

1

_Port._Protocol.Subdomain TTL IN SVCB [Priority] [Destination Domain] [Service Parameters...]
  • The goal is to speed up the communication connection process with a single DNS query
  • priority == 0 indicates AliasMode
    • Support for binding root domains
  • Priority ! = 0 indicates ServiceMode
    • Service parameters are arbitrary key-value pairs, the main ones are.
      • TLS ALPN prompt message
      • Port
      • ECH configuration information (public key, etc.)
      • IP hints

HTTPS Records Overview

https records are a special class of svcb records that are functionally indistinguishable, but do not require the _https protocol prefix to be specified. Wildcard domains can be better supported. For example *.example.com TTL IN HTTPS ... , accommodates the existing CNAME semantics.

If a domain name has HTTPS records set up, it means that the domain name supports HTTPS/TLS access (similar to HSTS).

The DNS server itself does not make any distinction between SVCB/HTTPS.

Alias Mode AliasMode

The following record points the http service information of example.com to the svc.example.net domain.

1

example.com. 7200 IN HTTPS 0 svc.example.net.

If you are also listening on a non-standard port (e.g. 8443) at example.com, then you should set the following record again

1

_8443._https.example.com. 7200 IN HTTPS 0 svc.example.net.

Service Mode ServiceMode

Here are two HTTPS logs for service mode

1
2

svc.example.net. 7200 IN HTTPS 2 svc3.example.net. alpn=h3 port=8003 ech=...
svc.example.net. 7200 IN HTTPS 3 svc2.example.net. alpn=h2 port=8002 ech=...

This means that you can connect to port 8003 of svc3.example.net using the QUIC protocol or to port 8002 of svc2.example.net using HTTP/2, and that you can encrypt the TLS handshake using the ech message.

DNS Query Flow

  1. Client initiates both A/AAAA and HTTPS records (50% increase in query volume)
  2. If the HTTPS record is in alias mode, then the A/AAAA and HTTPS records for the domain name need to be queried
  3. the client needs to query the A/AAAA record of the target domain in service mode
  4. the DNS recursive resolution server can provide these records through additional fields
  5. Special requirements for ECH records: 1.
  6. the client needs to initiate a TLS connection after receiving the HTTPS query result to prevent the server from enabling ECH
  7. If the HTTPS query times out, the client cannot assume that the server does not support ECH in order to prevent a degradation attack

IP hints

SVCB/HTTPS records can also add so-called IP hints, which have the following effect.

1

@ 7200 IN HTTPS 1 svc.cdn.example ipv4hint=192.0.0.1

IP hints are optional. It is mainly used to speed up the dns resolution process. If the HTTPS record contains an ip hint, the IP address of the target domain can be eliminated.

Current Status

  • IANA has assigned two type IDs, 64/65, to SVCB/HTTPS.
  • draft-ietf-dnsop-svcb-https is nearing completion
  • iOS 14/macOS 11 already partially supports SVCB/HTTPS queries
  • Cloudflare’s CDN and DNS already support SVCB/HTTPS records
  • BIND/PowerDNS/Unbound and other DNS service software are working on corresponding features

Other Random Thoughts

Why am I so concerned about the progress of the SVCB/HTTPS standard? It has to do with the network control in China. As you know, operators in China block standard ports like 80/443, which means you can’t use your home broadband to serve websites. HTTP/1.1 and HTTP/2 can only work on the standard 80 and 443 ports. HTTP/3, however, can work on any port. In other words, you can listen to any port, update the port information to the corresponding HTTPS record, and the supported clients will be able to access the corresponding HTTP/3 content. When the time comes, everyone can use home broadband to provide Internet services to the outside world again. The key is that Apple is very supportive of SVCB/HTTPS, and I believe that SVCB/HTTPS will soon be able to complete the standardization.

Of course, China will continue to control the Internet. When the time comes, it will definitely interfere with SVCB/HTTPS queries. This can only use DNS over HTTPS/TLS to cope with it. The good thing is that the mainstream systems are now accelerating the deployment of DoH/DoT, and with ECH technology, it should be difficult to prevent people from providing network services to the public.