> So there seem to be at least two alternatives: > > * 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. > Perhaps it'd be desirable to see some actual figures; how much > percentage of the applications out there that use > gethostbyXXX()/getaddrinfo()/getnameinfo() would assume those > functions look up DNS records *only*, and would be severely broken if > they were given results not based on DNS. Well, it has a lot to do with the environment, doesn't it? I mean, if and when an alternate name-to-address translation service produces answers identical to DNS, then the app probably doesn't care what service provided the answers. The problems occur when the translation service doesn't provide the correct answers, or when the translation service in use at point A provides different answers than the service in use at point B. The more different lookup mechanisms in use, the easier it is for them to get out of sync with one another. Similarly, no app will be broken by a decision to use DNS when its host or network is properly configured. The only time breakage occurs is when the host or network is improperly configured to use some other lookup service besides DNS, or when the host is not configured at all. (yes, we do need to deal with self-configuring or ad hoc networks, but we need to do so in a way that produces results that don't conflict with DNS) An increasing number of apps are defined in such a way that DNS is *part of the protocol specification*; the app will violate the protocol specification if it uses a service other than DNS. For instance, any app that uses SRV or MX records falls into this catgory. There's little justification for an administrator to use an alternate address lookup service, since they typically have to support at least one app that requires DNS anyway. And there's certainly no reason for IETF to be endorsing the idea that a site should be able to use any lookup service it likes without breaking things. > However, my impression was that a vast majority of applications out > there use the functions in their original semantics (i.e. as a > shorthand facility for specifying human-readable text form of > addresses, not as a frontend interface for DNS only but nothing else), > e.g. `ping6 www.kame.net' certainly wouldn't care if the IPv6 address > getaddrinfo() returns comes from DNS, NIS, or any other mechanism. It's been a long time since HOSTS.TXT was sufficient. It's also been a long time since DNS was only a distributed replacement for HOSTS.TXT. The Internet is not defined by the "vast majority of applications". The Internet is defined by specifications. The problem is that our specifications are sometimes incomplete. In this case the APIs that we're recommending be used for implementation of apps aren't specified with enough precision to allow those apps to interoperate reliably. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
