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@xxxxxxxxxxxxxxxxxxxxx' not 'jejb@xxxxxxxxxxxxxxxxxxxxxxxxxxx' and to do that, I need SRV records. The same goes for matrix (except my id is @jejb:hansenpartnership.com) > Through three different web design outfits and their favorite hosters > now, I have successfully upheld that binect.de points to an IP *we* > control and run a HTTP+HTTPS redirector to www.binect.de (and > whatever other stuff we want to be available as "binect.de") 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. James _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
