In DNS there was SRV record defined long ago, which allowed to direct some services for a domain to different machines. For example, this is how I publish a LDAP service for a domain example.com
served on server1.example.net
tcp port 389:
_ldap._tcp.example.com IN SRV 100 1 389 server1.example.net
There may be more than one record of that kind and this way I can achieve some load balancing.
Support of corresponding DNS lookups is usual for some services, including LDAP, Kerberos, SIP, XMPP and some others. However, for email we use a "reduced form" of SRV
record called MX
record. It doesn't allow us to define weight and alter port (it always uses tcp 25). Some services don't use this type of lookup at all, for example, HTTP clients never issue corresponding DNS requests and always connect to the TCP port 80 (or 443 for HTTPS) of the corresponding host.
Recently a new draft appeared, which suggests the use of the special new type of DNS records, called SVCB record. It also defines a special type of SVCB record, a HTTPS record. In the draft authors confirm this is essentially a new type of SRV record.
So I'd like to understand why they invented a new type of a record with a whole new semantic, instead of pushing an adoption of well known and widely used SRV record? Why not use something like
_https._tcp.example.net IN SRV 100 1 443 server2.example.com
Disadvantages are similar: this needs change of a software. Old client software will neither do SRV nor SVCB/HTTPS DNS requests, so neither will work.
However, SVCB has a huge additional disadvantage: the record type is new and therefore it needs also DNS server updates and administrator training. By the way, a semantic of a record is not that simple.
As a professional administrator who has some dozen public DNS domains in charge, I am concerned with this.
What are significant advantages?
Quote from the draft, Appendix C.1