On Feb 19, 2021, at 1:50 AM, Mara Sophie Grosch <littlefox@xxxxxxxxxx> wrote: > On Feb 18, 2021, at 11:28 AM, Thorsten Glaser <t.glaser@xxxxxxxxx> wrote: >> On Thu, 18 Feb 2021, James Bottomley wrote: I can’t see where this >> will end up in anything other than sysadmin tears. > > Though the same argument applies to A vs AAAA records and any new > technology, having this as an option that defaults to off seems like a > good idea anyway and would help against this. > > On Thu, Feb 18, 2021 at 11:56:48AM -0800, Ron Frederick wrote: >> Keep in mind that SRV records typically point at hostnames, not >> directly at IP addresses. In fact, I’m not even sure they are allowed >> to point at IPs. So, there will still be a hostname lookup which occurs >> after the SRV record lookup, and that could potentially be resolved via >> /etc/hosts depending on the local system’s resolver configuration. >> >> It’s also worth pointing out that one benefit of SRV records is that >> you can specify port information in them, if you want client to use a >> port other than the default one of 22, without the need to configure >> that on every client. >> >> In my experience, SRV records are not set at the “host” level. They’re >> typically set at the domain level (e.g. example.com >> <http://example.com/>, not foo.example.com <http://foo.example.com/>), >> and they tell you which host(s) under that domain provide the service >> you are looking up, along with the port number to connect to on that >> host. You can also set a series of possible hosts, with weights for >> which ones to prefer. > > Being able to specify custom ports (and not having users configure it) > is the reason I'm working on it, also the primary reason for the initial > feature request. I'm thinking of running Git+SSH without having to > dedicate an IP or have it fiddle with my systems configuration. > > Also fits something like Github (or any large Git+SSH deployment) more > closely: SSH is a service provided by lots of hosts which may have > different priorities (the current patch only uses the highest-prio host > though). > > I hope to get some more comments about SRV records with SSH and not > about if SRV records in general are useful? I see the potential usefulness of this. Given how many other ways there already here to determine the hostname, though, and the extra delay which may be introduced to do the SRV record lookup, I think it should probably be disabled by default. Even with it enabled, it probably shouldn’t trigger the lookup in cases where the ‘Hostname’ option is already set in configuration. In cases where that’s specified, I think that value should be used directly if it is an IP address, and trigger only normal A/AAAA/CNAME resolution if it is a name. Something else to consider is how this interacts with the various Canonicalize config options. Are those applied to the name before doing the SRV record lookup? If a short hostname is given, that might be needed, but that means you’d be potentially looking up multiple SRV entries. Also, there’s a question of what wins if one of the domains in CanonicalizeDomains has an SRV record but another one has a CNAME or A/AAAA record with no SRV. Do you try all the domains for SRV records before looping back around to look for CNAME/A/AAAA records? That’s getting pretty complicated. Since SRV records return a port number, you’d also need to consider what happens when no hostname is specified in config but a port number is. Do you still look up the SRV record in that case and use the hostname and port from there, ignoring the port in config, use the hostname from the command line with the port from the config, or use the hostname from the SRV record but override the port and use the port from the config? I don’t really like mixing and matching hostname and port from two different places, so perhaps the presence of either a hostname or a port in config should be enough to disable SRV record lookups. -- Ron Frederick ronf@xxxxxxxxxxxxx _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
