[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG



> 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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------