> Keith Moore <[EMAIL PROTECTED]> writes: > > > Or you could redirect attempts to ssh to host X so that they go to > > host Y instead. This is not an inherently desirable feature. > > Sure, but if I have write access to the DNS configuration (so that I > can add the SRV record), then I don't need any SRV records to do that > redirection, plain A or CNAME works fine. SRV just let's me do it on a > more fine grained scale.
in other words, it lets you mount precision attacks :) > > > If the server administrater wants it: Sure. Nobody else can really > > > decide whether or not SRV is "useful" or "appropriate" for a > > > particular service instance. > > > > Nor, for that matter, can the DNS server administrator. > > The server and administrator and DNS server administrator have to > cooperate. If they for some reason refuse to do that, they simply > can't deploy SRV in any useful way. You missed my point, which was that the DNS server admin is usually not in a position to know whether it's appropriate to impose SRV records on a particular app - unless perhaps the app specifies how and when it's okay to do that. SRV is not a general-purpose club that you can beat apps with. > > For instance, http://example.com:80/foo/bar will be canonicalized to > > http://example.com/foo/bar - which, if there were a SRV record for > > _http._tcp.example.com pointing to a different port or host, would > > change the meaning of the URL. > > Thanks, that's a good point. It's got more to do with URL syntax than > with the http protocol per se, it's pretty hard to separate HTTP and URL syntax; HTTP and URLs are very closely tied together. > but it still seems like it could be a > real problem with using SRV records for http. It's just one example among many. Some protocols can run perfectly well on any port; others have assumptions about port numbers wired-in , and often they are not obvious. The point is that one size does not fit all, and imposing SRV on all apps will break things. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
