On Mon, Nov 03, 2003 at 04:22:55PM -0500, Keith Moore wrote: > > 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.
NIS is a specific lookup service, as is WINS, and well I could go on ... DNS may be more standardised, more widely-deployed and frankly - more tasteful, but it is no more specific. It's not the only show in town :) I don't mean to be facetious here, of course I regard DNS as the "standard" name to number resolver, but I'm a long long way from thinking it should be the only means allowed for applications to resolve names. > > 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. Could you give some specific examples of the type of apps you're talking about? > > 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. When you say "reality", do you really mean - "DNS"? If so, what makes DNS more authorative than the decisions of the local administrator ? What about site to site inconsistencies in DNS ? I don't think many people would argue that Global DNS names should be broken by local administrators. But is making that slightly harder worth heavily impairing their ability to have site-local name resolution? > Apps sometimes care if the results of those lookups at different points > in the network are not consistent with one another. Certainly, but since this can (and frequently does) happen with DNS on its own, surely the problem should be resolved more generally? I don't see how the problem of distributed applications needing to agree on a network number is solved by only using DNS to resolve network names. > 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. I disagree. And there are many examples of when people consider it useful for domains to return inconsistent results. Many end-users wish to blackhole the domains of web-banner advertiser; integral to many testing and staging procedures is the ability to spoof production domains; users of RFC1918 space frequently wish to resolve to different addresses depending on scope. Whilst all of this is possible with control over a resolving name-server (assuming there is one), it very much removes power from the administrator which they find useful. > 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. Agreed, however I view the alternative as worse. I've been involved in the IPv6 development of widely-deployed applications, and have experience dealing with obsure user problems, extremely tenous getaddrinfo bugs and other such madness, and I can't think of many such problems occuring. On the other hand, I've been saved by the ability to quickly over-ride local name resolution more than once. > > > 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 ? Because local administrators arn't always in control of their DNS names. All that would happen is that more local administrators would run local DNS resolvers. It just gets you right back to square one :) > > 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. Could you provide an example ? Personally I consider lookup-agnosticism as a good feature of getaddrinfo. It will take a lot to persuade me otherwise. "really in DNS" and "globally consistent" are not equatable statements, because well ... they're not. Unless you're arguing for a global short-list of resolvers ? The problems seen with name-resolsution inconsistency are the result of stupid operators - they arn't going to go away. They're just going to be stupid with DNS instead :) > 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. Totally, but it is not for an API to dictate to local administrators how best to achieve this. Extra lookup methods can be part of providing a more reliable and predictable environment. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
