Zeroconfig and Multicast DNS

[Pat Lashley]

> > 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