[dnssd] Example Use Cases (was Re: Rechartering)

["R. Atkinson" <[e-mail]>]

I’d like to talk a little bit about use cases relating to both mDNS & DNS-SD.

This is mostly prompted by the rechartering slides (which I read online,
although I have not been in Montreal for IETF this week).

These are partly baked thoughts, written in haste, so are incomplete
and probably have typing/editing errors in places.

1. ZeroConf / No Infrastructure Case

   In my experience as a user and as a consultant, is that most (non-IETF :-)
   residences and most small-businesses fundamentally want a zero 
   configuration network.  The outer limit of what they might view as 
   acceptable infrastructure is enabling a DHCP server (facing to the interior) 
   on a (small) site border router that uplinks to some ISP. 

   These sites have viewed the “magic” appearance of “it just works” 
   mDNS + DNS-SD as a huge win — a win that they really do not want
   to lose.  The main application benefit I see is printer discovery, but 
   there are other services that do get advertised and also get used
   via the existing widely deployed mDNS + DNS-SD combination.
   (Again, their preference is for a Zero Configuration network, even if
    that means a less secure interior network deployment.)
   
   In this environments, the site border router typically just learns its IP address
   and other configuration (e.g. ISP’s DNS resolvers) by running a DHCP/DHCPv6
   client on the exterior router interface and trusting the ISP’s DHCP reply.
   The same router runs a DHCP/DHCPv6 server on the interior interface,
   and the router’s DHCP replies carry along DNS resolver information learned
   from the DHCP client on its exterior interface.  The site does not itself
   have a DNS server or even its own DNS resolver.

   In these environments, I rarely see any servers within a small business.
   They might have a web site and email, but those often are outsourced
   to someone other than their ISP.  Email very often is really web-based email.
   If they happen to have their own domain name (example.com), they
   usually are NOT running the DNS name server for that and they are NOT
   using that domain name on internal machines.  Instead, their domain name
   is advertised by their (outsourced) web site hosting company, which often
   also is providing them with web-based email.
      
   Medical offices (in my neighborhood) seem to be migrating to “electronic
   records”.  In practice, this often means some deal with a local hospital.
   The servers are run at the hospital IT department and client-server type
   software is installed on the medical office computers (or a web application
   is used instead), but the servers are all offsite and run by someone else.
   Privacy laws/regulations on medical data are growing, even outside the EU,
   and a common belief is that it is better to outsource the implementation
   so that some other organization is responsible for privacy & security
   compliance (e.g. HIPAA).

   These sites LOVE the existing mDNS + DNS-SD solution.  Their only real
    wish is that if they have 2 or 3 subnets, they could somehow have a single
    operational mDNS environment (instead of having one mDNS environment
    per subnet).  At least some of my clients have enabled a non-standard mDNS
    proxy that is available from a well-known IP router vendor.  At their scale,
    they are happy with that router vendor’s approach.  I worry a bit that in a
    larger network environment too much bandwidth would be consumed 
    (as happened historically with SLP) by that vendor’s implementation approach.

    As I have mentioned to Stuart at least once in the past, these folks really
    want something that looks/feels/behaves like the old AppleTalk/EtherTalk
    system — although most clients don’t use that terminology (because they
    were not working age when those capabilities were widely deployed by sites
    with Apple products).


2.  Larger Enterprise / Campus / Building-sized Case

    Larger businesses usually do have their own internal mail servers, file
    servers, and DNS servers.  Often their authoritative DNS servers are
    different/separate from their DNS resolvers.  These often have 2 logically
    different WiFi networks, one for employees/internal-users and one for
    guests.  Sometimes the “guest” wireless is outside a corporate firewall
    and only sees the public Internet.   Other times the “guest” network is in
    a kind of DMZ environment, so that guest’s can discover printers and
    send out print jobs, but does NOT have unconstrained access to the
    organization’s internal network.

    In this environment, often there is more concern about “security”, which 
    seems to mean some combination of “access control” (about what a 
    given node can see) and “authentication” (for DNS updates) relative to 
    DNS service advertisements.  (In the extreme, I have a client who turns
    on every possible security feature, including use of things like 802.1x.
    This results in a more secure, if somewhat more brittle, deployment.)

    In this environment and for these users, there is MUCH more willingness
    to have IT staff configure “infrastructure” (e.g., routers, switches, servers, proxies)
    than in Case 1 at top of this email.  This customer type also is MUCH more
    interested in using access controls and/or cryptographic authentication for
    any service advertisements and for any kind of DNS update.  

    However, in my experience, these customers do NOT want to configure 
    the end-user devices — at least not beyond whatever DHCP (or DHCPv6
    + IPv6 ND) can provide by way of automatic configuration.

     Note that users in this category often want to see services for their
     (logical) organization, regardless of where they are within the campus
     (or which campus for multi-campus organizations).  Someone who works
     in “engineering” wants to see all of the “engineering” groups services
     plus whatever printers are geographically near the person’s current
     location.  In old AppleTalk this flexibility was pretty easily deployed and 
     also pretty easily used.


Postulate:

    My postulate, again based on my own non-scientific sample, is that there
    are at least 2 distinct use cases for DNS-SD (and mDNS).  One case is
    small scale, so scalability of solution is not as important.  The other case
    requires scalability.  The small sites are not usually very security conscious,
    while the larger sites usually are very security conscious.

    So it is conceivable that some potential products of this WG might apply
    to one use case, but not to the other use case.  I think we need to all keep
    both use cases in mind as the WG ponders current/future work in this WG.

Yours,

Ran