From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 10:41:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B92EA16A4E0; Thu, 24 Aug 2006 10:41:51 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 143FF43D49; Thu, 24 Aug 2006 10:41:50 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 84AD91A78D; Thu, 24 Aug 2006 12:41:48 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27260-05; Thu, 24 Aug 2006 12:41:47 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id ED5B81A751; Thu, 24 Aug 2006 12:41:46 +0200 (CEST) Message-ID: <44ED8266.1060303@shapeshifter.se> Date: Thu, 24 Aug 2006 12:41:42 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> In-Reply-To: <5D7785ADC030FEBFB9A5E69D@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 10:41:51 -0000 Pat Lashley wrote: >> As for mDNS/SD I think a generic responderd.conf/mdns.conf file should >> be available where you can configure "static" dns records. > > I would really rather see the service advertisement done in each > service's rc.d script. That has the advantage of not requiring the > mdns.conf file to be updated if the _enable knob is changed in > /etc/rc.conf. It also makes it easy to add a line to revoke the > advertisement in the rc.d script's 'stop' action. > > That said, static service advertisement via the mdns.conf file is useful > when advertising on behalf of of a system or embedded device that > doesn't have native mDNS support. (E.g., An older network-attached > printer.) > > The mdns.conf can also be used to advertise host records for hosts that > don't support mDNS. But again, it would be nice to have a config flag > that just says 'advertise everything in /etc/hosts' in addition to a way > to list individual entries. > I should probably explain better what I mean with this mdns.conf file, as I think there might be a misunderstanding about it. Let us for a second pretend that SD doesn't exist but mDNS does, mDNS without SD is still a very valuable protocol. The specs. says that each host should claim a unique host and also advertise a HINFO record, but this in my opinion a policy decision and should be left to the end user. A user might want to advertise 0, 1, 2 or many different unique records, and the main purpose of the mdns.conf file would be to provide a easy way to do so (without writing scripts that calls a cmd line utility). For example, a line in the mdns.conf might look like this $(hostname).local. A $(ifaddr) Might look cryptic but it just means announce a A record using my current hostname, append .local. and point it to whatever ip number that happens to be configured on my interface. These variables would be updated when things happen in the system (new ip address etc) Also, there is no technical limitation in the mDNS protocol that prevents it from working with other TLDs, so which TLD to use should also be up to the user (again a policy decision). Now we can get back to the reality where SD does exists. In addition to this mdns.conf we have the client API, using this client API a command line tool should be built that can insert and remove records (even those records configured using mdns.conf). Lets call this tool mdns for now (the name it doesn't matter, and isn't really the point). Programs announcing a service using SD would preferably call the mdns tool in their rc.d scripts to add/remove SD records. So I'm not voting for either side, I want 'em both and I definitely want a command line tool that rc.d-scripts can call to register records. > >> > 8. How should applications interact with this system? That includes >> stuff in >> > the FreeBSD base, and what APIs to publish for third party stuff. >> Are there >> > well established APIs that we should/must support? >> >> It's best to go with Apples API from mDNSResponder. > > It's not clear to me yet whether it is better to do that or to go with > the Avahi API; or to provide both. (I haven't actually looked at either; > so I don't know just how they differ.) If KDE and Gnome are using the Avahi API, then we really need to support it. But as you said we can probably implement both APIs as shim calls around our own API. >> > 10. How do users interact with this? Should there be a utility that >> allows >> > users to browse the network to see what services are available? >> As for mDNS and hostname in generic, users would interact with them just >> as with any other dns records or name. > > Right. Except for the additional bit of knowledge about the .local domain. > I've been thinking about this too. The NSS module would require a file similar to resolv.conf. It would contain a "white list" of allowed domains to resolv (local., 168.192.in-addr.arpa., 10.in-addr.arpa etc). But it could also contain a "search" directive so that if it receives a query for a name without a white listed TLD it appends for example ".local." to the name. It might be dangerous though as it could try to query for www.google.com.local., a solution to this would be do "blacklist" existing TLDs when a search is done or only to do a search if there are no dots in the name, I think the latter solution is the best Anyway, it would allow users to leave out the .local part when communicating which I think would be a nice feature. Fredrik Lindberg