Keith Moore wrote:
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.
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.
The intention here is to define and promote res_XXX()/dn_XXX() as `the' DNS API, and define and promote getaddrinfo() as nothing more than a basic name lookup service. 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 (e.g. they would want to add new members to struct getaddrinfo to return SRV service priority and weight information *shudder*).
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.
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.
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. (By the way, I'm talking about the option #1; AI_DNS_ONLY looks good because it does draw a clear line without sacrificing any of the existing capability.)
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.
Agreed. The current RFC 3493 seems insufficient in this aspect. An update to RFC 3493 that defines the DNS-only flag could clarify: `If AI_DNS_ONLY is not specified to getaddrinfo() or getnameinfo() calls, the result from such calls MUST NOT be assumed to be obtained solely from DNS. Applications that require the result to be from DNS MUST specify AI_DNS_ONLY when calling getaddrinfo() or getnameinfo().'
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.
(This seems to be getting off-topic; this will be my last on-list response about this particular subject. Sorry ;)
I agree with you, except that I think the Internet *is* defined (albeit indirectly) by applications. My take is slightly broader.
How the Internet *should be in the future* is defined by specifications. How the Internet *currently is* is defined by various components of the Internet, including the VMoA (:p).
The basis upon which people decide how the Internet should be in the future, i.e. specifications, is what they want to accomplish in the current environment, i.e. the current status of the Internet. In that sense, the current Internet and its applications provide some sort of guidance upon creating/amending specifications, usually suggesting a path of less resistance.
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. Whatever we do that breaks them will upset some people (especially if they didn't even know those applications had problems, however subtle they may be). So, as long as we can reach our goal of enhancing our specifications to be more clear and precise, why not take a course of action that meets expectation of more applications and/or breaks less applications?
This is why I still believe what people expect from (current applications that expect certain behavior from) getaddrinfo() should have a say about how we update RFC 3493. To me it looks like there are going to be more people who are like `What, my changes to /etc/nsswitch.conf has no effect?' or `Why do the entries I added to /etc/hosts seem to be ignored?' (e.g. if system admininstration scripts rely on those files) after we change getaddrinfo() to be DNS-only by default, than people who are like `Geez, this program doesn't work anymore after I change /etc/nsswitch.conf?' (e.g. after raising the priority of NIS database which is out of sync with DNS) under the current behavior. But this is only from my (limited) viewpoint, and I wanted to hear some other inputs as well.
Regards, Eugene
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
