From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 04:32:56 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 4C6D616A4DD; Fri, 25 Aug 2006 04:32:56 +0000 (UTC) (envelope-from patl@phoenix.volant.org) Received: from orwell.phoenix.volant.org (64-144-229-193.client.dsl.net [64.144.229.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 763CD43D62; Fri, 25 Aug 2006 04:32:46 +0000 (GMT) (envelope-from patl@phoenix.volant.org) Received: from [172.24.16.2] by orwell.phoenix.volant.org with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGTN3-0001Pk-Ot; Thu, 24 Aug 2006 21:32:42 -0700 Date: Fri, 25 Aug 2006 00:32:25 -0400 From: PM Lashley To: Fredrik Lindberg Message-ID: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 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 04:32:56 -0000 > >> The nsswitch.conf should IHMO be :files dns mdns, > > > >> and the mdns nss module should ship with a default to only allow > >> queries to > >> .local > >> .168.254.in-addr.arpa > > > > I think you meant .254.168.in-addr.arpa here. > > Actually .254.169.in-addr.arpa :) Err, yes. I knew that... :-) > >> .168.192.in-addr.arpa > >> .16.172.in-addr.arpa-31.172.in-addr.arpa > >> .10.in-addr.arpa > > > > I put mdns before dns for performance reasons. If you restrict the > > queries as defined above, there's no real advantage to doing the dns > > query first. > > Yes, agreed (if restricted). > > > > > I am reluctantly coming to agree that for security reasons we need to > > restrict the domains for A record lookups via mDNS; and PTR records in > > the in-addr.arpa domain. > > > > I think the reasons are very clear, in a mobile environment you might > hook up your laptop to various "untrusted" networks. Just because they're clear doesn't mean that I'm happy with them. But then I'm not happy with the need to lock my car or my front door either; but I recognize the need to do so. > > But service discovery will often have a non-.local domain; so I think we > > need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything > > outside in-addr.arpa. Given the existence of the .local domain, I don't > > see any utility in advertising a service in an in-addr.arpa domain. I'm > > sure somebody will post an example if I'm just being short-sighted here...) > > As you said above SD is not only for mDNS. SD over mDNS should be in the > .local domain. A SD browser should go through the normal nss environment > to do its searching and not directly consult the mDNS API for all of its > queries. Under normal circumstances queries for SD records in existing > TLDs should be looked up just as any other DNS record. 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. > > Not entirely. It is also a syntactic/semantic issue in the config file > > design. There's a choice between whether there's an implicit "ignore > > this if the necessary protocol isn't available" or some sort of > > conditional block to explicitly say 'if condition X, then apply the > > following set of options'. The later is potentially more powerful. > > Yes, I agree. A user might want to advertise a record only if a > certain condition is met, however I think we should be careful > not to create a too complex syntax. > The mdns.conf must be simple enough so that an average user is > able to edit it without too much knowledge. > We really do not want to turn in into something similar to named.conf, > more /etc/hosts on steroids. We can define the basic conditional block and some simple conditional tests for things like 'is interface X currently supporting IPv4?' or 'is interface X a point-to-point link?'; and possibly a 'for each '. And then add condition tests as necessary/desirable later. -Pat