2

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?

3
  • "So I'd like to understand why they invented a new type of a record with a whole new semantic" Browsers never wanted to implement support for SRV records, so that path was blocked. Plus new needs emerged, like encrypted clientHello during TLS exchange that needed to publish keys somewhere in the DNS. Plus the explosion of HTTP versions (version 2, then 3) Feb 15, 2022 at 9:33
  • 2
    And now browsers which never wanted to implement SRV lookups will happily implement SVCB lookups. Because you don't understand, it's different. Also there was absolutely no way to put keys into DNS. TLSA? Never heard about that thing. Feb 15, 2022 at 11:10
  • 1
    The only problem with SRV and TLSA records seems to be "not invented here". Jun 27, 2022 at 9:08

1 Answer 1

1

Quote from the draft, Appendix C.1

C.1.  Differences from the SRV RR type

   An SRV record [SRV] can perform a similar function to the SVCB
   record, informing a client to look in a different location for a
   service.  However, there are several differences:

   *  SRV records are typically mandatory, whereas SVCB is intended to
      be optional when used with pre-existing protocols.

   *  SRV records cannot instruct the client to switch or upgrade
      protocols, whereas SVCB can signal such an upgrade (e.g. to
      HTTP/2).

   *  SRV records are not extensible, whereas SVCB and HTTPS RRs can be
      extended with new parameters.

   *  SRV records specify a "weight" for unbalanced randomized load-
      balancing.  SVCB only supports balanced randomized load-balancing,
      although weights could be added via a future SvcParam.
1
  • 1
    But all in all those are all "minor" points. The biggest difference is that browsers always stated they won't use SRV so it doomed that record for http traffic at least, where same ones embraced SVCB right at the beginning... Feb 15, 2022 at 9:32

Not the answer you're looking for? Browse other questions tagged .