Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

[Colm MacCarthaigh <colm@stdlib.net>]

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 ?

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.

> > 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.  

> 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. Many administrators cherish and understand
their ability to define a search-order, over-ride domains, cache lookups.
Others misunderstand and abuse these facilities, but the primary fault
lies with those administrators - not elsewhere.

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.

> 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. Certainly more applications than host/dig and so on 
need to know what's really is in DNS, but I don't think the term
"specialised" is unsuited.

A the issue of link-locals in DNS, I agree that they should be returned
by getaddrinfo, for the same reason I cite below. 

> 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.

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net