[KLUG Members] SuSE, Zeroconf, and the 'local' Domain

[Andrew Thompson]

On Thu, 2004-09-30 at 06:20, Adam Tauno Williams wrote:
> > > So, what does this have to do with the 'local' domain? Just this:
> > > instead of resolving it through the regular channels, SuSE's resolver
> > > library tries multicast DNS instead, as noted above. As near as I can
> > > tell, this is NOT a configurable option; it's written right into the
> > > resolver library, and that's that.
> > Yep.  I'm afraid your fighting the tide.  Multicast DNS is in the
> > resolver, the GNOME-VFS subsystem, and other places too.  This is pretty
> > much part & parcel 'service discovery'.
> 
> Take a look at http://gnomedesktop.org/article.php?sid=1841 for some of
> the resulting possibilities.

Actually, the only possibility in which I'm interested is getting back
control of my chosen private domain name. I don't give beans or barley
for zeroconf.

As far as I'm concerned, and I know I'm not the only one who feels this
way, hardcoding this kind of rerouting into the resolver is not the way
to go. Nor is ordering a 1000-seat customer to change its internal
domain name. The use of 'local' for an internal domain is a known
practice, and an IETF draft exists proposing that name be reserved for
that purpose
(http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-dnsind-local-names-07.txt, section 2). Another, more recent draft proposes the reservation of 'local' for zeroconf (http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt, section 3), but as near as I've been able to discover, neither has been formall accepted, unless these drafts themselves are supposed to constitude a standard.

The point is that, while it might be appropriate to set aside a
particular top level domain name to support a particular technology, it
is not appropriate to embed that specification into core technologies.
This change to the resolver library is a perfect example. It turns out
this is part of the glibc package, specifically the dynamic link
library, /lib/libresolv.so.2. I determined this by copying the 9.1
version to a different name, then copying the 9.0 version over top of
it. Presto! '.local' works again! (Make sure you're not running any
networking software while doing this, kids, but that's another story) So
what we have is a fundamental change to the C library to implement one
particular technology. I thought this was the sort of reason I got away
from Microsoft. Sorry, it's just not the way to do it. You want it? Make
it an option. Make it configurable. Make it a switch in resolv.conf or
nsswitch.conf or whatever file seems most appropriate. It doesn't belong
in a core library. Even .com doesn't get that kind of privelege, does
it?

-- 
Andrew Thompson <tempes at ameritech.net>
The Imagerie