Before showing a page, a browser looks up the IP, connects, negotiates encryption and only then requests content. It often learns that a server supports HTTP/3, or that the site is HTTPS-only, after that first connection. SVCB and HTTPS records, standardised in 2023 as RFC 9460, put this information in DNS so the browser knows it up front, which can make the first connection faster and safer.
SVCB versus HTTPS
SVCB ("service binding") is a generic record type for any service. HTTPS is its web-specific form with the same format, used for https sites without an extra name prefix. Site owners almost always work with HTTPS records. Each record has a priority, a target name and parameters. Priority 0 is AliasMode, which only points to another name; priority 1 or higher is ServiceMode, which carries connection parameters. A target of "." means "this same name". You can publish several ServiceMode records for one name with different priorities, for example a primary endpoint and a backup on another host; clients try the lowest priority number first.
What it looks like
example.uz. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
misol.uz. 3600 IN HTTPS 0 cdn.example.net.alpn lists supported protocols (h3 for HTTP/3, h2 for HTTP/2), port sets a non-standard port, and ipv4hint/ipv6hint let the client start connecting before A and AAAA answers arrive. ech distributes keys for Encrypted Client Hello. AliasMode at the apex is attractive because CNAME is not allowed there, but browser support for it is still uneven.
Why it helps
Without the record, browsers learn about HTTP/3 from the Alt-Svc header and switch to QUIC only on later requests; with it they can try HTTP/3 on the very first connection, which matters on lossy mobile networks. Per the standard, a client that sees an HTTPS record should upgrade http:// to https:// automatically, much like HSTS. And ECH keys are only distributed this way.
Example: an online course platform
A Tashkent e-learning platform serving mostly mobile users already had HTTP/3 enabled in Nginx, yet almost all first visits stayed on HTTP/2. After confirming HTTP/3 worked, the administrator published an HTTPS record with alpn="h3,h2", and supporting browsers began using HTTP/3 from the first connection.
server {
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
server_name example.uz;
add_header Alt-Svc 'h3=":443"; ma=86400';
}HTTP/3 runs over UDP, so open it in the firewall with sudo ufw allow 443/udp, or the record promises something the server cannot deliver.
Risks of getting it wrong
Because the record triggers automatic HTTPS upgrades, any name without a working certificate, or a subdomain that only serves HTTP, will stop opening in supporting browsers. Hints go stale easily: when the server IP changes you update A but forget ipv4hint, and browsers waste time on the old address. If IPs change often, leave hints out; they are optional. Advertising a protocol in alpn that the server does not speak forces a fallback and slows the first connection instead of speeding it up.
Adding and checking the record
Not every DNS panel supports this newer type, and some CDNs publish it automatically. Check whether it is available in the DNS section of the sayt.uz cabinet or ask support. Older dig builds may need the numeric type:
dig example.uz HTTPS +short
dig example.uz TYPE65 +short
curl --http3 -I https://example.uzThe last command needs a curl build with HTTP/3. Clients that ignore HTTPS records keep connecting through A and AAAA as usual, so a correct record harms no one.