SRV lookup support (Bugzilla 2217)

James Bottomley James.Bottomley at
Fri Feb 19 11:28:58 AEDT 2021

On Fri, 2021-02-19 at 00:03 +0100, Jochen Bern wrote:
> On 18.02.21 20:22, James Bottomley wrote:
> > SRV is used as a requirement by several protocols today.  Xmpp
> > simply won't work without them unless you happen to have a lucky
> > domain setup and matrix could use the .well-known/ URL instead, but
> > having SRV records is required for setups where WWW isn't run on
> > the domain URL.
> While I very much agree that any protocol/service that insists on
> pwning your domain name in the DNS *deserves* the eternal punishment
> of having to support a personal fix for their hubris (a la SMTP and
> MX RRs), I do *not* agree that SRVs are "required" to run a webserver
> today.

I didn't say required for a webserver, I said required for certain
protocols.  The general use case is where you have a multi-node domain
but you want to export the service at the domain level, so I want my
xmpp address to be 'jejb at' not
'jejb at' and to do that, I need SRV records. 
The same goes for matrix (except my id is

> Through three different web design outfits and their favorite hosters
> now, I have successfully upheld that points to an IP *we*
> control and run a HTTP+HTTPS redirector to (and
> whatever other stuff we want to be available as "") on.
> (Having your content appear under a *single* FQDN is actually good
> for your SEO.)

Running a single server for all protocols at the domain address
obviates the need for SRV records usually (unless you're on non-
standard ports).  However, once you want fault resiliency or load
balancing, you'll get forced to use them as well.

> Also, the range of "web browsers" is a tad too large - from FF, Edge
> and the like to Konqueror to elinks and lynx to cURL and wget to
> debugging with plain "telnet" or "openssl s_client" - to
> *consistently* obey SRV RRs anytime soon.

The app implementations of protocols that specify SRV URLs tend to be
well behaved.  The fact that most browsers aren't that well behaved is
sadly true but orthogonal.


More information about the openssh-unix-dev mailing list