Hey, so #RFC9460 HTTPS/SVCB records are neat, right?

They...
- speed up your time-to-first-packet (by basically stuffing the Alt-Svc HTTP header / ALPN TLS extension into the #DNS);
- let you do redirection on the zone apex without using CNAMEs;
- allow for simple DNS load distribution and failover;
- obviate HSTS and the cumbersone preloading process;
- enable stronger privacy protections via Encrypted Client Hello aka #ECH

@jschauma They’re pretty great. #HTTPS records are self-explanatory, but do you know of any services using #SVCB yet?
@colincogle @jschauma As each use need a profile, it needs a documentation. There are various endeavors currently at IETF for those: finding your resolver already an RFC (https://datatracker.ietf.org/doc/rfc9461/) finding Oblivious DNS parameters (https://www.ietf.org/archive/id/draft-ietf-ohai-svcb-config-00.html) , use for DANE (https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-dane/) are the ones I have seen around, but there may be more.
RFC 9461: Service Binding Mapping for DNS Servers

The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols.

IETF Datatracker
@pmevzek @jschauma Ah, some bedtime reading for tonight. Thanks for sharing!
@jschauma Are there any convenient sources tracking client adoption at the OS/browser/library level similar to caniuse.com that would give an indication when it’s “safe” to start using these records exclusively over legacy solutions for zone apex records like ALIAS?