Date: Fri, 25 Aug 2006 11:12:29 -0400 From: Pat Lashley <patl+freebsd@volant.org> To: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> Cc: freebsd-net@freebsd.org, Doug Barton <dougb@FreeBSD.org> Subject: Re: Zeroconfig and Multicast DNS Message-ID: <A889C23B148D6DD14C451F1F@garrett.local> In-Reply-To: <44EE9D66.80105@shapeshifter.se> References: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> <44EE9D66.80105@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 <domain> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A889C23B148D6DD14C451F1F>