Subject: Requirements for Service Discovery

From: Stuart Cheshire <[email-masked]>
Date: Tue, 30 Jul 2002 22:34:45 -0700

Erik raises some good requirements here, and I think it is
a useful exercise to evaluate DNS-SD against this list.

> 1) security -     which services can advertise themselves?
>                   what configuration do services, clients and
>                     infrastructure need?
>                   what is the policy - what does one do with
>                     unauthenticated services one discovers?

I believe that "security through not advertising" is flawed.
A hacker can run a port scan to see what listening ports are open.
Security through not advertising makes lives harder for legitimate
users without significantly making lives harder for intruders.

The risk of discovering a rogue service on the network masquerading as a 
legitimate service is real.

The benefit of using DNS-SD is that it allows us to build on existing 
work like DNS SEC, instead of having to learn one security model for host 
names and a different one for service discovery.

A DNS server can choose to accept DNS Updates only from authorized 
clients.

A DNS resolver can choose to ignore DNS Responses that are not properly 
cryptographically signed.

> 2) organization - what administrative hierarchy is presented for browsing?

Host names can be organized into domains and subdomains
(e.g. host.sales.apple.com., host.eng.apple.com., etc.,
or host.building1.apple.com., host.building2.apple.com., etc.,
as the organization chooses).

With DNS-SD, the hierarchy of services can follow the exiting DNS 
hierarchy that the users already understand and expect.

> 3) performance -  what does the administrator have to improve performance?

It is the responsibility of the protocol designer to provide good 
performance. We should not require administrators to tinker to fix 
performance problems. Being able to tinker to fix performance problems 
may seem like a benefit at the time, but the reality is that it is an 
unreasonable burden. A manual choke in a car lets you manually adjust the 
fuel/air mix, but that is not a benefit; it is a deficiency of the car if 
it can't do that automatically for itself.

> 4) parameters -   what parameters can one obtain for services from the
>                     service discovery mechanism to configure clients
>                     (beyond merely the address of the server)?
>                   what is the 'schema' for these parameters?

Supporting a small amount of configuration is a useful feature of a 
service discovery mechanism. DNS-SD provides this feature with the 
convention of using a TXT record with the same name as the SRV record. 
For each service type, a 'profile' has to be written which specifies what 
goes in the TXT record for that service type.

As an example, the DNS-SD 'profile' that Apple is proposing for IPP and 
LPR printing includes sufficient information in the TXT record for the 
client software to automatically select the right PPD file for that 
printer without user intervention.

> 5) naming -       what are service names?

If you mean the names of service types (protocols), DNS-SD
follows the convention in RFC 2782 -- service types are defined
by the protocol names in the IANA list of well-known ports at
<http://www.iana.org/assignments/port-numbers>.

If you mean the names of service instances, they are selected freely by 
the user.

> 6) management -   what does an administrator have to do to 'set up' a
>                     group of clients and servers so that all the clients
>                     in the enterprise can discover all the same set of 
>                     services?   How can this be controlled? 

Exiting DNS concepts (e.g. the client 'search list') are a natural fit 
for this requirement.

> 7) internet       what has to happen to the protocol to make it scale
>    resource          to the internet - so services can be discovered in
>    discovery -       other administrative domains?

DNS is a distributed hierarchical system, which already supports queries 
addressed to other administrative domains. Since DNS-SD records are just 
DNS records like any other, they can be queried from other administrative 
domains like any other. To try it out, type the following:

nslookup -q=ptr _printer._tcp.stuartcheshire.org.

---

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org