From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 17:48:08 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 8CFF816A4E6; Thu, 24 Aug 2006 17:48:08 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 833D843D5D; Thu, 24 Aug 2006 17:47:56 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGJMF-000Nhd-RE; Thu, 24 Aug 2006 10:51:21 -0700 Date: Thu, 24 Aug 2006 10:46:50 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <93381966E13B960D4ACFF05C@garrett.local> In-Reply-To: <44EDCEC2.7060109@shapeshifter.se> 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> <44EDCEC2.7060109@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: ad3247664fb21905dd1e193a1aebee8942160683 X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.5 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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 17:48:08 -0000 > 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. In general, I agree with, and have been known to strongly champion, that sentiment. But I also believe that programs should Do The Right Thing even when the config file is missing. And in this case The Right Thing is to advertise the hostname; since that will be the desired result in 99+% of the cases. > > 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. And that's one of the things that we'll have to fix if we want LLA and mDNS to work correctly. The default should probably be to assume that they are separate; but to recognize if they are in fact on the same link. That should be easy enough to do since the LLA packets sent out on one interface will be seen by the other one when they are on the same link. > > 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. The NSS module shouldn't have to know which domains mDNS is handling. It should just attempt to resolve the FQDN given, using mDNS. If it fails, resolution will fall back to the next module listed in nsswitch.conf. (I envision the default as being: files mdns dns) The problem with your proposal is that if the config file is missing, there is no host advertisement at all. Also, that doesn't address the service advertisement records. As I recall, the actual DNS records for service discovery look something like _service._protocol.fqdn. So in the multi-domain situation, you want each service to be -automatically- advertised as existing in -all- of the host's domains. > > 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. I think our main point of disagreement here is on whether suitable default behavior requires the presence of a (default) config file. With a minor disagreement over how much of the configuration should be choosable via /etc/rc.conf -vs- mdns.conf. > 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. > } Adding IPv6 support wouldn't be quite as simple as just adding two more lines. The default behavior needs to be able to handle all three cases: IPv4 only, IPv6 only, and both. You don't want to advertise an A record if $(ifaddr) isn't set. (And you do NOT want to issue an error/warning message. At least not unless higher-than-default verbosity was explicitly requested.) > > 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. That's why the default should be to NOT advertise everything that is in /etc/hosts. But it would be very convenient to not have to add/remove the same mapping to two different config files. Please note that I'm not saying that you shouldn't be able to add mappings directly to the mdns.conf; only that if you are putting things into /etc/hosts anyway, it might be useful to have the ability to just tell mdns to advertise everything in /etc/hosts. > 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. Hmmm. You may be right about who is reading resolv.conf. But I'm not really happy about the thought of adding yet another config file; especially since some of the info (domain/search) is almost certain to need to be duplicated between them. Since we need some way to tell the mdns daemon which domain(s) to use if we're using anything other than $(domainname); perhaps the mdns.conf can be shared between the daemon and the nss module. Split the info into sections to make it easier for each to know which parts they aren't expected to understand and put all of the stuff they both want into a shared section. -Pat