> >> * Change/fix the definition of getaddrinfo()/getnameinfo() so they > >> are tied to DNS only but nothing else. > >> * Keep the current semantics of those functions, then update and > >> standarize an API that strictly queries DNS only (res_XXX() and > >> dn_XXX() comes to mind first; if they fall short of what real > >> applications need, we could always define a new superset). > >> > > > >There's a third option - like I suggested earlier, add a flag to > >getaddrinfo that says "only use DNS for this query". The res_XXX > >and dn_XXX functions (or improvements to these) are needed anyway > >because we use DNS for other things besides address lookup. > > > > That sounds good too, as long as the res_XXX()/dn_XXX() functions are > standardized at the same time and the DNS-only getaddrinfo() flag is > defined to be equivalent of obtaining address records via res_XXX() calls.
That makes sense. If you just want A/AAAA records do getservbyname() with the DNS only flag; otherwise use res_XXX/dn_XXX. The only problem is that the res_XXX/dn_XXX functions have really awkward interfaces. But there's something to be said for stability. > 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) and partially because it can cause additional errors. (It is utterly insane to look up a symbolic constant in a file or network-accessible database when that constant is part of the specification for the protocol you're implementing. When I was a sysadmin I lost track of how many times I had to diagnose an application that was failing because getservbyname() for some well-known protocol returned NULL - usually because the YP server wasn't bound or some stupid thing like that.) > IMO, people should be first recommended to use res_XXX() in order to > implement such a non-A/AAAA lookup scheme, and if they find that too > bothersome (which it's likely to be when the scheme is widely deployed), > they should define a new API that fully covers the scheme rather than > finding a similar API then victimizing it. Agree. In particular, lots of problems result from changing existing APIs in ways that introduce new failure modes. > The standard (RFC 3493, or POSIX) as it is defined now is defined to be > namespace-neutral (although in a passive manner). A lot of > implementations interpret the standard that way too, e.g. > nsswitch.conf. If applications abuse it as a DNS interface then break > later, it's their problem; they should've taken into account from the > first place that getaddrinfo() *may* return non-DNS results. It doesn't > seem like a good idea to reduce the functionality of an existing > standard just so it meets what applications mistakingly expect it to > be. I'm sympathetic to that view. I suppose I'm griping that getaddrinfo() was a poor design that we're kind of stuck with now. I certainly agree that a poor design doesn't necessarily justify a retroactive change. At the same time I think it might help to recommend somewhat more uniform behavior for getaddrinfo() - both the code and the way hosts are configured to use it - e.g. - specify more precisely what it means in terms of DNS queries (e.g. no SRV records) - discourage use of proprietary or platform-specific query methods like NIS, NIS+, netinfo, WINS, without forbidding it entirely - specify requirements for consistency between different services that provide lookup for the same names > I'm not saying that what applications do is always right. But the fact > that applications are doing a wrong thing means we can just ignore them > as if they weren't there. I agree with this. We don't want to break existing apps. But the desire to have (more) reliable apps in the future implies a need to define components precisely enough that apps can get repeatable behavior from them - even when those apps run on different platforms, and in different parts of the network. Well, I guess I know what kind of Internet-Draft to write... Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
