From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 15:13:30 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 0D96A16A4DE; Fri, 25 Aug 2006 15:13:30 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0A0E43D5F; Fri, 25 Aug 2006 15:13:21 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.167]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGdQH-000AbT-EA; Fri, 25 Aug 2006 08:16:45 -0700 Date: Fri, 25 Aug 2006 11:12:29 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: In-Reply-To: <44EE9D66.80105@shapeshifter.se> References: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> <44EE9D66.80105@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 5a9f0aa7631eaf24b05a19f367ec35b66bbb353d X-Spam-User: nobody X-Spam-Score: -4.3 (----) X-Spam-Score-Int: -42 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: (-4.3 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 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: Fri, 25 Aug 2006 15:13:30 -0000 > > No, I don't think that there's any good reason to restrict mDNS service > > discovery to .local; when you're using some other domain on the LAN, you > > still want to easily do the dynamic service advertisement, even if the A > > records are being handled by a traditional unicast DNS server and static > > IP allocation. > > Well, this would cause an authority conflict if it's on by default as > anyone on the local network would be able to announce SD records in > a domain they do not have authority over. The normal use of SD requires the ability of non-privileged users to announce services on the FQDN of the host upon which they are running. (Think iTunes playlist sharing.) > Do do SD updates to an DNS zone you would need to enable dynamic updates > on that name server, just as the Service Discovery specifications says. What makes you think that there even IS a unicast DNS server for the (sub)domain in question? > Some quotes from draft-cheshire-dnsext-dns-sd.txt > > The part of the name may be "local" (meaning "perform the > query using link-local multicast) or it may be learned through some > other mechanism, such as the DHCP "Domain" option (option code 15) > [RFC 2132] or the DHCP "Domain Search" option (option code 119) > [RFC 3397]. > > Service discovery requires a central aggregation server. > DNS already has one: It's called a DNS server. > > Service discovery requires a service registration protocol. > DNS already has one: It's called DNS Dynamic Update. > > Service discovery requires a query protocol > DNS already has one: It's called DNS. > > Service discovery requires security mechanisms. > DNS already has security mechanisms: DNSSEC. > > Service discovery requires a multicast mode for ad-hoc networks. > Zeroconf environments already require a multicast-based DNS-like > name lookup protocol for mapping host names to addresses, so it > makes sense to let one multicast-based protocol do both jobs. > > I don't say that we shouldn't support it, but it should not be on by > default. And it will actually boil down to what the mdns nss module > allows. I agree that it should not be on by default. But there should be one simple knob in rc.conf to cause service advertisements to be published for both .local and the host domain. Any thing more complex would require editing mdns.conf. -Pat