Keith Moore <[EMAIL PROTECTED]> writes: > > 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. Or if you do lookups in parallell, you ask for A, AAAA and SRV instead of just A and AAAA. > 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. > 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. (To be precise, I'd say that if a client that asks for SRV records, gets a NODATA answer, and then falls back to the good old A, AAAA and getservbyname, then SRV is "not used". You may say there are security issues, but from reading the security considerations section of RFC2782, I don't think there's a real problem). 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. The effect is that the client applications delegate the decision "should I be using SRV records for this particular <domain,service>" to the operator of the corresponding DNS domain. This depends on how you want to deploy SRV, I guess. To me, it makes sense with a gradual deployment per <domain,service>. And then it seems useful if applications by default use SRV records whenever the operator of a domain has bothered to configure relevant SRV-records in the right DNS server. My current interest in SRV is that I'm hacking Ian Jackson's resolver library "adns" to support IPv6 and SRV. This includes an adns_getaddrinfo function which asks for SRV-records, and in the absense of SRV-records, constructs a fake SRV-record from A and AAAA records and getservbyname. Unlike getaddrinfo, SRV lookup is an advertised feature, and the function returns SRV records, not just a list of addresses. 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. 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). What about the others, does there exist any standards track spec, as required by the RFC2782 applicbility statement, endorsing SRV-records for e.g. ftp, http and kerberos? For example, try host -l sunet.se sunic.sunet.se |grep SRV host -l ingate.se usagi.ingate.se |grep SRV for two domains that are operated by people who I believe are not clueless about the DNS. Best regards, /Niels PS. I'm afraid API and deployment issues border on off-topic on the ipv6 list. Feel free to send followups elsewhere (and Cc: me), or to answer privately. -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
