From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 16:07:36 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 14FBA16A4DA; Thu, 24 Aug 2006 16:07:36 +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 6D8DD43D45; Thu, 24 Aug 2006 16:07:35 +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 24E5C1A78D; Thu, 24 Aug 2006 18:07:33 +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 30634-09; Thu, 24 Aug 2006 18:07:31 +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 544361A72A; Thu, 24 Aug 2006 18:07:31 +0200 (CEST) Message-ID: <44EDCEC2.7060109@shapeshifter.se> Date: Thu, 24 Aug 2006 18:07:30 +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> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> In-Reply-To: <7C6CDF1CB0BC58A6ADE1FCA8@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 16:07:36 -0000 Pat Lashley wrote: >> >> Let us for a second pretend that SD doesn't exist but mDNS does, mDNS >> without SD is still a very valuable protocol. > > No argument there. > >> 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. > > The HINFO record should be a policy decision; but I'm much less certain > about the utility of not advertising a hostname. Well, then we can agree upon disagreeing :) I guess it's just my nature, I really don't want to restrict end users ability to do stuff when there is no TECHNICAL limitation of doing so. It's the classical policy versus mechanism scenario, imho policy should be left to the user, of course provided with sane default values that can be used out of the box. > >> 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. > > Things get a bit more complex for multi-homed hosts; especially if they > are connected to more than one local link using IPv4 Link Local > Addressing... Well, I already have a proof-of-concept of this running a multi-homed responder and hosts on both ends resolve the addresses correct. A multi-homed host with two interfaces configured in 169.254/16 will have other major problems beyond mDNS as the host would threat both interfaces as being on the same net even if they are physically separated. > > As I mentioned in an earlier posting, I would really like to see it > support multiple TLDs for a single host. In particular, if I'm using > example.com, then mumble.local and mumble.example.com should both > resolve via mDNS to the IP address of host mumble. Similarly, services > advertised by host mumble should automatically be listed in both domains. Well, $(hostname).example.com. A $(ifaddr) :) You would have to configure the NSS module to allow .com queries too. > > If we're going to require an entry in a config file to get address > advertisement; then we need to ensure that the default config file Does > The Right Thing for the 99.99% case. (Otherwise, it isn't really > zeroconf, is it?) Of course, default configuration should always be such that it requires none or minimal work by the end user to get it running with values that suite most people. However I feel power-users shouldn't be restricted to do what ever they want, even how crazy other people might think it is. The default of my proof-of-concept stuff had this as default, which means advertise a A and a PTR record for my hostname on all interfaces using the address of the interface. (should be expanded with AAAA and $(ifaddr6) in a real application). interface * { $(hostname).local. A $(ifaddr) $(ifaddr) PTR $(hostname).local. } > > > I think that it would be best if the most common cases worked correctly > without a config file at all. Command-line flags set via /etc/rc.conf > can indicate interfaces that are (not) to be used, whether or not to > automatically produce an HINFO record, and whether to advertise all > (except 127/8) or none of the /etc/hosts records. Doing this via rc.conf > makes it much easier to set up common options at install time via > sysinstall. I really don't understand how it should read /etc/hosts, users might have aliases in there that doesn't belong to them which would make the responder announce records that doesn't belong to them. > > The config file, if provided would specify additional hosts that don't > advertise themselves; and additional services provided by hosts that > don't advertise. It would also be used to specify a non-default HINFO > record format. (I'm thinking a string with various % substitutions > available.) Note that whether or not to produce an HINFO record at all > would still be handled by the command line. > >> 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. > > No, programs announcing a service using SD would preferably make a call > to the mdns-sd library. The use of the mdnstool in the rc.d script > should probably be viewed as the preferred method during the transition > period between bundling the basic mDNS support and converting the > service providers to being directly mDNS-aware. Yeah, on a second though I agree with that. > >> > 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. > > Is that really necessary? I haven't looked at how the resolver handles > the domain search list and how that relates to NSS calls; but couldn't > it be handled by implicitly adding 'local' to the list? > I was under the impression that resolv.conf was explicitly used by the dns nss module, but I could be wrong. The mDNS will requires its own nss module that should be independent from the other DNS. Fredrik Lindberg