> On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > > I don't think that we should be defining getaddrinfo() in terms of > > "whatever lookup service happens to be around" because it's very > > difficult to get reliable and repeatable behavior that way. > > Isn't the DNS a lookup service that happens to be around ?
DNS is a specific lookup service. not a random one that just might happen to be around. > The purpose of getaddrinfo is to perform network address and service > translation. Whilst a portable, granular, interface to DNS would be > very much welcome - getaddrinfo should not be it. Perhaps. But if getaddrinfo isn't the service that does DNS lookups, then at least some apps should not be using it. > > > I also think it > > > should be possible for an administrator to define which name services > > > should be used, which type of addresses should be returned, and the > > > order. > > > > I disagree. Different apps have different needs, and no single > > host-wide or site-wide policy can accomodate the needs of the variety of > > apps in use. > > A large ammount of apps have common needs; a very common need is to > translate network and service names into numbers. The vast majority > of these apps should not care whether it comes from lookupd/nscd, a > hosts file, dns, WINS or another source. That's simply insane. Apps (and users) often care if the results from whatever lookup service getaddrinfo/gethostname happens to use are not consistent with reality. Apps sometimes care if the results of those lookups at different points in the network are not consistent with one another. People are often claiming that apps should not use IP addresses for referrals - that they should use DNS names instead. Indeed, it would be nice for apps to be able to do that, but that would imply (among other things) that a name means the same thing from all points of the application - NOT whatever some random lookup service or stale host file happens to return to a particular host. Every additional oracle that attempts to provide name to address translation is another potential source of variation and error. Every additional configuration knob that attempts to choose which source of name lookup should be used (whether it be an API, a config file, or a DHCP option) is yet another knob that can be set wrong. All of this garbage makes applications that ought to be portable from one host to another and one network to another, overly sensitive to host and site configuration. It causes bugs that are often difficult to troubleshoot. > > Also, apps often cross administrative boundaries, which > > creates problems when different nodes of those apps are subjected to the > > whims of different administrators. > > Indeed, but to remove responsibility from administrators is to remove > power from administrators. It removes the power to screw things up. I don't see this as a bad thing. Administrators can already set the meanings of DNS names in the zones that they control. Why do they need multiple ways to screw things up ? > Many administrators cherish and understand > their ability to define a search-order, over-ride domains, cache lookups. And many administrators should be terminated with extreme prejudice, too. > Resolving only DNS would even hinder an administrators ability to fix > these problems. Many sites have RFC1918 bogons in their zones (forward > and reverse), some even listed as MX. It can ocasionally be useful to > over-ride such sillyness locally. I'm not saying administrators should > have to work around other's problems, de-incentivising the need to really > fix them, but ocasionally we do. Okay, fine. Maybe admins need a way to work around occasional problems that occur. But we don't need a hodgepodge of different lookup methods and APIs and configuration mechanisms that interact with each other in arbitrary ways that vary from one host or site to another. > > It's not just specalized DNS applications that need to know what really > > is in DNS. > > I would argue that really only an application with specialised DNS > functionality (for instance an SMTP implementation) needs to know what > really is in DNS. You're wrong, of course. > A the issue of link-locals in DNS, I agree that they should be returned > by getaddrinfo, for the same reason I cite below. Well, link-local addresses should never be in DNS in the first place. My argument is not that link-local addresses should be returned by getaddrinfo() , it is that getaddrinfo() should be transparent. It shouldn't be yet another layer (in addition to all of the ones mentioned above) that is getting in the way of the app finding out what the DNS name means. > > Many apps need consistent views of DNS without having to > > second-guess the local host API implementation, brain-damaged sysadmins, > > etc. > > Whilst it's extremely desirable that apps not have to deal with API > implementation inconsistency, the application writers sense of priorities > should come much lower than the local administrators IMO. Quite often local administrators forget that their purpose is to support users, that those users need to run apps, and that for the apps to run reliably they need a reliable and predictable environment. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
