> > > As far as I can see, the only good reason to have the service argument > > > in getaddrinfo is to make it possible for getaddrinfo to perform SRV > > > lookups. > > > > that's not a good reason, that's a disaster. > > That's a strong word, given that the only effect on lookups in the > majority of domains that haven't deployed SRV, is one more roundtrip > to the local caching dns-server.
Wrong. One problem is that the various apps that don't use SRV now won't all get upgraded at once. So when you turn on a SRV record you will break all of the clients and servers that don't support SRV yet. Either that or you have to configure the server to support both old and new ports. Another part of the problem is that the server has to be explicitly configured to listen on the alternate port - there's no reliable way for the server to automatically determine this. So SRV creates yet another way for DNS to get out of sync with host configuration - another knob that can be set incorrectly. And yes, we went through a similar transition with MX records and email; but the net was much smaller then, and this was a deliberate change to a single app by the people who maintained that app rather than a change to every app made by people who had nothing to do with most of those apps. Even so, my recollection that it wasn't until the mid-1990s that you could count on MTAs recognizing MX records, even though RFC 974 was published in 1986. I'd expect the net to transition even more slowly today. > > it would also tempt NATs to tweak DNS in even more preverse > > ways than they already do. > > I don't understand how this is relevant. It should work fine unless > the NAT operator does anything stupid, and that's the highest level of > NAT-support we can expect for any protocol. 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? > > there's a reason that RFC 2782 contains the following text: > > > > Service SRV records SHOULD NOT be used in the absence > > of such specification. > > Right, for each particular domain and service, there's a choice that > has to be made before deploying SRV. In order for SRV-records to be > used for a particular service, both ends must have it: There must be > SRV records configured in the DNS-server for the domain, and the > client must ask for and use them. and the server has to listen on that port and honor requests. > The effect of of having getaddrinfo try SRV lookup (or generally, > having a random client application ask for SRV records by default) is > to make it possible for the operator of the domain in question to > easily implement her choice. 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) SRV can be useful, but its utility varies widely depending on the application. For some apps it's completely inappropriate. Should ping honor SRV? What about ssh? SNMP? NFS? FTP? Sometimes a domain names a service; sometimes it names a host. and is it really worth it to double the time required to do DNS lookups FOR EVERY APP, when DNS lookups are already abysmally slow and unreliable? > My current interest in SRV is that I'm hacking Ian Jackson's resolver > library "adns" to support IPv6 and SRV. That's fine and useful as long as you make the SRV lookup optional. Apps need to choose whether they want to do SRV or not; not have that choice made for them. > If there's any good reason why I shouldn't > recommend random client applications to use this function, I'd like to > know about it. 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. > Ah, and one more question: After a first look around for SRV records > in the current DNS infrastructure, I've found SRV records for the > following services: ftp, http, kerberos, kpasswd, and sip. I imagine > SIP, being a recent protocol, actually specifies the use of SRV (I > haven't read the SIP specs). It does. I believe there's a spec for use of SRV with Kerberos also. I am fairly confident that ftp, http SRV records are bogus and should not be honored by standards-conforming clients. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
