[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG)

Keith Moore <moore@cs.utk.edu> writes:

> > Otherwise people might start thinking that 
> > getaddrinfo() would/should be the point of augmentation when they want 
> > to implement SRV, MX and other name-to-address lookup API, leading to a 
> > whole mess 
> People already *are* thinking that, and have been for many years.  IMHO 
> one of the biggest botches of getaddrinfo() is the srvname parameter,
> partially because it tempts people to have getaddrinfo() do SRV lookups (and
> there's nothing in the specification that says not to do that)

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. It can ask for SRV-records, and sort the returned addresses
according to some combination of SRV priority, weight and other
destination address selection rules. If no SRV was found, it can ask
for A and/or AAAA records, and use getservbyname to find the port
number. Sounds like an easy and reasonable way to deploy SRV.

Compare to the non-SRV usage scenario: I use getaddrinfo, to make my
code nice and protocol independent, and I want to use some fix port
number. Then I'll want getaddrinfo to write the number into the
returned sockaddr structures, in the nice protocol neutral way of
getaddrinfo. But to do that, I have to convert my fix number into a
*string*, and let getaddrinfo convert it back to a number. To me, that
mode of operation makes a lot less sense than having getaddrinfo
perform SRV lookups...


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6