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?

Nikita Kipriyanov
  • 15,624

1 Answers1

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.
    

    •
AlexD
  • 11,191