> > NAT vendors do stupid things all the time, like producing NATs that > > modify the contents of packets where they don't even know what > > protocol is being used. What makes you think they would stop there? > > *No* protocol can work under the assumption that there's a NAT box on > the path that makes arbitrarily stupid changes to packets. Therefore, > it's not possible or useful to consider that scenario in protocol or > application design.
No, but it is entirely reasonable to realize that having applications support SRV is a temptation for NAPT boxes to intercept DNS queries for SRV records, allocate an external port for that service, map it to the internal address and default port for that service, and returning A SRV record that indicates the external port - thus furthering the pollution of the network. > > Funny, you want the admin to have this choice, but you apparently > > don't want the application specification to have a choice (as RFC > > 2782 insists must be done) > > The default ssh port is 22. Say that I operate an ssh server, and for > some arbitrary reason I want it to listen on a different port, say 80. > To make this work, I can send out a mail to all my users telling them > to use ssh -p 80, and hope they read and remember that. Or I could > install an SRV record in the DNS tree that says that I'm using port > 80, and hope the the users' ssh clients will notice. Or both. 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. The point is - it's not within either the purview of the DNSext group, or the network administrator, to change how the ssh application operates. Unilaterally imposing SRV records violates the expectations behind the design of the app, and may violate users' expectations also. > > SRV can be useful, but its utility varies widely depending on the > > application. For some apps it's completely inappropriate. Should > > ping honor SRV? > > To use SRV for ICMP ping seems quite far out. To use SRV for lots of protocols seems far out. ICMP is just one end of a broad spectrum. > > What about ssh? SNMP? NFS? FTP? Sometimes a > > domain names a service; sometimes it names a host. > > 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 reason is: it violates the SRV specification to use SRV with an > > app that doesn't specify the use of SRV, and it also violates the > > specifications of those applications that specify a port number to > > be used. > > > I am fairly confident that ftp, http SRV records are bogus and > > should not be honored by standards-conforming clients. > > Thanks for the answers, even if I'm not totally convinced. > > Let's look at http again, where the spec for http-url:s says clearly > that of no port number is given explicitly, port 80 should be used > (the text is descriptive here too, "if the port is empty or not given, > port 80 is assumed"). Say I have a SRV aware browser that breaks the > spec and looks up _http._tcp SRV records, and uses ports given in SRV > records instead of the default port 80. There's WAY too much code out there that assumes that the lack of an explicit port number in an HTTP URL means port 80. Imposing SRV on HTTP would break all of that code. 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. It's incredibly naive to think that you unilaterally can change an interface used by nearly all apps and not break things. To insist on doing it anyway is criminally irresponsible. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
