On Thu, 2021-02-18 at 16:13 +0100, Thorsten Glaser wrote:> On Thu, 18 Feb 2021, Mara Sophie Grosch wrote: > > > > (after all, they could already send it to an entirely different > > > host) but maybe I'm missing something... > > > > I think if an attacker controls DNS, it's a lost game anyway. > > Current > > It?s still a level of indirection that isn?t traditionally used, and > which makes me a bit nervous,The statement is a bit ambiguous, but I think you're saying SRV records aren't traditionally used? That's simply not true. If you look at my own host site, I have SRV records for a couple of protocols: _matrix._tcp.hansenpartnership.com _xmpp-client._tcp.hansenpartnership.com _xmpp-server.._tcp.hansenpartnership.com Whether you should have them for openssh is a different question, but 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.> especially considering name resolution is not just DNS (think > /etc/hosts for example)./etc/host only resolves A and AAAA records, so it would have no impact on SRV records at all. It's actually annoying on one level because to test out the functionality of SRV records you really do need a DNS setup. James
On Thu, 18 Feb 2021, James Bottomley wrote:> > It?s still a level of indirection that isn?t traditionally used, and^^^^^^^^^^^^> SRV is used as a requirement by several protocols today. Xmpp simply^^^^^ Do you see it?> > especially considering name resolution is not just DNS (think > > /etc/hosts for example). > > /etc/host only resolves A and AAAA records, so it would have no impact > on SRV records at all.That?s part of what makes me nervous. If foo.example.com has an SRV RR and I add an entry for foo.example.com into /etc/hosts to temporarily locally redirect it, does that mean the hosts entry will be ignored if SRV RR usage is enabled? I can?t see where this will end up in anything other than sysadmin tears. bye, //mirabilos -- tarent solutions GmbH Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/ Tel: +49 228 54881-393 ? Fax: +49 228 54881-235 HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ************************************************* Mit unserem Consulting bieten wir Unternehmen ma?geschneiderte Angebote in Form von Beratung, Trainings sowie Workshops in den Bereichen Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung sowie Agile Organisation. Besuchen Sie uns auf https://www.tarent.de/consulting . Wir freuen uns auf Ihren Kontakt. *************************************************
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. 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.) 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. Regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210219/a45a7f2c/attachment-0001.p7s>