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 <cheshire(_at_)apple(_dot_)com>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf