Re: Last Call: <draft-cheshire-dnsext-dns-sd-07.txt> (DNS-Based Service Discovery) to Proposed Standard

[Stuart Cheshire <[e-mail]>]

On 22 Dec 2010, at 23:33, Pekka Savola wrote:

> What I'm saying is that having to manually pre-configure the hostname in DNS goes against what appears to be one of the main DNS-SD goals, i.e., the host can invent the hostname or use it in a zero-conf fashion.
> 
> I don't think it's possible to integrate DNS-SD with secure DNS without losing at least some of the properties DNS-SD was designed to address.  So it would be unrealistic to require this from the protocol, especially given its background.
> 
> What I would have wanted to see is more truth in advertising how in practise using security impedes the use of DNS-SD.  Which usage modes of DNS-SD can be made to work and at what cost.

I see the confusion. Multicast DNS is intended to be zero-configuration. DNS-SD is not necessarily. I have added this to the introduction which should hopefully clarify this:

   When used with Multicast DNS, DNS-SD can provide zero-configuration
   operation -- just connect a DNS-SD/mDNS device and its services are
   advertised on the local link with no further user interaction.

   When used with conventional unicast DNS, some configuration will
   usually be required -- such as configuring the device with the DNS
   domain(s) in which it should advertise its services, and configuring
   it with the DNS Update [RFC 2136] keys to give it permission to do
   so. In rare cases, such as a secure corporate network behind a
   firewall where no DNS Update keys are required, zero-configuration
   operation may be achieved by simply having the device register its
   services in a default registration domain it learns from the network
   (See Section 12 "Discovery of Browsing and Registration Domains")
   but usually security credentials will be required to perform DNS
   Updates.

Stuart Cheshire <[e-mail]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org